En la siguiente animación se pueden seguir las proyección de los pasos a seguir para lograr el rescate:

Rescate de los mineros chilenos atrapados bajo tierra

La noticia saltó a los medios especializados el 16 de julio. Los primeros detalles indicaban que la vulnerabilidad permitía a un atacante ejecutar automáticamente código al insertar un medio extraíble en el sistema. La crónica y más detalles se puede encontrar aquí:

Interesante (y peligroso) troyano que aprovecha un interesante (y peligroso) 0 day en Microsoft Windows

Ahora el código es público y ni lentos ni perezosos ya lo incluyeron en la archiconocida suite MetaSploit. Aunque ya es posible mitigarlo mediante una Directiva de Seguridad Local, Microsoft no ha publicado aún ningún parche.

Gracias a Un informático en el lado del mal por la recopilación de fuentes.

Protocolos de conocimiento cero (ZKP)

Sabemos que sin un esquema de cifrado de llave pública es trivial para un atacante interceptar la información que se envía entre el cliente y el servidor, pero el sistema debe tener alguna manera de autenticar a los usuarios del sistema. Necesitamos enviar algo que si un atacante intercepta no pueda utilizar para autenticarse. Esto se conoce como un protocolo de conocimiento cero (Zero-knowledge proof), y en palabras coloquiales significa: “probar que poseemos cierta información sin revelar esa información”.

Como comúnmente la única información que queremos “probar que poseemos pero no queremos revelar” es la contraseña, voy a explicar el esquema que usa MySQL para implementar su autenticación de usuarios. Los detalles no están explicados de manera formal en la documentación de MySQL pero alguien se tomó el tiempo de leer el código fuente y explicar cómo funciona (MySQL 4.1.x authentication internals).

¿Cómo se almacenan las contraseñas?

Lo primero que hay que tener en cuenta es que, siguiendo los principios básicos de almacenamiento seguro de contraseñas, éstas se almacenan en el sistema sólo como un hash criptográfico. Que tiene la propiedad de ser prácticamente irreversible y prácticamente único. Por lo que esta es la primera parte del ZKP, ya que sólo quien conozca la contraseña podrá generar el hash criptográfico que le pertenece.

Desde MySQL 4.1 las contraseñas de usuario están almacenadas en la tabla “mysql.user” en la columna “Password” de la siguiente manera: . Donde es el hash criptográfico SHA-1.

La transmisión

Si cada vez que el cliente se quiera autenticar sólo transmitiera , cumpliría con el principio de no revelar la contraseña, pero un atacante podría capturar y enviar después para autenticarse exitosamente aún sin conocer la contraseña. Por lo que necesitamos agregar más cosas al protocolo para que la información que transmite el cliente sólo sea útil para un intento de autenticación.

Este sería el esquema cliente-servidor para la transmisión:

1. Se inicia el intento de autenticación
2. El servidor genera una cadena aleatoria y se la transmite al cliente.
3. El cliente calcula , y (aqui significa concatenación).
4. Finalmente el cliente transmite . (aquí significa bitwise XOR)

Autenticación

El servidor sólo conoce , que está almacenado en la tabla de usuarios, y . Para autenticar hace lo siguiente:

1. Calcula .
2. Calcula .
3. Calcula .
4. Sólo si la autenticación es exitosa.

Observaciones

Nunca se transmite ni , por lo que la fortaleza está en que este ZKP verifica que el cliente conoce y pero sin revelar esa información, y que sería casi imposible que un atacante poseyera sin conocer .

También hay que observar que es una cadena única por cada intento de autenticación, o sea que esa cadena siempre está cambiando.

Implementación

Próximamente trabajaremos en una implementación de este esquema para aplicaciones web usando JavaScript y PHP, que publicaremos bajo licencia LGPL.

Este malware viene incorporado en un screensaver contenido en un paquete .deb que requiere privilegios de administrador para instalarse. Específicamente es un troyano diseñado para formar parte de una Botnet y hacer ataques DDoS.

