Nota del autor

Si la entrada que estás leyendo carece de imágenes, no se ve el vídeo que teóricamente lleva incrustado o el código fuente mostrado aparece sin formato, podéis conocer los motivos aquí. Poco a poco iré restableciendo la normalidad en el blog.
Este blog es un archivo de los artículos situados previamente en Lobosoft.es y ha dejado de ser actualizado. Las nuevas entradas pueden encontrarse en www.lobosoft.es. Un saludo,
Lobosoft.
Mostrando entradas con la etiqueta Seguridad. Mostrar todas las entradas
Mostrando entradas con la etiqueta Seguridad. Mostrar todas las entradas

miércoles, 28 de septiembre de 2011

Nueva vuelta de tuerca a la privacidad en la nube.

Entrada publicada originariamente en el blog Lobosoft bajo el mismo título.

Quienes me conocen saben de mi escepticismo sobre la computación en la nube. No es que no me parezca un campo apasionante, que lo es, ni que reniegue de la ubicuidad de los datos y del software, pues la considero una configuración de sistemas informáticos válida e interesante hasta cierto punto y para determinados usos. Lo que no me gusta (ya no como profesional de la informática, sino como usuario de la misma) es que mis datos estén diseminados por el mundo y no sentirme dueño de mi software: que este sea única y exclusivamente un servicio (SaaS).

En lo personal he podido comprobar cómo personas cercanas a mí han sufrido problemas con la disponibilidad del servicio de aplicaciones en la nube y, aunque obviamente esto es algo que puede ocurrirnos con cualesquiera otros de cuantos están involucrados en el proceso, como el acceso a Internet por parte de nuestro proveedor, por ejemplo, lo cierto es que tener un plazo de entrega de un trabajo determinado y no poder llevarlo a cabo porque hay problemas con los servidores puede resultar algo exasperante. De cualquier forma, esto es soluble mediante replicación de servicios y una mejora de la confianza y la asistencia técnica de los mismos.


Sin embargo, que los datos se encuentren en la nube es una cuestión más delicada. ¿Qué empresa dejaría en un servidor remoto el detalle de sus operaciones contables? ¿Y los datos de sus clientes o trabajadores? ¿Almacenaríamos nuestro historial médico en un disco duro “virtual” accesible a través de Internet? ¿Quién nos asegura que los datos no serán robados, como ocurriera recientemente con las cuentas bancarias de usuarios de Sony? ¿Y que no serán usados por nuestra compañía para ofrecernos otros servicios –como publicidad personalizada– al más puro “estilo Google”?

Hasta hace poco, nadie podía asegurarnos que nuestros datos no pudieran ser robados, usados o alterados sin nuestro consentimiento y/o conocimiento. Sin embargo, esta noche leía con interés una noticia sobre un avance en la resolución de esta problemática llevado a cabo por la gente de Microsoft. Se trata de una implementación parcial de un sistema de cifrado homomórfico, en la que se permiten algunos cálculos básicos (sumas, multiplicaciones) que, no obstante, permitirán ser combinados para llevar a cabo operaciones más avanzadas, como funciones estadísticas del tipo del modelo logístico.

Este avance es importante ya que el cifrado homomórfico permitiría vislumbrar un futuro interesante para el almacenamiento de datos en la nube. Sin embargo, desde la publicación del artículo de Ronald L. Rivest en 1978 (On Data Banks And Privacy Homomorphisms) transcurrieron más de 30 años de debates hasta que se ofreció un posible escenario de resolución de un sistema de cifrado homomórfico completo. Fue en su tesis de doctorado, A Fully Homomorphic Encryption Scheme, donde Craig Gentry presentó un modelo matemático completamente funcional; con todo, la gran cantidad de cálculos necesarios para hacerlo funcionar llevaron al experto en seguridad Bruce Schneier a afirmar que transcurrirían al menos cuarenta años más hasta que pudiera ser llevado a la práctica un sistema así de complejo con el mismo rendimiento que uno que no use cifrado. Schneier llegó a sus conclusiones basándose en la ley de Moore y en los datos aportados por Gentry en un artículo acerca del cifrado homomórfico y el tiempo requerido para llevar a cabo las operaciones de búsqueda por parte de un hipotético Google que usase de este mecanismo de cifrado.

El funcionamiento básico del cifrado homomórfico es el siguiente: supongamos un esquema criptográfico con un sistema de cifrado simétrico o asimétrico donde tenemos dos funciones, C(x,k), que cifra el valor ‘x’ usando la clave ‘k’ y otra D(y,k) que descifra ‘y’ usando la clave ‘k’. Entonces podemos afirmar que

D(C(x,k),k) = x

Esto es así para cualquier sistema de cifrado. Se cumplirá que es homomórfico si además existe un conjunto de pares de funciones (F, G) tales que

D(F(C(x,k)) = G(x)

Las funciones F y G pueden ser o no la misma, pero dada F podemos saber G, y viceversa.

Como resultado de lo anterior, podemos llevar a cabo operaciones sobre los datos cifrados, sin descifrarlos, por lo que el proveedor de servicios no tiene la necesidad de almacenarlos en claro y únicamente nosotros, como clientes, tenemos acceso a los mismos sin cifrar.

¡Ay, qué feliz habría sido nuestro paso por la asignatura de matemática discreta si hubiéramos encontrado ejemplos así de prácticos en el primer año de carrera! ;)

A pesar de lo interesante del avance de Microsoft y sus aplicaciones prácticas en la nube, los esquemas de cifrado con homomorfismo parcial no son demasiado raros. Por ejemplo, uno que todos conoceréis es RSA, que es homomórfico respecto a la multiplicación. Dadas un par de claves pública y privada (K,k), para todo par de valores ‘x’ e ‘y’ se cumple que:

D(C(x*y,k),K) = x*y

Un posible escenario de uso del cifrado homomórfico podría ser el de una empresa que desee hacer uso de un servicio en la nube para almacenar datos de sus clientes. La explotación de una vulnerabilidad en el servidor podría exponer dichos datos al atacante en un sistema como los actuales y, si el servicio almacenase todos los datos cifrados como mejora de la seguridad, el acceso a los mismos sería demasiado penoso. Imaginemos que nuestra empresa desea realizar una consulta sobre sus datos de clientes para obtener aquellos residentes en una provincia determinada que hayan alcanzado un determinado volumen de compras. La consulta sobre la tabla de clientes requeriría ir descifrando cada una de las filas, comprobar si se cumplen las condiciones requeridas y devolverlo, o no, en función de ello. En un servidor que usase el cifrado homomórfico la consulta se haría sobre los datos cifrados directamente, devolviendo únicamente aquellos que se vieran afectados por la consulta y podrían ser descifrados en el propio equipo del cliente sin ser expuestos a “miradas ajenas” en ningún momento.

En resumen, se trata de un interesante avance en lo tocante a la seguridad y la privacidad en la nube, para evitar que esta devenga en nubarrón.

Para saber más:
El cuadro que ilustra la entrada es un óleo de J. M. William Turner, "Rain Cloud", y la camiseta la he encontrado en Nerdy T-Shirt.

jueves, 11 de agosto de 2011

Nueva vuelta de tuerca a la privacidad en la nube.

Quienes me conocen saben de mi escepticismo sobre la computación en la nube. No es que no me parezca un campo apasionante, que lo es, ni que reniegue de la ubicuidad de los datos y del software, pues la considero una configuración de sistemas informáticos válida e interesante hasta cierto punto y para determinados usos. Lo que no me gusta (ya no como profesional de la informática, sino como usuario de la misma) es que mis datos estén diseminados por el mundo y no sentirme dueño de mi software: que este sea única y exclusivamente un servicio (SaaS).

