Lo que pasa es que creía haber visto una herramienta que te decía qué CAs tenían un certificado firmado usando MD5… por eso decía que eso no ayudaba. Sí ayuda lo que tu comentas, no fiarte de los que firmen en MD5.

Espero que pronto sean pocos y que no se pasen a SHA-1… que busquen algo mejor pues ‘los expertos’ opinan que SHA-1 sufrirá de problemas similares en poco tiempo. Yo lo he oído decir a uno de los autores de este ataque ( Benne de Weger ) en clase en Eindhoven el año pasado, y creo recordar que dijo que su opción en ese momento sería usar SHA-256. Quizás SHA-512 sea ser un poco bestia :D

Saludetes!

Evidentemente, ya comento en el post que el ataque es algo más complicado, puesto que intervienen una rogueCA y el tema que comentas de la predecibilidad del número de certificado (ayudado por ser secuencial y porque fueron capaces de estimar que si hacían coincidir los 3 días que requería el cálculo con un fin de semana solo se firmaban aproximadamente 1000 certificados). Se ha intentado explicar “el concepto” de forma simplificada para que resultara más didáctico, pero agradecemos igualmente tu aportación dando detalles más precisos.

Sólo una puntualización con la que no estoy completamente de acuerdo: “Tampoco resuelve nada quitar la confianza en las CAs cuyo certificado esté firmado con MD5, ya que en ese certificado el atacante no ha podido incluir esos ‘pocos’ bytes necesarios para ayudar a forzar la colisión”

Más que las que está firmadas utilizando Hash MD5 serían aquellas que firman sus certificados utilizando un Hash MD5. El éxito del ataque es conseguir, de alguna manera, instalar el certificado de la rogueCA en la base de datos de certificados de confianza del navegador, porque a partir de ahí se puede generar certificados para cualquier web, firmarlos con esta CA, y eso será automáticamente aceptado como válido por el navegador. Para ello, lo que hacen es utilizar el Hash firmado por la CA de confianza X de un certificado especialmente preparado para aplicarlo al certificado de un rogueCA, cuyo contenido ha sido ya calculado para que sea coherente y además para que su hash colisione con el del certificado “legítimo” que ha firmado la CA de confianza. Una vez hecho esto, se dispone de una CA propia con la que podemos firmar cualquier certificado, y que además, a ojos de todos, es de confianza para la CA X. Por eso, la primera vez que nuestro navegador visitara una web con un certificado firmado por esta CA, este comprobaría que CA lo ha firmado, encontraría la rogueCA, que desconoce, pero cuyo certificado está a su vez firmado por una CA que sí que es de confianza, por lo que “los amigos de mis amigos son mis amigos” y la incluye en su base de datos de CAs de confianza (visita la prueba de concepto modificando el reloj de tu equipo y luego mira tu lista de certificados de confianza, verás como ha aparecido el rogueCA que ellos han generado como prueba de concepto entre ellos).

¿En que solucionaría retirar de nuestra base de datos de CAs de confianza a las CAs que firmen certificados con MD5? Pongamonos en el ejemplo anterior, sé que la CA X firma certificados usando Hash MD5, y por lo tanto la elimino de mi base de datos. ¿Que pasará cuando alguien intente suplantar una web legítima mediante un certificado firmado por la rogueCA? En primer lugar desconocerá la CA que ha firmado el certificado de la web, verá que esta a su vez está firmado por otra CA llamada CA X, con lo que comprobará en su base de datos si esa CA X es de confianza y por tanto si esa rogueCA también lo es. Tras buscarla, no la encontrará (la hemos eliminado), por lo que rechazará el certificado de la CA rogueCA, y por tanto el certificado de la web que intenta suplantar.

Saludos y muchas gracias por tu comentario TuXeD, y perdona lo del símbolo menor, ya sabes, la seguridad es la seguridad :P

———-

Hola,

Yo no me considero un experto en criptografía, pero algún conocimiento al respecto sí tengo. Esto viene de mi cabeza directamente sin verificación, así que puede haber algún error. Si es así agradecería que me lo comentarais :)

Es evidente que cualquier método que pase de N bits a k menor que N bits va a tener colisiones. De hecho, si pruebas 2^k+1 combinaciones, seguro que 2 de ellas tienen el mismo hash. O lo que es lo mismo, hablando de md5 (128 bits), si pruebas 2^128 combinaciones seguramente dos de ellas tengan el mismo resultado. Obviamente, si tienes 128 bits no puedes tener más de 2^128 salidas distintas, así que con ese número de entradas va a haber una colisión.

El truco está en que por una parte 2^128 es muy costoso de probar, y por otra las colisiones además deben tener sentido (meaningful collisions). Para atacar estos algoritmos no nos vale en encontrar ‘una colisión’ sino que necesitamos que el destinatario ’se lo trague’.

Que por cierto, un algoritmo de hashing se suele considerar roto cuando se conoce un ataque mejor que un ‘birthday attack’, que en teoría necesita de 2^(n/2) ejecuciones del algoritmo de hash para obtener una colisión, con n igual al número de bits de salida. De ahí que en general los algoritmos de hash usen el doble de bits que los cifrados de bloques.