Las instrucciones para eliminarlo revelan dónde se instala y cómo se autoejecuta:

sudo rm -f /usr/bin/Auto.bash /usr/bin/run.bash /etc/profile.d/gnome.sh index.php run.bash && sudo dpkg -r app5552

Hace tiempo reflexioné sobre este futuro poco alentador en un artículo sobre un troyano en mac. Lo que me lleva a hacer una reflexión que me gustaría que todos los linuxeros nos hiciéramos: ¿cuántas veces has revisado lo que hace e instala un paquete .deb antes de ponerle tu contraseña de administrador?

Eso de creernos invulnerables por usar Linux o Mac OS pronto va a dar frutos, y son frutos podridos. Si se le sigue diciendo a la gente, sistemáticamente, que es invulnerable al malware es casi seguro que caiga en un engaño por exceso de confianza. También pasó con el troyano que venía en la versión de bittorrent de iWork y quién sabe cuántos aún sigan infectados.

Para hacer este tipo de cuestiones existe un sitio que nos permite hacer una comparación general de precio en diferentes cosas: restaurantes, productos básicos, transporte, renta de departamentos, gasolina, internet y telefonía. El sitio es:

http://www.numbeo.com/cost-of-living/compare_countries.jsp

Hoy encuentro una serie de posts referentes a un exploit en concreto en donde explican con cierto grado de detalle los pasos concretos a seguir y los conceptos que hay detrás de un exploit por stack overflow para la aplicación Easy RM to MP3 Conversion Utility.

Exploit writing tutorial part 1 : Stack Based Overflows

Exploit writing tutorial part 2 : Stack Based Overflows – jumping to shellcode

Exploit writing tutorial part 5 : How debugger modules & plugins can speed up basic exploit development

Exploit writing tutorial part 3 : SEH Based Exploits

Exploit writing tutorial part 6 : Bypassing Stack Cookies, SafeSeh, HW DEP and ASLR

Exploit writing tutorial part 3b : SEH Based Exploits – just another example

Exploit writing tutorial part 4 : From Exploit to Metasploit – The basics

Exploit writing tutorial part 7 : Unicode – from 0×00410041 to calc

Y sigue actualizándose.

El NIST, la agencia encargada de definir los estándares tecnológicos para las agencias federales de EEUU, establece que la información con vigencia menor a 2010 debe usar al menos 1024 bits, con vigencia menor a 2030 deberá usar al menos 2048 bits y con vigencia mayor a 2030 deberá usar 3072.

Bruce Scheiner por otro lado en 2002 ratificó una tabla publicada anteriormente por él mismo en donde establece los bits recomendados según seas un individuo, una corporación o el gobierno. Ahí estipula que para 2005 los individuos ya deberían usar llaves de 1280 bits, y el gobierno ya debería estar usando 2048 bits.

Algunos más “inteligentes” que los anteriores, dicen que todos exageran, y recomiendan 1025 bits, razonando superfluamente que eso duplica la complejidad de la factorización. Ese razonamieto surge de pensar que el mejor algoritmo de factorización es por “fuerza bruta” sobre los posibles factores, probando todos los números entre y para factorizar un módulo de 1024 bits, pues sus factores primos son de 512 bits.

La realidad es otra, y desde hace tiempo, desde Fermat de hecho, existen métodos sublineales de factorización de enteros respecto al tamaño del entero y los mismos algoritmos son subexponenciales respecto al número de bits del entero. Por lo que aumentar un bit la llave no es tan drástico como aumentarlo en otros algoritmos como AES, como no es tan drástico multiplicar por dos el tamaño del entero, pues eso no duplicaría el tiempo necesariamente. ¿Pero qué tanto aumenta el tiempo un bit más?

Criba General de Campos Numéricos (GNFS)