En lo personal he podido comprobar cómo personas cercanas a mí han sufrido problemas con la disponibilidad del servicio de aplicaciones en la nube y, aunque obviamente esto es algo que puede ocurrirnos con cualesquiera otros de cuantos están involucrados en el proceso, como el acceso a Internet por parte de nuestro proveedor, por ejemplo, lo cierto es que tener un plazo de entrega de un trabajo determinado y no poder llevarlo a cabo porque hay problemas con los servidores puede resultar algo exasperante. De cualquier forma, esto es soluble mediante replicación de servicios y una mejora de la confianza y la asistencia técnica de los mismos.


Sin embargo, que los datos se encuentren en la nube es una cuestión más delicada. ¿Qué empresa dejaría en un servidor remoto el detalle de sus operaciones contables? ¿Y los datos de sus clientes o trabajadores? ¿Almacenaríamos nuestro historial médico en un disco duro “virtual” accesible a través de Internet? ¿Quién nos asegura que los datos no serán robados, como ocurriera recientemente con las cuentas bancarias de usuarios de Sony? ¿Y que no serán usados por nuestra compañía para ofrecernos otros servicios –como publicidad personalizada– al más puro “estilo Google”?

Hasta hace poco, nadie podía asegurarnos que nuestros datos no pudieran ser robados, usados o alterados sin nuestro consentimiento y/o conocimiento. Sin embargo, esta noche leía con interés una noticia sobre un avance en la resolución de esta problemática llevado a cabo por la gente de Microsoft. Se trata de una implementación parcial de un sistema de cifrado homomórfico, en la que se permiten algunos cálculos básicos (sumas, multiplicaciones) que, no obstante, permitirán ser combinados para llevar a cabo operaciones más avanzadas, como funciones estadísticas del tipo del modelo logístico.

Este avance es importante ya que el cifrado homomórfico permitiría vislumbrar un futuro interesante para el almacenamiento de datos en la nube. Sin embargo, desde la publicación del artículo de Ronald L. Rivest en 1978 (On Data Banks And Privacy Homomorphisms) transcurrieron más de 30 años de debates hasta que se ofreció un posible escenario de resolución de un sistema de cifrado homomórfico completo. Fue en su tesis de doctorado, A Fully Homomorphic Encryption Scheme, donde Craig Gentry presentó un modelo matemático completamente funcional; con todo, la gran cantidad de cálculos necesarios para hacerlo funcionar llevaron al experto en seguridad Bruce Schneier a afirmar que transcurrirían al menos cuarenta años más hasta que pudiera ser llevado a la práctica un sistema así de complejo con el mismo rendimiento que uno que no use cifrado. Schneier llegó a sus conclusiones basándose en la ley de Moore y en los datos aportados por Gentry en un artículo acerca del cifrado homomórfico y el tiempo requerido para llevar a cabo las operaciones de búsqueda por parte de un hipotético Google que usase de este mecanismo de cifrado.

El funcionamiento básico del cifrado homomórfico es el siguiente: supongamos un esquema criptográfico con un sistema de cifrado simétrico o asimétrico donde tenemos dos funciones, C(x,k), que cifra el valor ‘x’ usando la clave ‘k’ y otra D(y,k) que descifra ‘y’ usando la clave ‘k’. Entonces podemos afirmar que

D(C(x,k),k) = x

Esto es así para cualquier sistema de cifrado. Se cumplirá que es homomórfico si además existe un conjunto de pares de funciones (F, G) tales que

D(F(C(x,k)) = G(x)

Las funciones F y G pueden ser o no la misma, pero dada F podemos saber G, y viceversa. 

Como resultado de lo anterior, podemos llevar a cabo operaciones sobre los datos cifrados, sin descifrarlos, por lo que el proveedor de servicios no tiene la necesidad de almacenarlos en claro y únicamente nosotros, como clientes, tenemos acceso a los mismos sin cifrar.

¡Ay, qué feliz habría sido nuestro paso por la asignatura de matemática discreta si hubiéramos encontrado ejemplos así de prácticos en el primer año de carrera! ;)

A pesar de lo interesante del avance de Microsoft y sus aplicaciones prácticas en la nube, los esquemas de cifrado con homomorfismo parcial no son demasiado raros. Por ejemplo, uno que todos conoceréis es RSA, que es homomórfico respecto a la multiplicación. Dadas un par de claves pública y privada (K,k), para todo par de valores ‘x’ e ‘y’ se cumple que:

D(C(x*y,k),K) = x*y

Un posible escenario de uso del cifrado homomórfico podría ser el de una empresa que desee hacer uso de un servicio en la nube para almacenar datos de sus clientes. La explotación de una vulnerabilidad en el servidor podría exponer dichos datos al atacante en un sistema como los actuales y, si el servicio almacenase todos los datos cifrados como mejora de la seguridad, el acceso a los mismos sería demasiado penoso. Imaginemos que nuestra empresa desea realizar una consulta sobre sus datos de clientes para obtener aquellos residentes en una provincia determinada que hayan alcanzado un determinado volumen de compras. La consulta sobre la tabla de clientes requeriría ir descifrando cada una de las filas, comprobar si se cumplen las condiciones requeridas y devolverlo, o no, en función de ello. En un servidor que usase el cifrado homomórfico la consulta se haría sobre los datos cifrados directamente, devolviendo únicamente aquellos que se vieran afectados por la consulta y podrían ser descifrados en el propio equipo del cliente sin ser expuestos a “miradas ajenas” en ningún momento.

En resumen, se trata de un interesante avance en lo tocante a la seguridad y la privacidad en la nube, para evitar que esta devenga en nubarrón.


Para saber más:
El cuadro que ilustra la entrada es un óleo de J. M. William Turner, "Rain Cloud", y la camiseta la he encontrado en Nerdy T-Shirt.

miércoles, 27 de julio de 2011

Manejando minidumps en .NET

Por mucho cuidado que pongamos en la programación, por exhaustivas que sean las pruebas unitarias que dirigen nuestros desarrollos y meticulosas las personas que realicen las funcionales, de integración o aceptación, lo cierto es que de cuando en cuando nos encontraremos ante la tesitura de tener que depurar un error en nuestras aplicaciones sobre una máquina de producción. En estos equipos no tendremos disponible nuestro IDE favorito y, aparte de las trazas de depuración que podamos habilitar para ayudarnos a determinar el origen del problema, lo cierto es que a priori solo nuestra holmesiana capacidad de deducción nos ayudará a lograr nuestro objetivo.

Sin embargo, no estamos del todo “vendidos”, y además de numerosas herramientas de depuración que nos ofrece Microsoft en su paquete Debugging Tools for Windows o de instalar en .NET Reflector add-ins como Deblector –técnicas en las que entraremos más adelante– podemos hacer uso de la función de la API MiniDumpWriteDump para obtener un archivo con un volcado de memoria que nos ayude, ya en nuestra máquina de desarrollo, a depurar el problema, bien con alguna de las aplicaciones diseñadas a tal fin, bien con el propio Visual Studio que, especialmente en su versión de 2010 sobre el .NET Framework 4, cuenta con poderosas herramientas a tal fin.

Los minidumps permiten la depuración post mórtem de nuestras aplicaciones, es decir, llevarla a cabo cuando la aplicación está “muerta”. Son usados, por ejemplo, por Microsoft, cuando un usuario envía información sobre un error desde el cuadro de diálogo correspondiente de Windows XP. Un minidump consiste en un volcado de la memoria de nuestra aplicación, y mediante la carga del mismo en un depurador podremos estudiar desde el hilo en el que se produjo una determinada excepción al valor de las variables involucradas o el estado de nuestro programa. Esto lo veremos más adelante. Por lo pronto, veamos cómo podemos usar la función nativa de Windows MiniDumpWriteDump desde nuestro código.