Si imaginamos una colisión en una firma de un ejecutable, debemos no solo conseguir MD5 idénticos, sino que el resultado de la colisión tenga el formato adecuado (PE o ELF o lo que sea) y además funcione de la manera que el atacante quiere.

El ataque del que hablamos se basa en el método de ‘chosen-prefix collisions’. El atacante puede elegir el principio de los dos mensajes arbitrariamente, luego en uno de los mensajes necesita 728 bits (si no me falla la memoria) que crean un ‘bloque de colisión’, en el segundo necesita más bytes para forzar la colisión, y finalmente detrás de esos bloques viene el resto del mensaje, que debe ser idéntico en ambos casos.

También quería comentar que la parte donde dice “descargar el certificado con la clave pública del host (que se puede descargar desde el propio host) y calcular un certificado (con su clave pública y privada) cuyo contenido tenga como resultado el mismo Hash MD5 que el certificado original” no es del todo cierta.

Lo que se hace es hacer una petición de un certificado a una CA online, que tras haberla estudiado sabían que los IDs, la fecha de creación y de expiración eran predecibles. De esta forma, conocían toda la información de la parte que la CA iba a firmar, y podían modificar a su antojo la clave pública RSA. Por tanto, esa petición tenía una clave RSA en la que se había añadido ese ‘bloque de colisión’.

Luego, con 3 días de antelación realizaban los cálculos de la colisión y generaban el nuevo certificado ‘mágico’. Cuando la CA les devolvía el certificado, si su predicción de fecha y números de serie se había cumplido ganaban la partida, si no perdían. Esto les costó 4 peticiones, hechas durante 4 fines de semanas consecutivos, y menos de 700$ si no me falla la memoria.

Respecto a descartar certificados firmados con MD5, realmente no es esa la solución. Teniendo una CA que cuyo certificado es de confianza para los navegadores (valida toda la jerarquía de certificados hasta una CA raiz), el atacante podría firmar el certificado final con lo que le diera la gana.

Tampoco resuelve nada quitar la confianza en las CAs cuyo certificado esté firmado con MD5, ya que en ese certificado el atacante no ha podido incluir esos ‘pocos’ bytes necesarios para ayudar a forzar la colisión.

La solución aquí pasa por que las CAs lo arreglen, y esperar que nadie haya hecho esto antes ;)

De todas formas, no creo que nadie se haya preocupado demasiado de realizar este ataque porque el 90% de los usuarios ‘tragan’ ante un certificado inválido con un mitm. La gente no lee los mensajes de alerta y le da a aceptar y se queda tan ancha.

Por lo que a mí respecta, parafraseo una de las últimas transparencias de la presentación de este ataque: “Don’t panic, the Internet is not *completely* broken”.

Ah, hay un video de la presentación en el FTP del CCC. En los videos la han titulado ‘Making the theoretical possible’. Podeis ver esta y las otras charlas en: http://ftp.ccc.de/congress/25c3/video_h264_720×576/

Saludos

No soy un experto en criptología y criptoanálisis, pero la lógica me dice que cualquier método que nos podamos inventar que pase de un mensaje de tamaño N a un mensaje de tamaño menor que N va a sufrir siempre de este tipo de problemas.

Como esta es la naturaleza de los algoritmos de Hash (sirven precisamente para verificar el contenido de un mensaje sin tener que manejar el mensaje entero, cuyo tamaño puede ser variable), supongo que siempre existirán matematicamente las colisiones.

La fortaleza del algoritmo de Hash radica en la dificultad para encontrar estas colisiones, es decir, precisamente por tratarse de un algoritmo de “cifrado en un sentido” (One-Way Encryption), si un algoritmo de Hash fuera “perfecto” (si es que eso existe) tendriamos que recorrer todos los posibles mensajes de entrada, de todas las longitudes posibles, y al final podriamos encontrar dos mensajes que tuvieran el mismo resultado al aplicarles el algoritmo de Hash. Sin embargo, como te puedas imaginar, recorrer todos los posibles mensajes de entrada es imposible, puesto que son infinitos.

Si el algoritmo tiene alguna debilidad, pues se podría acortar el espacio de posibilidades.

Cuando se estima que en el momento actual es posible comprobar todas las posibilidades en un tiempo razonable, bien porque la potencia de los procesadores ahora lo permite, bien porque se ha descubierto una vulnerabilidad en el algoritmo que permite reducir el espacio de búsqueda hasta una cantidad manejable de pruebas, entonces se dice que “se ha roto” un algoritmo de Hash.

De hecho, probablemente, dado un algoritmo de Hash, existan estudios matemáticos que definan cual es el tamaño del espacio de entradas que asegura que exista al menos una colisión entre ellas.

Como ya he dicho, no soy experto en criptología, por lo que mi respuesta puede no ser 100% precisa. Si alguno de nuestros lectores es experto en criptología, por favor, que nos escriba :)

Saludos, muy interesante tu página :)

Es un plugin para Firefox que detecta tanto los certificados débiles debido a la archiconocida vulnerabilidad de Debian como los certificados firmados mediante MD5 y que por tanto pueden ser susceptibles de realizar sobre ellos un MitM sobre el que forzar la instalación de un RogueAP.