GNFS es el mejor algoritmo de factorización de enteros, conocido a la fecha, para enteros de 130 digitos al menos (que son aproximadamente 432 bits). En 2005 el algoritmo se utilizó para romper el récord de factorización RSA para un entero de 640 bits, hazaña que fue llevada acabo por un equipo de investigación alemán. Lo interesante de este algoritmo es su complejidad, y en base a ella voy a realizar algunos cálculos para esclarecer qué tan fuerte es aumentar un bit más a un módulo RSA.

La complejidad del algoritmo está dada por

donde es una constante dada por la heurística utilizada en el algoritmo y es el número a factorizar (no los bits del número). Carl Pomerance, creador del segundo mejor método de factorización, indica que en este caso . Por otro lado tenemos que es una función asintótica que tiende a cero, por lo que para los cálculos se va a considerar como cero, pues Pomerance así lo toma.

Teniendo eso, lo que se puede hacer ahora es calcular el tiempo del algoritmo para factorizar un número de 1024 bits y comprarlo respecto al tiempo para factorizar uno de 1025 bits. Por lo que vamos a denotar al tiempo de 1024 bits y al tiempo de 1025 bits.

Sabemos que un número de 1024 bits se aproxima a y uno de 1025 bits a , por lo que se van a tomar esas aproximaciones para simplificar la exponenciación. Tenemos entonces que

donde es la constante de la notación asintótica.

Por lo tanto tenemos que

Que es muy poco. Pues si el gobierno de algún país contara con los recursos para romper un módulo de 1024 bits en 24 semanas (6 meses), entonces romper uno de 1025 bits les llevaría casi 25 semanas. Esto en el mejor caso, puesto que la complejidad del algoritmo está dada en notación O, así que el algoritmo podría comportarse aún mejor de lo estimado y ser más rápido.

Si hacemos lo mismo y comparamos un módulo de 1024 respecto a uno de 1280, tenemos que . Que es bastante decente, y suponiendo que se pudiera factorizar el módulo de 1024 en una semana, entonces tardarían 8 años y medio en factorizar el de 1280; lo que le da bastante más confiabilidad a ese módulo que a uno de 1025. Aunque un cálculo más correcto sería considerando una ecuación diferencial porque la capacidad de cálculo no va a permanecer 8 años igual, va a ir aumentando.

Pragmáticamente hablando

Seguramente alguno va a desconfiar de este análisis, y necesitará una prueba más terrenal, sin tanta matemática. En ese caso lo invito a bajar un paquete que tenga implementado el algoritmo y factorice un número de unos 450 bits, que se puede hacer en un tiempo bastante decente (unos minutos) y vaya aumentando de bit en bit, para comparar los tiempos. Implementaciones hay varias y se pueden encontrar en la página de la wikipedia sobre GNFS.

La leyenda urbana de que es inseguro borrar información sobreescribiéndola una vez siempre se escuchó de boca en boca, y se tomaba como un dogma de fe. Las herramientas de borrado seguro de información y los estándares de seguridad, dicen que para borrar información de manera segura se tienen que sobreescribir todos los bits 25 veces o más; lo que requiere tiempo y es simplemente una pérdida de tiempo.

Como bien es sabido mediante software la información sobreescrita no se puede recuperar, pero mediante hardware queda la duda. Por ello para desfalcar el mito, Craig Wright, experto en forensia, y su equipo, hicieron un estudio para analizar varios discos duros de distinta manufactura y edad. El estudio consistió en sobreescribir la información en condiciones controladas y luego estudiar las superficies de los platos con un Microscopio de Fuerzas Magnéticas. Así llegaron a la conclusión de que recuperar la información después de una sola sobreescritura tiene una probabilidad que tiende a cero; y, se habla en términos de probabilidad porque reconstruir un bit tiene una probabilidad de 56% y reconstruir un byte completo 0.97%; esto con discos nuevecitos. Pero la prueba más interesante, que fue llenar 32 veces el disco usando dd con /dev/random, para simular un disco usado, y luego sobreescribiendo todo con /dev/zero, arrojó aún menos probabilidad de recuperación.