Obvia decir que al no tratarse de una función propia del .NET Framework es necesario realizar la llamada mediante Interop. Así, lo primero es definir las estructuras de datos que necesitaremos para hacer uso de aquella y, a continuación, importar las librerías necesarias y las funciones que usaremos, tanto de la Kernel32.dll para obtener información sobre el proceso como, en el caso de MiniDumpWriteDump, Dbghelp.dll.

Según la MSDN, la sintaxis de nuestra función es:
BOOL WINAPI MiniDumpWriteDump(
__in HANDLE hProcess,
__in DWORD ProcessId,
__in HANDLE hFile,
__in MINIDUMP_TYPE DumpType,
__in PMINIDUMP_EXCEPTION_INFORMATION ExceptionParam,
__in PMINIDUMP_USER_STREAM_INFORMATION UserStreamParam,
__in PMINIDUMP_CALLBACK_INFORMATION CallbackParam
);
Crearemos una clase que nos ofrezca el comportamiento que deseamos: un auxiliar que nos permita volcar a fichero el estado de la memoria cuando nuestro proceso capture una determinada excepción. El código podría quedar así:

    public class MiniDumpWriter
    {
        [Flags]
        public enum DumpType : uint
        {
            MiniDumpNormal = 0x00000000,
            MiniDumpWithDataSegs = 0x00000001,
            MiniDumpWithFullMemory = 0x00000002,
            MiniDumpWithHandleData = 0x00000004,
            MiniDumpFilterMemory = 0x00000008,
            MiniDumpScanMemory = 0x00000010,
            MiniDumpWithUnloadedModules = 0x00000020,
            MiniDumpWithIndirectlyReferencedMemory = 0x00000040,
            MiniDumpFilterModulePaths = 0x00000080,
            MiniDumpWithProcessThreadData = 0x00000100,
            MiniDumpWithPrivateReadWriteMemory = 0x00000200,
            MiniDumpWithoutOptionalData = 0x00000400,
            MiniDumpWithFullMemoryInfo = 0x00000800,
            MiniDumpWithThreadInfo = 0x00001000,
            MiniDumpWithCodeSegs = 0x00002000,
            MiniDumpWithoutAuxiliaryState = 0x00004000,
            MiniDumpWithFullAuxiliaryState = 0x00008000,
            MiniDumpWithPrivateWriteCopyMemory = 0x00010000,
            MiniDumpIgnoreInaccessibleMemory = 0x00020000,
            MiniDumpValidTypeFlags = 0x0003ffff,
        };

        [StructLayout(LayoutKind.Sequential, Pack = 4)]  
        struct MiniDumpExceptionInformation
        {
          public uint ThreadId;
          public IntPtr ExceptionPointers;
          [MarshalAs(UnmanagedType.Bool)]
          public bool ClientPointers;
        }

        [DllImport("dbghelp.dll",
          EntryPoint = "MiniDumpWriteDump",
          CallingConvention = CallingConvention.StdCall,
          CharSet = CharSet.Unicode,
          ExactSpelling = true, SetLastError = true)]

        static extern bool MiniDumpWriteDump(
          IntPtr hProcess,
          uint processId,
          IntPtr hFile,
          uint dumpType,
          ref MiniDumpExceptionInformation expParam,
          IntPtr userStreamParam,
          IntPtr callbackParam);

        [DllImport("kernel32.dll", EntryPoint = "GetCurrentThreadId", ExactSpelling = true)]
        static extern uint GetCurrentThreadId();

        [DllImport("kernel32.dll", EntryPoint = "GetCurrentProcess", ExactSpelling = true)]
        static extern IntPtr GetCurrentProcess();

        [DllImport("kernel32.dll", EntryPoint = "GetCurrentProcessId", ExactSpelling = true)]
        static extern uint GetCurrentProcessId();

        /// <summary>
        /// Generates a memory dump and save it into a file.
        /// </summary>
        /// <param name="fileName">The file where dump must be stored.</param>
        /// <param name="dumpType">The type of memory dump generated.</param>
        /// <returns></returns>       
        public static bool Write(string fileName, DumpType dumpType)
        {
            using (FileStream fs = new FileStream(fileName, 
                                                  FileMode.Create, 
                                                  FileAccess.Write, 
                                                  FileShare.None))
            {
                MiniDumpExceptionInformation exInfo;
                exInfo.ThreadId = GetCurrentThreadId();
                exInfo.ClientPointers = false;
                exInfo.ExceptionPointers = Marshal.GetExceptionPointers();
                
                bool value = MiniDumpWriteDump(GetCurrentProcess(),
                                               GetCurrentProcessId(),
                                               fs.SafeFileHandle.DangerousGetHandle(),
                                               (uint)dumpType,
                                               ref exInfo,
                                               IntPtr.Zero,
                                               IntPtr.Zero);                
                return value;
            }
        }
    }

Y para usarla, simplemente llamaremos al método correspondiente cuando nos interese tener un volcado de memoria, por ejemplo, cuando se produzca una excepción en nuestro programa:

 class Program
    {
        static void Main(string[] args)
        {
            try
            {
                object o = null;

                Console.WriteLine("Press ENTER to continue...");
                Console.ReadLine();

                o.ToString();

            }
            catch (System.Exception e)
            {                
                string dumpFile = @"Something\Like\lobosoft.dmp";                
                MiniDumpWriter.Write(dumpFile, MiniDumpWriter.DumpType.MiniDumpWithFullMemory);
            }
        }
    }

Hay que tener en cuenta que los ficheros generados son bastante voluminosos y que la ruta donde los guardará nuestra aplicación debe establecerse a una ubicación donde contemos con permisos suficientes como para que pueda ser escrito. Una vez generado podremos usar Visual Studio, o la Debugging Diagnostic Tool para analizar el error. Pero esto será objeto de una próxima entrada.

miércoles, 26 de mayo de 2010

Seguridad en WordPress


Tras el ataque sufrido en Lobosoft me he visto obligado a adelantar un poco la dedicación al blog (que tenía pensado incrementar, como ya dije, hacia mediados de junio), llevar a cabo una limpieza del mismo y actualizar, ya no la versión del mismo pero sí algunos plugins que podrían estar en el origen del ataque (fallo por mi parte al utilizar demasiados, aunque alguna de la funcionalidad extendidad del blog está basada, mucho me temo, en ellos).


El script que “me colaron” básicamente se encarga de permitir al atacante subir un archivo a la web con lo cual, dicho pronto y claro, la seguridad completa del sitio queda claramente comprometida. He estado buscando en Internet y parece que es un script genérico que ha sido instalado en numerosos servidores, sobre todo tipo de CMS y foros (y otras aplicaciones web), por lo que en sí no es más que una herramienta más que utilizar para atacar el sitio o usarlo como plataforma para fines oscuros y perversos. ;)


Uno de los blogs que he encontrado con el problema en cuestión es Brian's World, que muestra el código en cuestión. En mi caso no habían llegado ni tan siquiera a inyectarlo en uno de los archivos de Wordpress, sino que se encontraba replicado en varios archivos PHP con nombre similares (con un prefijo añadido) a los contenidos en un par de plugins y en el tema de Wordpress que da estilo al blog.
Dejo por aquí una extensa lista de referencias a la seguridad en Wordpress (algunas aplicables a otros CMS) que nunca está de más tener en cuenta. E incluso así, a pesar de lo que afirme nuestro amigo GigA, me temo que nada es demasiado seguro.


Feliz lectura.


Para saber más:


En castellano.




En inglés.

Más allá de WordPress.

La imagen que ilustra la entrada, que me ha encantado, es de Antivirus WordPress.

martes, 25 de mayo de 2010

Phoenicopterus

