Fundalmentalmente, cuando te conectas a un sitio seguro, para certificar que es seguro, hay un conjunto de empresas que certifican que no sólo nadie puede escuchar lo que envías al sitio, sino que se lo envías al sitio correcto (por ejemplo, tu banco y no a un ladrón).
Esos certificados están basados en producir una cifra criptográficamente segura de un "hash" del contenido a firmar. El problema está en que algunas empresas (autoridades de certificación o CA), aún utilizan como algoritmo del "hash" el MD5, que desde 2004 es teóricamente posible atacar (aunque las dos cosas que tienen el mismo "hash" sólo se pueden diferenciar en 128 bytes de sufijo).
Aún peor, desde 2007 es posible teóricamente un ataque fácil en el que se puede tener dos prefijos todo lo largos que se quieran que se rellenan con 716 bytes y generan el mismo hash MD5.
Como los dos ataques anteriores eran únicamente teóricos, el equipo formado por Jacob Appelbaum, Alexander Sotirov y cinco académicos más, se puso manos a la obra para demostrar el ataque en la práctica.
Primer paso: recoger certificados SSL para ver cuántos usan MD5. Aunque había unos seis o siete proveedores que usan todavía MD5, el 97% de los 9.000 certificados (de 30.000) que había en la muestra estaban emitidos por RapidSSL.
El siguiente paso era genera el par de certificados (el bueno y el malo), para que la autoridad certificase el bueno y ellos pudiesen usar el certificado para el mal. En concreto, lo que hicieron es conseguir una firma para un certificado de un sitio web que era el dual de un certificado de autoridad de certificación, que les permitía actuar como CA intermedia reconocida y en realidad firmar lo que quisieran (como el certificado raíz lo avala, un navegador se fiará también de las autoridades intermedias).
El problema es que la generación de los certificados lleva unos tres días y lo más difícil era predecir el contenido del certificado bueno, ya que para evitar eso el certificado lleva un número de serie y la hora (con resolución de un segundo) de emisión. Afortunadamente para el ataque, los números de serie del proveedor no eran aleatorios sino secuenciales y el número de certificados emitidos el fin de semana y el tiempo de emisión eran bastante predecibles (un certificado se tardaba 6 segundos en emitir).
Bueno, hubo que pagar bastantes emisiones de certificado de relleno para poder conseguir dar en el clavo (como mecanismo de ajuste fino), y aún así sólo tuvieron éxito al cuarto intento (sólo lo intentaban los fines de semana porque pasaban más desapercibidos).
¿Y cómo afecta esto al resto de los certificados? Bueno, no se sabe si alguien ha podido hacer esto anteriormente (según ellos, con $2.000 de computación de la Amazon EC2 se puede tardar un día en hacer el ataque), pero cualquier certificado MD5 debería ser considerado "menos seguro". Hay que considerar que hace tiempo las principales las autoridades de seguridad ya no usan MD5. Adicionalmente, parece que todos los certificados con "Extended Validation" (que se muestran de manera especial en todos los navegadores -- por ejemplo en Firefox aparece el nombre del propietario). Y Microsoft y Mozilla van a parchear sus programas en breve. De hecho, mi Firefox 3 ya no lo reconoce como válido (bueno, aparte de que por motivos de seguridad el certificado malicioso tiene expiración de 2004 y nunca podría ser válido), aunque el IE 7 todavía sí, y es relativamente difícil detectarlo (ya que hay que mirar el certificado intermedio, que es el único que es MD5):
Así que estamos seguros por ahora... aunque estaría bien que todas las autoridades de certificación que en el pasado han emitido certificados MD5 los reemitiesen a un coste bajo... para que ya no queden por ahí sueltos.
Entradas
No hay comentarios:
Publicar un comentario