Así que para borrar un disco duro ya no habrá que reformatear muchas veces el disco, ni comprar herramientas especializadas. Con una distribución Linux live, y un simple dd if=/dev/zero of=/dev/sda será suficiente. Pero si todavía no tienes confianza y crees que rasurarse muchas veces hace salir más barba o que las probabilidades son engañosas, aunque OpenSSL usa una prueba probabilística de primalidad, puedes usar /dev/urandom. Hacer más y perder tu tiempo ya es simplemente ser supersticioso.

[Resumen del artículo original]

He aquí de algunos titulares amarillistas que he encontrado:

Vulnerabilidad en la infraestructura de clave pública
El algoritmo MD5, en peligro
Researchers hack VeriSign’s SSL scheme for securing Web sites
Cómo unos hackers rompieron la seguridad del SSL usando 200 PS3

Hasta sitios que considero de respeto, como Astalavista, cayeron en el juego. Yo preferí leer el reporte orginal de los investigadores e informar breve pero verdaderamente el ataque que realizaron.

Breve introducción

Como alguna vez explicamos, una parte de la seguridad en Internet se basa en el uso de certificados digitales, que dan certeza sobre la identidad de un servidor en Internet. Un equipo de investigadores recientemente publicó una demostración de un ataque que permitió falsificar indetectablemente un certificado digital, firmado por la empresa RapidSSL (filial de VeriSign), y que los navegadores aceptan como parte del círculo de confianza.

El ataque fue factible porque la empresa RapidSSL generaba las firmas digitales, de sus certificados digitales, usando el esquema ‘MD5 con RSA’. El algoritmo MD5 ya se considera inseguro desde hace largo tiempo. Anteriormente se han realizado demostraciones impresionantes, por ejemplo el famoso caso de Nostradamus en donde generaron distintos archivos PDF que tenían el mismo hash MD5. Además desde 2005 ya se había publicado un artículo en donde se exponía cómo usar colisiones MD5 para generar dos certificados digitales distintos que produjeran el mismo hash.

El ataque

Lo que hicieron estos investigadores, para falsificar el certificado, fueron principalmente dos cosas: predecir probabilísticamente cuál iba a ser el siguiente número de serie (del certificado generado por RapidSSL) y generar una llave pública que ocasionara colisiones MD5. La parte más dificil fue construir una llave pública que ocasionara colisiones y construir la llave privada a partir de la llave pública, pues es necesario firmar con la llave privada la petición de un certificado. Se requirió el poder de un clúster de 200 PS3 para hacer los cálculos, además de gastar 657 dólares en la compra de certificados para poder predecir el número de serie.

El alcance de este ataque, como bien dicen ellos, está limitado para aquellas CA (Autoridades Certificadoras) que generen certificados firmados con MD5, y la gran mayoría actualmente firma con SHA-1. Aunque SHA-1 ya no se considera seguro no se conocen ataques de este tipo, pero ellos recomiendan que se use al menos SHA-2 para generar las firmas, porque puede ser que en poco tiempo empiecen a surgir ataques parecidos a los de MD5 y sí va a ser entonces un problema grave para todo el mundo.

En el artículo original se puede encontrar el certificado y una página web de muestra para ver el certificado en funcionamiento. Pero los investigadores se cuidaron de que nadie le dé mal uso a su trabajo, por lo que hicieron que el certificado expirara en 2004 y no publicaron la llave privada. Potencialmente, si se pudiera llevar a cabo este ataque para cualquier certificado, cualquiera podría falsificar la conexión segura de un banco (por ejemplo) y de manera indetectable si se combina con un DNS poisoning o pharming.

Ext3 supuso una mejora respecto a Ext2 al introducir journaling. El journaling es una técnica mediante la cual se lleva un registro de las actividades en el sistema de archivos y facilita la recuperación del sistema de archivos después de una interrupción abrupta (como una falla eléctrica). Cuando se borra un archivo ocurren dos procesos principales: eliminación de la entrada del directorio que lo contiene y marcado de los bloques ocupados como bloques libres en el mapa de bloques; si no se completan los dos procesos el sistema de archivos puede quedar en un estado inconsistente; además detectar y recuperarse del fallo puede toma mucho tiempo, pero con journaling esto se puede hacer de manera más eficiente y segura.