Hace apenas unos días comentaba en una entrada que me sentía con ganas y fuerzas de dar un empuje al blog. Tras un tiempo demasiado prolongado, durante el cual había permanecido inactivo por completo, con apenas alguna que otra entrada sin más contenido que vídeos o noticias que habían llamado mi atención, quería retomar un nivel de escritura aceptable, que tal vez no llegase al del verano de dos años atrás, pero sí que constituyese un estímulo para seguir adelante con el mismo. Sin embargo, es posible que en los últimos días, si habéis intentado al blog, lo hayáis encontrado deshabilitado, sin acceso o con un limitado, con problemas. El pasado sábado quise escribir una entrada en la que hablar, aunque fuese de forma somera, de la interesante charla que nos ofreció Bruno Capuano en Málaga mas no me fue posible. Tras un par de años de tranquilidad desde los últimos ataques al blog me encontré con que estaba siendo seriamente comprometido y usado como plataforma desde la que lanzar un ataque DoS contra otras máquinas. Mi gozo en un pozo, la cuenta desactivada hasta nueva orden y unos días en los que apenas podía permitirme el lujo de dedicarme a revisar el blog en los que este no ha estado disponible como habría sido de desear. Mis más sinceras disculpas a todos aquellos que pasaron por aquí buscando algo y tuvieron que irse como habían llegado.



La verdad es que el nuevo ataque me ha servido para reflexionar un poco en torno al blog, al sentido que tiene y al porqué de estas injerencias en su plácido transcurrir en la blogosfera. Por un lado, es cierto que hace un par de años sufrió un ataque en un periodo en el que no podía dedicar apenas tiempo al blog. Ahora ha ocurrido otro tanto, con la salvedad de que el blog llevaba ya mucho sin actividad y ha sido ahora, cuando intentaba retomarla, cuando ha ocurrido. Ya en las últimas semanas había notado ciertos repuntes bastante sospechosos en las visitas diarias al blog. El viernes, durante un descanso en el ecuador de la charla, le comentaba este hecho a un par de compañeros, así como mi suspicacia ante esta repentina afluencia a un blog apenas actualizado. La verdad es que no estaba equivocado.


¿Qué ha podido motivar el ataque? Bueno, no es necesario que exista una razón por la cual Lobosoft haya sido elegido, y ejercería de presuntuoso y “blogocéntrico” si afirmase que alguna oscura conspiración se ha centrado en este, mi blog, para derrocarlo. Sin embargo, me parece curioso que estando actualizado a la última versión estable de WordPress, con varios plugins de seguridad activados y sus ficheros de configuración de Apache medianamente bien estructurados haya sufrido un ataque de este tipo. A diario encuentro multitud de blogs WordPress (y otros CMS) sin actualizar, con la versión expuesta en el código HTML generado y que, pasando así el tiempo, no son atacados. Tal vez la temática del blog, que toca hasta cierto punto la seguridad informática, sea un aliciente para el hacker (más bien lammer, por los métodos usados) que haya accedido en una u otra ocasión. Ya os digo que no tiene que tratarse en sí mismo de un ataque centrado en el blog, pero si así fuese y el atacante estuviera leyendo estas líneas, me gustar decirle que, en primer lugar, no gano nada con el blog (es más, hasta la fecha me cuesta el dinero, aunque no me pesa: es una afición que me ofrece otros beneficios más allá de los pecuniarios) e intento ofrecer en él algunas píldoras de conocimiento que, espero, puedan ayudar a quienes lo necesiten. Y a mí mismo, por qué no decirlo, cuando esta memoria que tenemos nos falla en alguna ocasión y decimos: “oye, si yo escribí una vez algo de esto… voy a buscar en mi blog”, je, je, je. En segundo lugar, no soy un profesional de la seguridad informática. Informático, sí, y aficionado a la misma, intento que el blog sea un motor de aprendizaje y mejora de mis propios conocimientos. Por tanto, aunque haga mis pinitos en ella, con toda probabilidad muchos de los que leéis el blog superéis con creces mis propios conocimientos sobre el tema (me consta que algunos de quienes pasan o pasaron por aquí son grandes profesionales del campo de la seguridad, así que tomo sus visitas como un verdadero cumplido y como una invitación al reto de la autosuperación personal). Así las cosas, romper la seguridad del blog (basado en un CMS cuyo código está disponible libremente y con algunos plugins instalados que, me temo, han sido el origen de la actual invasión) supone un reto interesante pero prescindible. Si aun así, hipotético lector, te interesara atacarlo, me parecería un ejercicio interesante que cambiases la plantilla para poner un mensaje con lo membrillo que puedo llegar a ser y que yo intentase evitarlo, pero no que el sitio web sea usado para propagar pornografía, troyanos o para atacar a otros. Ahí la broma pasaría de castaño oscuro y la próxima vez puede que llegase a las autoridades. No por nada, sino porque creo que es de mal gusto y, además, compromete algo más allá del propio blog, que es mi propia credibilidad y mi responsabilidad civil con las leyes vigentes.


En resumen, después de la parrafada anterior: Lobosoft ha vuelto, esperemos que para quedarse. Aunque acciones como la descrita le quitan a uno un poco las ganas de seguir adelante como blogger (al menos de esta forma, con hosting propio), por otro lado inspiran las ganas de mejorar, de modo que la miraré desde esta perspectiva e intentaré que el blog vaya a mejor.


Si estáis leyendo esta entrada, habré sido capaz de restaurar el blog en la noche del martes (lo hago en tanto subo las imágenes y resto del material del blog) y dejarla programada. Mañana miércoles por la tarde espero poder publicar otra con el código del script que instalaron en el blog y un pequeño resumen sobre seguridad en WordPress.


Saludos.

jueves, 20 de mayo de 2010

Primeros pasos con Reflexil (2)

En la entrada anterior veíamos cómo era posible utilizar Reflexil como plugin de Reflector para modificar el valor de una variable, en concreto la que comprobaba nuestra aplicación de ejemplo para permitir el acceso del usuario a la misma. Hoy veremos cómo es posible incluir código propio en un ensamblado .NET para modificar el funcionamiento de la aplicación (inyección de código).

Deseamos que, cuando el usuario haya accedido al programa “crackeado” este realice una serie de acciones; en el ejemplo consistirá únicamente en mostrar un mensaje en pantalla pero podría tratarse de cualquier tipo de comportamiento inesperado. Para ello, creamos una DLL que contiene el siguiente código, la compilamos y la llevamos a la carpeta donde tenemos nuestra aplicación “ContaConta”.

[csharp]
namespace EjemploReflexil
{
public class Sorpresa
{
public static void Infectar()
{
MessageBox.Show("¡Pardillo!", "Sorpresa",
MessageBoxButtons.AbortRetryIgnore,
MessageBoxIcon.Exclamation);
}
}
}
[/csharp]

Partiremos del ejecutable que obtuvimos en la entrada anterior tras sustituir el valor de la contraseña por una cadena vacía (ContaConta.Patched.exe), incluyéndolo en Reflector. El usuario ahora espera utilizar el programa modificado para no tener que introducir contraseña alguna. Cuando el usuario introduce la palabra esperada (ninguna en este caso), la aplicación ejecuta un método que muestra un mensaje de bienvenida. Vamos a insertar una llamada a nuestro método Infectar() de la clase Sorpresa justo cuando esto ocurra.

Lo primero que debemos hacer es incluir una referencia a nuestro ensamblado (Sorpresa.dll).


Damos simplemente el nombre del ensamblado que, recordemos, se encuentra en la misma carpeta que nuestra aplicación:


Reflexil nos avisa de que los cambios que realizamos sobre el código no son visibles de inmediato en las ventanas de Reflector, así que debemos salvar los cambios y proceder a recargar la DLL. Podemos hacerlo desde el menú contextual o en las opciones que habrán aparecido en la zona de trabajo del plugin.


Tras recargar la DLL vemos que el ensamblado aparece ahora referenciado:



Abrimos el código del método Hola(System.String) para proceder a incluir en él la llamada a Sorpresa.Infectar(). Nos situamos sobre la primera instrucción y seleccionamos la opción de crear una nueva operación. Será una llamada (MSIL call) al método que deseamos, de modo que configuramos en el cuadro de diálogo el tipo de operación y de operando.


Seleccionamos, dentro del ensamblado Sorpresa, el método que deseamos llamar


y guardamos los cambios indicando que inserte la operación antes de la que teníamos seleccionada para que esta nueva sea la primera que se ejecute. Ahora guardamos los cambios y ejecutamos la aplicación con el nuevo parche.


Tras pulsar cualquier botón terminaría la ejecución del código inyectado, por lo que la aplicación prosigue con la del código preexistente:


En próximas entradas veremos cómo podemos reemplazar por completo el código fuente de una determinada clase del ensamblado directamente en C# o Visual Basic.NET mediante la opción “Replace all with code...

Primeros pasos con Reflexil (1)

Una de las ventajas de los compiladores que generan código intermedio es que las aplicaciones resultantes (ejecutables y librerías dinámicas) pueden desensamblarse con facilidad, reconstruyendo el código en su lenguaje original. Con .NET Framework esto es posible, incluso, obteniendo el código fuente descompilado al cualquier lenguaje de la CLI (Common Language Infrastructure), como bien sabréis, así que realizar un ejercicio de ingeniería inversa sobre sus ensamblados es algo, a priori (y sin ofuscador mediante), bastante ilustrativo.

