Novedades en la categoría Criptografía
Ahora que capté su atención estimado lector, le cuento que no se trata del Luciano Bello de la foto, quien, a pesar de sus intentos de poner cara de inteligente, no creo que se dedique a la informática.
No, el Luciano Bello en cuestión es un hacker argentino, quien se tomó el tiempo de leer el código de la implementación Open SSL de Debian, y encontrar un fallo bastante serio (Debian la base de la distribución Ubuntu) y otros.
El bug estaba desde 2006, y demuestra, una vez más, que el software libre no es más seguro "per se".
También demuestra que tampoco es cierta la mal llamada Ley de Linus, acuñada por Eric Raymond, quien postula que al haber muchos ojos mirando el código todos los bugs son evidentes.
La verdad, es que aún habiendo suficientes ojos, igual se pasan los bugs por entre las patas de los desarrolladores.
Lo mejor de todo este incidente es la tira de XKCD de hoy:
Una oscura nota del New York Times indica que Adi Shamir (la S en el algoritmo RSA) sospecha que los bugs matemáticos, como el encontrado en Excel, o los que afectaron al Pentium en 1994, pueden abrir una brecha en los algoritmos de llave pública y privada.
Al parecer Shamir ha enviado una nota de circulación restringida entre distintos criptógraficos indicando que una organización de inteligencia, que supiera del fallo en el diseño de un chip distribuido a larga escala, podría enviar mensajes específicos (envenenados) a un sistema y descubrir las claves secretas.
Esto es interesante, porque estaría revelando una potencial falla del algoritmo RSA, como sugiere Jean-Jacques Quisquater, profesor e investigador en criptografía de la Universidad Católica de Lovaina, en Bélgica.
En general los criptógrafos son bastante paranoicos con estas cosas, y supongo que la nota de Shamir debe ser bastante reveladora, pero mientras no se haga pública no nos va a quedar claro cómo aprovechar estos bugs.
Especulo que el temor de Shamir es que si uno sabe que cierta operación matemática tiene un bug que se gatilla con ciertos números específicos, (como por ejemplo, al multiplicar 77,1 por 850), entonces se podria enviar un mensaje cifrado "armado de cierta manera" con estos numeros "venenosos" al sistema que se quiera atacar comprometiendo sus claves por un efecto de la acumulación de errores intermedios.
Aprovecho de comentarles que el investigador Chris Lomont, ha logrado hacer una ingeniería en reversa del bug de excel, y habría demostrado que el problema es sólo de presentación, y que internamente los cálculos de Excel son correctos.
Al parecer la causa del bug estaría al migrar un trozo de código en assembler desde 16 bits a instrucciones en 32 bits. Para los que tengan la paciencia, o la curiosidad, la explicación detalla está en el artículo publicado por Chris Lomont.
El año 2005 escribí un artículo en codeproject donde mostré un esquema práctico que explotaba una de las vulnerabilidades encontradas en ese tiempo al algoritmo MD5. El artículo alcanzó notoriedad al ser destacado en Slashdot, y en Kriptópolis.
Mi artículo original está en inglés y hay un (muy breve) resumen en este mismo blog.
La verdad es que no me preocupé much más del tema, y no estaba enterado de los derroteros que siguió esta prueba de concepto, pero haciendo una investigación reciente encontré el trabajo de Peter Selinger, profesor e investigador de la Universidad de Dalhouse en Canada que extendió mi esquema aprovechando el resultado de Patrich Stach, que permite aprovechar los posteriores descubrimientos sobre las fallas de este algoritmo.
Otra sorpresa es que este trabajo ha sido mencionado como una herramienta anti forense en círculos de hackers éticos.
¿De que se trata todo esto, y que implicancias tiene?
Les voy a dar un ejemplo.
Cuando ustedes van a un sitio donde se encuentran las imágenes de disco de Ubuntu encontrarán un archivo llamado MD5SUMS que en el caso de Ubuntu 7.10 contiene lo siguiente:
ebf7ad055bc39634065daa10de980d7e *ubuntu-7.10-alternate-amd64.iso
9a4ae3cfd68911a861d094ec834c9b48 *ubuntu-7.10-alternate-i386.iso
61c87943a92bc7bf519da4e2555d6e86 *ubuntu-7.10-desktop-amd64.iso
d2334dbba7313e9abc8c7c072d2af09c *ubuntu-7.10-desktop-i386.iso
43ff753b260729b12c7d21d3a6db8c73 *ubuntu-7.10-server-amd64.iso
7d88cd87df509a740d9f47b9bbf1375e *ubuntu-7.10-server-i386.iso
5308a79f5e652edba5be84644ee14b09 *ubuntu-7.10-server-sparc.iso
La serie de numeros y letras a la izquierda de cada nombre nos indica el valor resultante al aplicar el algoritmo MD5 al archivo de la derecha.
En este caso, para la imagen del CD ubuntu-7.10-desktop-i386.iso el valor MD5 es d2334dbba7313e9abc8c7c072d2af09c.
Para validar de que nuestra imagen es la correcta, lo más seguro es aplicar un cálculo del hash MD5 en el archivo descargado y comprobar que coincida con lo informado en el sitio oficial de Ubuntu. Si estos valores coinciden sabemos que el disco no ha sido saboteado ni alterado por nadie.
Esto impide que un hacker malicioso pueda infectar Ubuntu con un virus o un trojano, ya que el hacker tendría que crear una imagen iso similar, reemplazarla en el servidor y asegurarse de que que el valor MD5 de su archivo coincida con lo informado por Ubuntu.
Hasta ahora eso parecía imposible, pero como demostré en el 2005 es muy sencillo escribir un programa extractor que burlara este mecanismo de verificación, aprovechando los fallos al algoritmo MD5 (descubiertos en ese tiempo por Xiaoyun Wang and Hongbo Yu de la Universidad de Shandong en China).
El problema con mi esquema es que requiere la distribución del programa extractor, pero la prueba de concepto de Selinger elimina esta traba.
Selinger es capaz de crear un programa "auto extractor", con lo que deja inutilzable la "firma MD5" como medio de validación de la integridad de los archivos.
Si pensamos en los archivos ISO con que se distribuyen las imagenes vivas de Ubuntu, y otros sistema operativos, estos archivos son "auto ejecutables", y por lo tanto aplica el esquema propuesto por Selinger.
La puerta está abierta para distribuir troyanos infectando cualquier distribución de linux que use MD5 como único mecanismo de validación.1
No es dificil imaginar una extensión al programa de Salinger para genera imagenes ISO maliciosas de muchos sistema operativos distribuidos de esta manera.
Por supuesto esta prueba de concepto también inhabilita el uso de MD5 como base para construir MAC (Message Autentication Code) en registros, transacciones o documentos digitales.
En este caso es más sencillo romper este mecanismo de control, porque los MACs siempre son ejecutados por programas externos, y para esto basta usar un esquema como el que describí en mi artículo original.
Han pasado 2 años de que sabemos estas cosas y aún me encuentro con implementaciones en que usan MD5 como un mecanismo de autenticar transacciones.2
Pero lo peor, es que todavía me topo con sistemas que proclaman su alto nivel de seguridad porque las claves de sus usuarios son almacenadas en MD5, algo no recomendado antes del 2005, y que aún sigue usándose.
¿Entienden ahora por qué aparte de orgullo siento preocupación?
[1] Insisto en lo de único mecanismo de verificación, porque en muchos casos se usan otras códigos de autenticación adicionales o complementarios, como firmas PGP o dos valores de hash, uno MD5 y otro SHA-1 por ejemplo.
[2] Lamentablemente muchos usuarios no saben o no se preocupan de verificar la integridad de las imágenes de los archivos descargados, así que muchas veces los hackers no necesitan algo tan complicado para vulnerar la distribución de sofware.
La conjunción de Biometría con Criptografía ha dado un nuevo paso con la publicación del paper Fuzzy Vault for Fingerprints por U. Uludag, S. Pankanti y A. Jain. del Michigan State University Biometrics Research Group.
Esencialmente el algoritmo oculta una llave de 128 bits en una nueva estructura, el fuzzy vault, un almacén virtual que no contiene la llave en sí, sino que los coeficientes de un polinomio, que sólo puede ser reconstruido con la adquisición de las minucias de las huellas.
El siguiente es un diagrama del algoritmo (haz click en él para verlo en detalle):
.
Una descripción en inglés se puede leer en darksideprogramming.
De acuerdo a Niels Ferguson el gran problema es que MD5 aún se usa en muchas partes y toma mucho tiempo hacer el cambio de un algoritmo. Steve Bellovin apunta que toma un año lograr el cambio a través de la IETF y entre cinco a siete años que este sea adoptado.
Ya sabemos que al menos Microsoft ha decidido que MD5 no debe usarse en sus desarrollos internos.
Un interesante comentario a mi artículo http://www.codeproject.com/useritems/HackingMd5.asp de parte de Erik Westermann {dispatches}
La siguiente es una traducción libre del comentario (el original se puede leer aquí: http://www.codeproject.com/useritems/HackingMd5.asp#xx1231841xx
Creo que la intención es demostrar un tipo muy específico de ataque que explota la inherente confianza en el hash MD5. Es una especie de ataque de ingenieria semi-social.1 Crypto-Gram Newsletter, May 15, 2000[^]El ataque mostrado en el artículo ilustra como el distribuidor-autor-etc puede distribuir una "buena" aplicación y luego empezar a distribuir una aplicación dañina explotanto la confianza dada al hash MD5 de la aplicación "buena". De todas maneras, este es un escenario muy específico, y usa vectores predefinidos; sin embargo ayuda a reforzar una verdad fundamentas sobre seguridad.
Bruce Schneier indica que la seguridad es un proceso, no un producto1. Este artículo demuestra un ataque específico que explota la visión de la seguridad basada en el producto..."Este archivo es seguro porque el hash MD5 que recién calcule coincide con el hash MD5 publicado (y bien conocido). El artículo resalta la importanca de establecer un proceso que asume que los producto tienen fallas y maneja la exposición a los ataque y trata en forma efectiva con las brechas.
No podría decirlo mejor, Erik Westermann ha resaltado mejor que yo el objetivo de este artículo, y de paso hemos reforzado una vieja lección, la seguridad es un proceso.
Agradezco la elogiosa mención en Kriptópolis, acerca de mi anterior post: Explotando las colisiones de MD5.
Pero me entero a través del mismo sitio que Microsoft ha decidido abandonar el uso de las funciones de hash bajo ataque, e incluso la función criptográfica DES, mas detalles aquí: http://www.kriptopolis.org/node/1126 y aquí: http://www.eweek.com/article2/0,1759,1859751,00.asp.
Me habrán leido en Redmond? :)
Como saben, escribí un par de artículos en CodeProject, el primero, Good Bye MD5, lleva menos de un mes y ya ha tenido cerca de 20.000 lecturas, incluso con un interesante debate.
Mi segundo artículo "Exploiting MD5 collisions" en que muestro como explotar el ataque a MD5 para perturbar los sistemas de distribución de software, lleva cerca de las 2000 lecturas en menos de 48 horas.
No es que me las quiera dar de genio, pero la verdad es que esto se sabe desde casi un año, y la base del ataque:
MD5(x)==MD5(y) => MD5(x+q) == MD5(y+q)desde hace mucho más tiempo.
Las bases de datos, y el algoritmo de las tablas Rainbow se conoce desde el 2003.
Lo que pasa es que ahora, tenemos las bases para crear esquemas para romper la seguridad basada estos algoritmos.
De hecho el esquema que presenté, es un tanto burdo, pero el paper de Kaminsky , en que describe el script en perl stripwire, me lleva a pensar, que es posible construir un ejecutable auto extraible, con un MD5 confiable, pero con un comportamiento dañino.
Es cuestión de tiempo...
Piensen por ejemplo, que la distribución de los archivos .RPM RedHat usan MD5 checksum, que tal si un hacker quiebra el utilitario RPM.
O si uno coloca código malicioso en utilitarios como tar, o gzip, y con eso se deja vulnerable los MD5 de Apache, solo por mencionar algunas consecuencias.
De hecho el ejemplo de los 2 archivos postscript, es un ejemplo de un autoejecutable atacado con la colision de MD5.
