Rogue CA

El pasado día 30 de Diciembre en la 25th Chaos Communication Congress (25C3) en Berlín, un grupo internacional de investigadores (principalmente Estadounidenses, Holandeses y Suizos) anunciaron que habían conseguido explotar la conocida debilidad ante colisiones del algoritmo de Hash MD5 para realizar un ataque real contra la infraestructura de PKIs.

Para ello realizaron una búsqueda de aquellas CAs que en su funcionamiento aún no han substituido el uso de algoritmos MD5 por SHA-1, para ello buscaron en las webs presentes en Internet aquellos certificados que al ser firmados por la CA correspondiente habían sido marcados como "MD5 firmado con X", y de esta manera obtuvieron una lista de 6 CAs candidatas a ser vulnerables.

De entre ellas, seleccionaron la CA FreeSSL para realizar su prueba de concepto. Además de usar el algoritmo de hashing MD5, la generación del número de serie del certificado es secuencial, por lo que facilita enormemente la realización del ataque.

El ataque consiste en que, dado que lo que firma una CA con su clave privada (secreta a ojos de todos salvo a si misma) es un Hash de la información contenida en el certificado que firma, si conseguimos dos certificados cuyo contenido, al aplicarle el algoritmo de hash, tengan el mismo resultado, podriamos dar a firmar uno de ellos a la CA y automáticamente ese Hash firmado sería válido para el segundo certificado, aunque la CA no haya "visto" ni tenga ninguna constancia del contenido de este. Ahí es donde entra en juego la debilidad del algoritmo MD5.

De esta manera, este grupo de investigadores crearon dos pares de certificados, uno de una web que dieron a firmar a la CA elegida para la prueba de concepto y otro que se trata de un Rogue CA, es decir, un par de certificados que podrán usar posteriormente para firmar otros certificados.

Evidentemente, obtener dos pares de certificados coherentes y que sufran un colisión MD5 no es una tarea fácil, para ello tuvieron que utilizar el Playstation Lab, un cluster formado por 200 Playstations 3, lo cual les permitió disponer de una gran capacidad de cálculo, y con el que tardaron aproximadamente 3 días en obtener los certificados.

Una vez obtenido los certificados, dieron a firmar el certificado de la web a la CA vulnerable, esta utilizó MD5 y lo firmo. Ese MD5 firmado fue trasladado al certificado público del Rogue CA, con lo que a todos los efectos, todos los navegadores (por poner un ejemplo) que confien en la CA vulnerable van a confiar en esta Rogue CA, puesto que a sus ojos parece ser de su confianza (ha firmado su certificado, o no?...).

Esto va a permitir al poseedor de esta Rogue CA crear certificados para CUALQUIER WEB de Internet y firmarla, con lo que un intruso podría utilizarlo para suplantar la identidad de equipos y realizar ataques MitM.

Pondamos un ejemplo, acabo de conseguir hacerme con un Rogue CA como el que han obtenido este equipo de investigadores. Creo un par de certificados para www.banco.com y los firmo con esta Rogue CA (puedo hacerlo, tengo tanto su clave pública como su privada, lo he creado yo!). En ese momento estoy en disposición de hacer un ataque MitM de algún tipo contra el objetivo, de tal manera que cuando un usuario visite en su navegador https://www.banco.com este se traerá el certificado que he generado, y verá que está firmado por una CA que no reconoce. En una situación normal nos aparecería la típica ventana en nuestro navegador de "este certificado está firmado por una CA que no es de confianza". Sin embargo, en este caso, esta CA, aunque no sea de confianza, está firmada por una CA cuyo certificado sí que está entre los certificados de confianza de nuestro navegador (el de la CA vulnerable), con lo que reconoceremos esta CA como de confianza, y se añadirá a nuestra lista de certificados de confianza:

Una vez que el certificado de nuestro Rogue CA está añadido al navegador como una CA de confianza, cualquier certificado que firmemos con ella estará automáticamente aceptado por el nevagador, es decir, la persona que visita www.banco.com va a acceder a la web sin ningún tipo de aviso de suplantación de certificado, pero sin embargo va a estar aceptando este certificado creado por nosotros, por lo que toda su comunicación podrá ser descifrada y alterada por la persona que realiza el ataque.

Los descubridores de esta vulnerabilidad han desarrollado una prueba de concepto para la cual debereis configurar la fecha de vuestro equipo en Agosto del 2004, no porque sea una limitación del ataque, sino porque han publicado todos los certificados que han empleado, y si no utilizaran un certificado caducado estarian dandole a cualquier atacante todas las herramientas necesarias para realizar este tipo de ataques sin necesidad del cluster de PS3s. Después de acceder a esta web y sin que os dé ningún aviso, podeis revisar la lista de certificados de CAs de vuestro navegador y podreis ver como se ha añadido automáticamente a la lista (ver la imagen anterior).

El ataque, como supongo que estais pensando, parece sencillamente terrorifico, puesto que los certificados parecían la única manera de asegurar que estabamos accediendo a donde creiamos, y parecía la manera de superar ataques de MitM de todo tipo (DNS, ARP, cualquiera). El problema que tiene el modelo de autoridades de certificación es que se basa en la confianza, por lo tanto basta que uno de las CA sea vulnerable a un ataque como este para que la seguridad de todo el modelo se vea comprometida (como pasa en este caso).

Como contramedidas, en mi opinión tenemos dos posibilidades:

1. Editar los certificados aceptados por nuestro navegador y eliminar todos aquellos que empleen el algoritmo de Hash MD5 para la firma. De esta manera impediremos que nuestro navegador confie en los certificados emitidos por esta CA, con lo que nunca reconocerá la autoridad del Rogue CA, con lo que evitaremos el ataque. Sin embargo, tiene un par de incomodidades, la primera es que requiere ir a nuestro navegador, revisar todos los certificados (que son muchos) y eliminar uno a uno (o montarnos algún sistema automático) los certificados de las CAs que puedan causarnos problemas. La segunda incomodidad es que no vamos a confiar en ningún certificado firmado por estas autoridades, sea legítimo o no, por lo que podemos encontrarnos con sitios que en principio debían estar autorizados pero que al acceder nos mostraré un mensaje de "el certificado está firmado por una autoridad no confiable" o similar. También corremos el riesgo de que el navegador actualice esta lista al aplicar parches y perdamos nuestra configuración. De esto último no estoy seguro, habría que probarlo.
2. Aunque nuestro navegador puede verificar el certificado por medio de la confianza a las CAs, también podemos aceptar un certificado de un host individual y almacenarlo, aunque esto solo es habitual si no se ha podido verificar la validez del certificado por otros medios. De esta manera, otra posible solución sería incluir manualmente en nuestro navegador los certificados de sitios más críticos, de tal manera que tengamos ya almacenado y confiemos en el propio certificado del host, y no tengamos que irnos a las CAs a comprobar su validez, con lo que evitariamos este vector de ataque. Por supuesto, esto solo se puede hacer con un número limitado de hosts.

Las CAs vulnerables han sido avisadas, así que se preveee que en breve sustituyan sus algoritmos.

Voy a hacer algunas pruebas con la segunda solución a ver si sería realmente efectiva y espero poder poner un post en un par de días explicando que es lo que he hecho para evitar este tipo de ataques.