Utilizando una de las herramientas que no puede faltar en la particular mochila virtual de cualquier desarrollador .NET, Reflector, es posible no solo descompilar el ensamblado sino incluso reconstruir un proyecto de Visual Studio que permita editarlo y volver a reconstruirlo. Sin embargo, podemos llegar más allá. Es posible, además, editar desde el propio Reflector un determinado ensamblado y modificar su funcionalidad utilizando el plugin Reflexil. Desarrollado por Sébastien Lebreton, se trata de un proyecto de código abierto que podemos incluir como dentro de los add-in de Reflector para extender su funcionalidad permitiéndonos alterar la funcionalidad de un determinado componente de la correspondiente aplicación ya sea inyectando código (en MSIL, C# o Visual Basic.NET) o modificando alguna de sus propiedades. He estado “jugando” un poco con el plugin y me ha gustado tanto que he decidido traerlo al blog aunque sea, de momento, con una introducción muy básica a algunas de las características que podemos encontrar en él.

Partimos de una aplicación realmente básica que simula un formulario de autenticación de usuarios que permitiría acceder a la misma. En nuestro ejemplo simplemente mostrará un mensaje indicando si el usuario introdujo la contraseña correcta o no. El sistema de protección es realmente rudimentario pero nos servirá a título de ejemplo para comenzar a familiarizarnos con Reflexil.


Si no lo hemos hecho antes, deberíamos bajarnos la última versión del plugin de su página oficial e instalarlo (simplemente descomprimirlo y agregarlo a Reflector a través de su menú View->Add-Ins).


Agregamos el ejecutable (o DLL) que deseamos analizar y modificar; en nuestro caso, ContaConta.exe. Si activamos el plugin (Tools->Reflexil vx.y ) veremos cómo, al acceder a un determinado método, campo o propiedad, aparecen diversas opciones que permiten modificar su tipo, los argumentos recibidos e, incluso, su comportamiento.



Por ejemplo, nuestra aplicación comprobaba simplemente si el usuario introducía el texto necesario para permitirle el paso. Una posible modificación sería eliminar esta palabra de paso. Si nos fijamos en las instrucciones en IL del método que se encarga de hacer la comprobación (el propio delegado que se suscribe al evento del clic de ratón sobre el botón Acceder) veremos que comienza situando en la pila de evaluación una referencia al objeto System.String que contiene la cadena a comparar (operación ldstr) para, a continuación, recuperar el valor que contiene el cuadro de texto donde el usuario introduce la contraseña y realizar una comparación entre ambas. Vamos a editar la cadena para sustituirla por una vacía. Para ello, accedemos al menú contextual de la primera instrucción pulsando de ella con el botón derecho del ratón y accedemos a la opción Edit. Veremos un pequeño cuadro de diálogo desde el que es posible editar el tipo de operación a realizar así como los argumentos con los que es llamada. Borramos de aquí el texto del argumento y aceptamos.


Tras ver cómo ha sido eliminado el valor del parámetro en la lista de argumentos, si queremos comprobar que el cambio ha tenido éxito debemos guardar el ensamblado. Para ello, en el árbol de ensamblados de Reflector pulsamos con el botón derecho sobre ContaConta para acceder al menú Reflexil->Save As… y le dejamos el valor predeterminado (ContaConta.Patched.exe).


Si ejecutamos ahora la aplicación y pulsamos simplemente en el botón de acceso veremos cómo nos deja pasar.


En la siguiente entrada veremos cómo inyectar código propio en un ensamblado .NET existente.

martes, 5 de enero de 2010

La web de la Presidencia europea

Estos últimos días he estado en Madrid junto a uno de mis mejores amigos, disfrutando lo posible de él y su compañía y, cómo no, de buena conversación. Entre los muchos temas que tocamos (no todos de índole informática, lo prometo, aun siendo uno de los mejores profesionales que conozco en este, nuestro campo) estaba el de la creación y mantenimiento de la web de la Presidencia europea que ostentará nuestro país en los próximos meses. Con este fin, Telefónica ha recibido 12 millones de euros de las arcas públicas, una cantidad que nos parecía del todo exagerada y que, conociendo cómo funcionan los mentideros, a buen seguro algún cargo de la empresa A asignará una pequeña dotación de esos 12 millones (pongamos, un 5%) a una subcontrata de la empresa B que, a su vez, repetirá este hecho hasta llegar a una empresa X que se encargue verdaderamente de llevar a cabo el trabajo, posiblemente haciendo uso de sus desarrolladores junior porque, al fin y al cabo, se trata meramente de mantener un sitio web.  ¿Qué dificultad tiene esto, o qué problemas podría haber?

Bueno, tal vez nos encontremos con situaciones como esta:


La web de la Presidencia ha sufrido un ataque hacker y la empresa A, la B, C o X no han sabido responder. Los 12 millones de euros sacados de las arcas públicas (que se dice pronto, y parece que no se piensa en que vienen del bolsillo de los ciudadanos) no han servido de mucho. Desde Moncloa se niega que se haya producido verdaderamente el ataque; dicen que la imagen que se está distribuyendo por Internet no es más que una captura de la web modificada para hacer que parezca que la web fue hackeada, ergo, no hemos sufrido ataque alguno. ¿O sí? Porque, según parece, la web ha estado caída durante todo un día y el acceso ha sido irregular durante buena parte de otro. Esto, muy señores míos, es una ataque DoS en toda regla, haciendo uso (si ciertamente la web no fue hackeada para incluir la fotografía y saludo de Mr. Bean) de ingeniería social. Y esto, querida clase política, queridos técnicos míos, es un ataque hacker, queramos verlo o no.

Es vergonzoso que se produzca un comportamiento así (más digno de un lammer que de un hacker, por supuesto), pero no lo es menos que el dinero de todos se invierta con tanta ligereza (¿12.000.000 € para mantener una web?) y que los resultados sean tan penosos. Con mal pie empezamos un liderazgo que no parece tal. Lo peor es que la oposición (especialmente la de mayor peso político) se cebará en un hecho que, muy probablemente, habrían sufrido por igual de estar en su pellejo, y que nadie pondrá remedio a que sigan ocurriendo hechos así.

Ah, entretanto, los informáticos de este país seguimos sin atribuciones profesionales y sin un reconocimiento real por parte del Gobierno. Pero claro, el oficio de informático puede llevarlo a cabo cualquiera, al fin y al cabo es una “materia transversal”. Así nos luce el pelo.

Para saber más:

Actualización (21:10).
En efecto, según parece existe un verdadero problema en la web de la Presidencia española: una vulnerabilidad XSS presente en la página en cuestión ha permitido volver a incluir una imagen en la misma, en este caso, el de la elefanta de Pocoyó. Sin (más) comentarios...

jueves, 3 de diciembre de 2009

La mano que mece la cuna

Después de bastante tiempo sin escribir, vuelvo al blog con una noticia de seguridad que, si bien no tiene mucho donde rascar, sí que creo que es interesante que se difunda. En casa utilizo un antivirus que, hasta la fecha, me ha parecido de lo más potable que hay entre este software en sus modalidades con una versión gratuita para el uso en el hogar: Avast!. Ayer por la tarde se actualizó tanto el motor del antivirus como la base de datos en uno de los equipos que tenemos en casa, y mi pareja continuó trabajando con él. Esta mañana, a primerísima hora, lo he encendido para hacer un pequeño trabajo con él y al poco tiempo de hacerlo me ha aparecido una alerta en la que detectaba un troyano, el Win32:Delf-MZG. Lo he intentado limpiar, he seguido trabajando y al poco rato han empezado a salirme más alertas del mismo problema en otras DLLs del sistema. He empezado a escanearlo y aparecía la memoria infectada, por lo que he reiniciado el ordenador iniciando el proceso de escaneo del Avast! antes de iniciar Windows. Y eso ha sido un caos. Decenas, si no cientos de DLLs infectadas que, afortunadamente, he ido llevando a la cuarentena.


Como tenía que marcharme, y temía que Windows no terminase de arrancar con tanta DLL afectada, y ya que Avast! había limpiado los archivos de inicio de Windows, he abortado el proceso y vuelto a arrancar el equipo. Entré en Windows, actualicé el Avast y procedí a escanear de nuevo. La memoria ya aparecía como libre de virus, y dejé el equipo realizando un escaneo minucioso. Al cabo de las horas, preguntando a mi pareja cómo iba la cosa, me decía que hasta el momento estaba calladito, sin detectar más el troyano. Extrañado (¿antes tantas y ahora ninguna?), barruntando algún tipo de ocultación por parte del troyano, he buscado información sobre el mismo y cuál no habrá sido mi sorpresa al comprobar que se trata de un falso positivo del antivirus, ya corregido en su última versión. El problema ha aparecido en la actualización VPS 91203-0, que incluía la definición de este malware, y ya ha sido corregido. Sin embargo, pueden existir problemas a la hora de recuperar los archivos “infectados” del baúl (y no digamos si elegimos la opción de eliminarlos, lo que obligará a reinstalar esas aplicaciones). Os dejo por aquí algunos enlaces donde se trata el problema, y ya me planteo una tarea para esta tarde: cambiar de antivirus y, de paso, actualizar mi distro de Linux. Un error lo tiene cualquiera, sí, pero no quiero ni pensar en las consecuencias que ha podido tener a nivel mundial, entre los 100.000.000 de usuarios que celebraban los chicos de Avast! no hace tanto.


Lo dicho, cuidaos de quien os cuida.


Más información en:



miércoles, 6 de mayo de 2009

Recursos interesantes

Aquí me tenéis estrenando la opción "QuickPress" de Wordpress, es decir, la de publicación de entradas rápidas y sin demasiada miga. Lo hago simplemente para recomendaros, en un momento, una interesante web que acabo de descubrir y que contiene una serie de Guías de Buenas Prácticas en desarrollo, diseño de arquitecturas, seguridad...


Se trata de la wiki Guidance Share, y podéis encontrarla en el enlace que os dejo.



Saludos.

viernes, 20 de marzo de 2009

WMI Code Creator


Unas de las entradas más populares del blog son, dejando de lado aquellas que cuentan la falacia de intentar descubrir quiénes nos han excluido de su lista de amigos en el Messenger, las que creé intentando explicar el modo de conseguir el número de serie “físico” de una unidad USB, o del disco duro del equipo. Fundamentalmente, el uso que le vienen dando a este código los visitantes que llegan al blog es la protección de nuestro software frente a la piratería. Bien distribuyendo el software con una asociación a un dispositivo USB, bien vinculándolo en su instalación a una determinada máquina, obteniendo de ella información difícilmente sustituible (como el número de serie del disco duro donde se instaló, o el de la placa base o el procesador). Sin ser métodos del todo fiables para proteger el software, sí que pueden servir para evitar una copia masiva del mismo, especialmente entre usuarios poco avanzados, y en tanto no sea tan popular como para que surja un crack o un método de romper nuestra protección de forma masiva.


Recientemente, otro lector del blog me consultaba sobre este aspecto, así que he querido subrayar los dos artículos mencionados con el uso de WMI (Windows Management Instrumentation) para conseguir información del sistema, de una forma clara y sencilla. Pero como no quiero profundizar en el conocimiento de las librerías WMI más allá de lo que ya explica de por sí la MSDN de una forma bastante más profunda de la que podemos tratar aquí, sí que me gustaría dejaros con una herramienta, cortesía de Microsoft, que permite automatizar la creación de código para el manejo de estos dispositivos. Se trata de WMI Code Creator, y consiste en un simple formulario que nos permite examinar la jerarquía de objetos, clases y métodos que podemos consultar mediante WMI, podemos llegar a ejecutar consultas y, para mayor gloria suya, nos genera código de forma automática en tres lenguajes: C#, VB.NET y VBScript. Una gozada con la que os dejo jugando durante el fin de semana.


¡Feliz descanso!

viernes, 13 de marzo de 2009

Huy, mi ejecutable ha crecido

I turn to you oh my precious Jerusalem
Deny your prophets their passion
and treat them like fools
I turn to you oh my poor old Jerusalem
Deny my love but you can't change fate

Nada mejor que este fragmento de la canción Precious Jerusalem, de los teutones Blind Guardian, para recordarnos la efemérides que celebramos hoy (y, de paso, también el pasado mes de febrero, aunque no tuve tiempo de dedicarle una entrada y, ante la expectativa de poder hacerlo en este mes, coincidiendo con otro evento geek y retro como es la Retromadrid, preferí dejarlo estar hasta hoy). Es posible que muchos ya sepáis de qué estoy hablando. Efectivamente, Jerusalem era el otro nombre de uno de los virus más longevos, mediáticos y “queridos” de la historia de la informática: el temido VIERNES 13 (leedlo con voz de ultratumba, ¿a que da miedito y todo? ;) ).


Allá en los años 80, cuando a muchos no nos afectaba el pánico que se reproducía en los noticiarios porque aún andábamos jugueteando con nuestros queridos 8 bits, las empresas de medio mundo temblaban ante la posible aparición del odiado virus. No era el único, ni el más malo, pero sí el más popular. Una vez instalado en memoria, se apoderaba de las interrupciones 08h y 21h (la de reloj y la subrutina del sistema operativo, respectivamente), y se dedicaba a propagarse a discreción por los archivos .EXE y .COM del sistema infectado, y de paso los engordaba un poco (entre 1.808 y 1.822 bytes los .EXE, y 1.792 los .COM). Los días normales, afectaba también al ordenador, introduciendo un pequeño retardo en la interrupción 08h que ralentizaba el ordenador. Pero los viernes 13 sacaba a la luz su lado más siniestro, eliminando todas las aplicaciones que eran ejecutadas


Os dejo un pequeño bloque de su código fuente (bueno, de uno de tantos, ya que fue uno de los virus con más variantes de la (pre)historia de los virus y el malware), en concreto con la comprobación de la fecha del sistema:



mov ah,2Ah
int 21h
mov cs:friday_13,0
cmp cx,07C3h
je ejec_real
cmp al,5
jne add_new_8
cmp dl,0Dh
jne add_new_8
inc cs:friday_13
jmp ejec_real