No me voy a centrar en datos sensacionalistas sobre el tamaño de archivos que ahora soporta, o la cantidad de archivos que puede contener cada directorio, ya que eso NO es un diferenciador importante a la hora de comparar sistemas de archivos. Quiero enumerar las nuevas características y mejoras conceptuales que se introdujeron:

• Extents: Los sistemas de archivos derivados de Unix (como Ext3) mantienen un esquema de mapeo de bloques para llevar el rastreo de bloques que pertecen a un archivo, por ejemplo un i-nodo mantiene una lista de bloques de un archivo. Para archivos grandes esto es ineficiente en tiempo y espacio pues el mapa de bloques es enorme, ya que los bloques son de tamaño fijo. Un extent es básicamente un espacio de bloques físicamente adyacentes que ahora se puede utilizar en el mapeo de un archivo; esto mejora el rendimiento, reduce el espacio y reduce la fragmentación.
• Alojamiento multibloque: Cuando Ext3 quiere escribir información a disco, el alojador de bloques decide qué bloques libres van a ser usados para escribir los datos. El problema es que el sistema de Ext3 sólo permite alojar un bloque (4 Kb) a la vez; esto no sólo es ineficiente para el tamaño de los archivos que se manejan actualmente, también impide que se pueda optimizar la asignación de bloques pues el alojador de bloques no sabe de qué tamaño es todo lo que se va a escribir. Con el alojamiento multibloque se pueden pedir muchos bloques al mismo tiempo. Esta característica ayuda a reducir la fragmentación.
• Alojamiento retartado: Esta característica ya viene incluida en sistemas de archivos modernos como XFS, ZFS y Reiser, y consiste en retardar el alojamiento de bloques lo más posible. Lo que pasa actualmente es que cuando un proceso pide escribir a disco, inmediatamente se asigna el bloque al que se va a escribir, aún si la información va a estar en caché un tiempo o si se va esperar un tiempo antes de escribir. Este método trae desventajas como cuando un proceso está escribiendo un stream, ya que no se sabe de qué tamaño va a ser el archivo finalmente. El alojamiento retardado asigna los bloques hasta que realmente se va a escribir a disco, lo que permite optimizar el alojamiento. Esta característica se combina perfectamente con las dos anteriores: extents y alojamiento multibloque; para mejorar el rendimiento y la fragmentación.
• Defragmentación al vuelo: Aunque con las características anteriores la fragmentación se va a reducir en la mayoría de lo casos, ahora existe la opción de defragmentar el sistema de archivos al vuelo. Esto porque en sistemas de alta concurrencia la fragmentación es un gran problema y la leyenda urbana de que Ext3 se fragmenta poco es completamente falsa para un sistema de mediana concurrencia al disco duro. Esta característica no está disponible todavía en el kernel (2.6.28) pero existe una herramienta llamada e4defrag por el momento.
• Prealojamiento persistente: Cuando una aplicación necesite reservar espacio en disco pero todavía no tenga los datos que se van a escribir, se puede prealojar el espacio en el sistema de archivos; esto es que se construyan las estructuras internas del sistema de archivos y se reserven los bloques necesarios. Por ejemplo lo que hacen los clientes P2P es escribir un archivo relleno de ceros del tamaño del archivo que van a bajar, pero esto es sucio e ineficiente. Con el prealojamiento este problema se soluciona y además se reduce la posibilidad de fragmentación.

Además se introdujeron otras mejoras en los i-nodos y en el journal. Un efecto colateral con todas las mejoras es que el fsck ahora va a ser mucho más rápido, por lo que ya no tendremos que desesperarnos cada vez que nuestro Debian necesite hacer un chequeo de disco.

[Fuente]

[Fuente2]