Feliz viernes 13… ¡¡y mantened actualizado el antivirus!!

martes, 23 de diciembre de 2008

Disponibilidad, nula

La seguridad informática es una disciplina que se dedica a proteger la confidencialidad, integridad y disponibilidad de la información. Para conseguir todo esto, habitualmente se realizan inversiones de mayor o menor índole en la empresa y se contrata a empresas dedicadas a dar soporte y auditar los procesos de la compañía. Pero pocas veces se forma adecuadamente al personal propio, o se le dan unas mínimas directrices a seguir cuando se produce algún problema y ha de seguirse un protocolo que minimice las pérdidas de información y, por ende, pecuniarias.
La semana pasada me encontré con ante un caso así, en el que los servicios on-line que ofrece una conocida Caja del sur de España permanecían indisponibles durante tres días consecutivos. Y lo más grave no fue esto, sino que hacían caso omiso a los clientes cuando daban aviso de la incidencia. Pero permitidme que os cuente la historia completa, desde la perspectiva que pude vivir en primera persona.
Esta “Caja del sur”, llamémosla X, ofrece como tantas otras entidades bancarias diversos servicios a través de Internet, desde la consulta de saldo y movimientos de las cuentas y tarjetas que poseamos en la misma, como la realización de transferencias, gestión de recibos, etc. Hasta ahí, lo normal. El pasado martes (hace, por tanto, una semana exacta) intenté consultar los movimientos de mi cuenta, para ver si había sido adeudada una cantidad determinada. Sin embargo, el acceso no era posible. Tras intentar acceder a la zona de la web en la que hacer login, ésta quedaba totalmente en blanco sin aparecer el formulario de autenticación. Lo dejé estar, porque tampoco me urgía, y terminé por olvidar el asunto.


Un día después, mi pareja me comentaba que no podía acceder a su cuenta, precisamente por obtener el mismo problema. Era tarde, por lo que únicamente les escribió un correo electrónico indicando el problema, pero cuál no sería la sorpresa al constatar, un día después, que la respuesta del servicio de asistencia de la Caja era, básicamente, el siguiente: “A nosotros nos funciona. Limpie las cookies y si no se soluciona el problema, pruebe a reinstalar su Internet Explorer”. Mi pareja, comprensiblemente indignada, les indicó que el problema se reproducía con Firefox y, de paso, también con Explorer. También que usamos a diario CCleaner y el ordenador está limpio, de una sesión a otra, como una patena.





Vaya, con la iglesia hemos topado. ¿Qué YO reinstale mi navegador? ¿Por un problema que se reproduce en tres ordenadores distintos, con tres navegadores distintos en cada uno de ellos (ya puestos, incluí a Chrome en el juego ya que, no os comenté, Google lo sacó de beta la semana pasada), con distintas conexiones a Internet? Molesto por la respuesta que ofrecía la entidad, decidí echar un vistazo a ver qué podía estar ocurriendo. Lo primero fue constatar que las cookies se descargaban correctamente, así como el certificado digital que daba acceso a sus servicios. Hasta ahí, todo correcto. Descargo los ficheros Javascript asociados a la página sin ningún problema, y les echo un vistazo. Vaya, contienen código encargado de la validación del usuario y el control de las cookies. Bueno, vamos a depurar. Accedo a la página con Chrome, habilitando el inspector de recursos. Et voilà: error en la carga de uno de ellos, acceso.js. Ay amiguitos, que estáis usando una variable sin declararla. Habilito el depurador Javascript, y comienzo la ejecución paso a paso del código. Para entonces ya había visto que el archivo contenía una rutina de inicialización consistente, básicamente, en llamar a tres funciones:


recogida_parametros();
analytics();
entrada();


El error está dentro del código de analytics(), donde han incluido funciones de seguimiento de Google. Al depurar ocurría exactamente lo que preveía: se produce el error, y al tratarse de una excepción no controlada el javascript no sigue ejecutándose, lo que provoca que nunca se llame a la función entrada(), que se encarga de hacer un submit automático del formulario y cargar el de login que, por tanto, nunca era mostrado.



Comprobado esto, escribí un correo a la entidad, explicando el proceso seguido, y con varias capturas adjuntas del error. Me contestaron agradeciendo el aviso, e indicando que efectivamente el martes habían hecho cambios y mejoras en la web. Diez minutos después la página estaba nuevamente operativa, pero a su vez tres días después de dar servicio.


Lo grave de todo esto, obviamente, no estuvo en el error en sí (que también), sino en la poca disposición a comprobar lo que los clientes están informando. ¿Qué pueden hacer las empresas para asegurar la disponibilidad de los servicios si sus propios empleados no llevan a cabo correctamente su trabajo? ¿Es realmente necesario que “alguien de fuera” tenga que darles mascado un trabajo tan simple que puede ser depurado y comprobado sin ningún tipo de privilegio sobre el sistema? Mi confianza en esta entidad se ha dañado irremisiblemente, pero esto no es lo malo. Lo malo será que no la recomendaré a nadie, y posiblemente cancele mis cuentas y recomiende hacer lo mismo a mis allegados. Lo malo es que sé que esto no habrá servido de mucho y seguirán haciendo mal su trabajo. Lo peor será que, por regla general, son muchas las empresas que trabajan así. Y en el caso de los bancos, bastante respaldo gubernamental están recibiendo como para que sigan de espaldas a la gente. A sus clientes, reales o potenciales.

domingo, 21 de diciembre de 2008

Fin de semana tardío

Llevo un par de semanas algo alejado del blog porque, por motivos personales, no me es posible dedicarle ahora todo el tiempo que quisiera. De hecho, estimo que esto seguirá así aproximadamente dos meses, hasta que la mudanza se haga efectiva y reorganicemos un poco nuestro habitáculo y nuestra propia vida :) Sin embargo, ahora que se avecina el periodo navideño, imagino que se iniciará un pequeño lapsus en el que poder escribir y retomar el afán bloguero que tanto lució en tiempos pretéritos en Lobosoft. Tengo, además, varios proyectos y artículos a medias, así que conforme vaya cerrándolos los iré subiendo por aquí. De momento, sin embargo, y ya que no pude hacerlo así la semana pasada, os dejo con una serie de lecturas recomendadas, recomendables o, cuanto menos, interesantes. A mí me lo parecieron, a ver si os gustan.


En el blog sobre Apuntes de seguridad de la información, Javier reflexiona sobre las implicaciones que tiene el “barrido informático” que eliminó datos trascendentes de la última legislatura del Partido Popular en el Gobierno. Esta eliminación, de existir, no debió ser fortuita y, por tanto, deberían existir responsables que rindan cuentas sobre dichas acciones. Javier trata este tema eliminando aquellas hipótesis que no habrían sido posibles, hasta sacar unas interesantes conclusiones sobre lo que pudo ocurrir y, de paso, sobre el tema siempre presente, ¿qué somos los informáticos?


Si os preocupa la seguridad y las implicaciones éticas de la informática (por ejemplo, ¿por qué un Gobierno podría, impunemente, destruir información sobre sus actuaciones, que deberían ser rendidas a todos los ciudadanos o, por ejemplo, de qué manera nos vigilan), puede interesaros ver también la entrada que El Proyecto Matriz dedica al tema de la videovigilancia: Alguien nos vigila a todas horas.


Aunque no todo es malo. Personalmente guardo ciertos recelos sobre tecnologías emergentes como RFID, aunque Lonifasiko nos cuenta una buena experiencia con las mismas: su trazabilidad. Lo que demuestra que, de querer, podemos hacer buen uso de la tecnología. El caso es, ¿quieren hacerlo así las grandes corporaciones y gobiernos?


Precisamente por esto deben existir las auditorías y, un tema muy interesante, los análisis forenses. GigA nos trajo un artículo en su blog Todo es Seguro sobre metodologías y la a ISO / IEC 17025:2005 que puede aclararnos un poco qué requerimientos se aplican a laboratorios que realizan ensayos o calibraciones.


En el blog PHP Senior reflexionan sobre la orientación a objetos y los posibles perjuicios en cuanto a rendimiento en el caso de programación PHP, claro está. Si bien es cierto que la orientación a objetos y una excesiva modularización del código pueden resentir en un pequeño grado el rendimiento de nuestras aplicaciones, tampoco es cuestión de bajar a las catacumbas de la programación en ensamblador para optimizar nuestro código (algo que ya hacen bastante bien por regla general los compiladores :) ). Sin embargo, sí es cierto que hoy día es más barato el hardware que el tiempo de los programadores, como viene a contarnos Jeff Atwood en Coding Horror, por lo que es más ventajoso para la empresa un código “mantenible” que eficiente a la hora de ser ejecutado.


Y poco más, de momento. ¡Disfrutad del fin de semana o, al menos, de lo que queda del mismo! ¡Saludos!

miércoles, 10 de diciembre de 2008

50BR3 35CR17UR4 Y 0TR45 H13RB45

Durante un tiempo en el pasado impartí clase a adultos que, en general, tenían escasos conocimientos sobre informática. A ellos, explicarles que, como norma, la contraseña que debían seleccionar para la cuenta de correo que estaban creando en ese momento, debía ser compleja y poco relacionada con ellos suponía un problema que terminaba, no pocas veces, con el olvido de la misma. De poco valía decirles que, a ser posible, la contraseña no debía ser el nombre de su hijo o su mascota, y que al menos debían incluir algunas cifras en la misma (¡¡distintas al año de nacimiento, por San Kernel!! :) ). En cualquier caso, visto el éxito obtenido, cuando me topaba nuevamente con ellos, algo más desenvueltos en los lances de la informática, o tenía a un grupo algo más avanzado, les introducía en los beneficios de la escritura LEET. Sí, es precisamente esa en la que las p414Br45 intercambian algunas letras por números, creando combinaciones legibles con ligeras dificultades para los neófitos de la práctica, pero que trae algunos beneficios asociados. Por ejemplo, puestos a usar contraseñas de longitud suficiente y que incluyan letras mayúsculas y minúsculas, resulta bastante más fácil recordar una frase que una serie más o menos compleja de caracteres, y esta peculiar codificación mejora la seguridad de las contraseñas. Claro que siguen siendo vulnerables a ataques por fuerza bruta o de diccionario, pero aun así el tiempo necesario para romperlas será habitualmente mayor.


Ya os comento que mi mayor interés en este tipo de contraseñas es facilitarle a los usuarios la generación de las mismas dándoles una herramienta que mejore aunque sea un poco la calidad de las mismas, así como la facilidad para recordarlas. Sin embargo, el fenómeno es tan geek que como todos sabréis, ha venido extendiéndose desde los tiempo de las BBS hasta nuestros días. Incluso Google tiene una versión 1337 del buscador, existiendo además traductores automáticos de texto plano a LEET. Para muestra, un botón:


Ya os comento que mi mayor interés en este tipo de contraseñas es
Y4 05 c0m3n70 qu3 m1 m4y0r 1n73ré5 3n 3573 71p0 d3 c0n7r453ñ45 35
`/@ 0$ (0|\/|3|\|+0 q|_|3 |\/|1 |\/|@`/0|2 1|\|+3|2é$ 3|\| 3$+3 +1|*0 [)3 (0|\|+|2@$3ñ@$ 3$

¿Y vosotros, qué opináis de este tipo de trucos nemotécnicos? ¿Los veis útiles para su uso cotidiano por parte de los usuarios?

viernes, 5 de diciembre de 2008

De puente a puente...

Llega un nuevo fin de semana y, siendo algo más prolongado de lo habitual, es el momento ideal para ponernos al día con tantas cosas como quedan pendientes debido al ajetreo diario y la semana de trabajo. Entre otras, podríamos citar las lecturas atrasadas, probar tal o cual elemento que despertó nuestro interés (desde software a un dispositivo del tipo que sea), investigar un poco o, simplemente, descansar. Sirvan como propuestas algunas de las lecturas que despertaron mi interés durante la semana, y alguna que otra situación que me resultó curiosa.


Empiezo, como viene siendo habitual, dando un pequeño (brevísimo) repaso a algunas entradas de blogs de informática que me llamaron la atención. El primero de ellos es un nuevo descubrimiento, el blog de Versvs que he llegado a conocer gracias a la entrada que publicaba días atrás Sergio Hernando, y que os recomiendo encarecidamente. De su autoría es también el libro La sociedad de control, un texto más que interesante que he empezado a leer con fruición, y que por lo que veo en su web ya está a la venta en formato, digamos, tradicional. Así que una buena descarga para disfrutar y aprender (a la par que reflexionar) estos días, y un (auto)regalo seguro.


Muy relacionada con esta sociedad de control, en los últimos días se han producido bastantes manifestaciones de repulsa en contra de la última jugada del Gobierno en connivencia con la siempre “amiga de los niños” SGAE. Se trata, claro está, de la ingeniosa, imaginativa y singular campaña, Si eres legal, eres legal. Me habría gustado escribir algo al respecto, pero la verdad es que la semana vino un poco cargada y apenas pude preparar ese par de entradas que “adornaron” el blog, más parado que nunca. Sin embargo, material de lectura hay, y mucho. Os recomiendo, por ejemplo, las entradas de Informática Verde, de Mangas Verdes (que es un punto de entrada a muchas otras que giran en torno a la misma cuestión). Por cierto, y aunque no venga al caso más que por el nombre de la campaña: si eres informático, ¿qué se supone que eres? Curioso dilema, digno de figurar en alguno de los libros de Smullyan, ¿verdad?


En fin, ya que sigo hablando de libros os voy a recomendar otro. Viene directo de la imprenta del Imperio, pero resulta muy interesante. Es la Application Architecture Guide 2.0 del grupo de patrones y buenas prácticas de Microsoft. Es un documento Beta 2 (que debe ser algo así como 0.0.0.1.1), pero que ya os adelanto que pinta bien. Podéis descargarlo desde su página web y es free, colegas. Otra lectura para la saca.


Seguimos con la programación, y en esta ocasión con el blog PHP Senior, de Enrique Palace, que también resultar ser un descubrimiento reciente, de la última semana, gracias a una serie de artículos-guía que debe seguir un programador para convertirse en un as del PHP. De hecho, lo que buscaba no era eso, sino buenas prácticas en programación orientada a objetos para brindar lecturas interesantes a unos alumnos de .NET, y en cualquier caso, como os digo, resulta un blog con artículos de calidad. Por cierto, días después me sorprendí encontrando un enlace desde el blog de DES, en un artículo sobre buenas prácticas de desarrollo.


Se me quedan en el tintero bastantes cositas de interés, como siempre, pero no quería despedir la semana sin recomendaros una página que vi a través de Eco Microsiervos. Se trata de un buscador inmobiliario (Real State Tool) que se encarga de encontrar la vivienda ideal en función de nuestra vida diaria (familiar). Le damos información sobre nuestros trabajos, la escuela de los niños, la dirección de la biblioteca que más frecuentamos o nuestro gimnasio, y se encarga de buscar la localización más idónea para la vivienda, minimizando los desplazamientos hasta el lugar. Una forma más de ser un poquito más eco, y perjudicar menos nuestro medio ambiente. Por lo pronto he hecho la prueba y creo que a mi querida Lycis le daré una alegría. Nos sugiere mudarnos (lo haremos en breve) a una zona que ella se había planteado.



¡Buen fin de semana!