domingo, 28 de diciembre de 2014

El impacto de Heartbleed en CloudFlare

En mi última charla de hoy, Nick Sullivan nos habla de cómo se abordó Heartbleed en la empresa CloudFlare.
Desde el punto de vista de CloudFlare, lo que pasó es que un amigo notificó a Nick que había una vulnerabilidad en los Heartbeats de TLS, así que Nick recompiló SSL sin Hearbeats y los parcheo todos. Antes de que la vulnerabilidad fuese pública. ¿Por qué era importante en CloudFlare? Porque un millon de sitios Web están en CloudFlare.
El 7 de abril, después de dos horas (12:00 aprox.) CloudFlare ya anunciaba que todos los clientes estaban parcheados. A las 13:00 la noticia llegó a los medios, se creó heartbleed.com y la madre de Nick se aseguró de que su hijo estaba bien.
En ese momento, CloudFlare admitió un Hearbleed Scanner en su plataforma, que recibió de 10k a 20k escaneos por minuto. En total, unos 200M de escaneos.
Desde entonces. registraron todas las peticiones de hearbleed malformadas: 69% eran de una longitud de 16384, probablemente de ssltest.py, 22% de filippo.io y un 2% de longitud 0 (ZMap).
El problema de Hearbleed es que normalmente no queda registrado, se puede conseguir hasta 64k de memoria del servidor y esto puede tener todo tipo de datos secretos.
¿Qué permite OpenSSL descubir? En principio, nada, porque en la biblioteca de OpenSSL bignum se borra todo nuevo número que se crea o se destruye.
Pero para demostrarlo, crearon el desafío: crearon un servidor con una clave privada, y desafiaron a cualquiera que enviase un programa firmado con la clave privada. Pero llegó un tuit de Fedor Indutny en menos de 10 horas con la clave robada.
¿Y cómo se obtuvo la clave? No mediante Heartbleed, sino que había un segundo bug en OpenSSL, habia tres números que se liberaban sin borrarlos. Aunque no se conseguía toda la clave en cada petición, había varios métodos para conseguirla en varias peticiones.
Como consecuencia de esto, tuvieron que revocar los certificados, la revocación más masiva de todo internet, un orden de magnitud de lo que había hasta entonces.
Pero el problema es que el servidor de certificados revocados CRL no aguantó la carga, Chrome no comprueba OCSP y además no funciona bien; y el sistema de Google, CRLSets, no incluyó los certificados de Cloudflare.
Así que recurrieron a un hack en Chromium (en el código fuente del navegador) y revocaron sus certificados.

Conclusiones.

  • Descubrir cosas de código abierto no es sencillo de hacer.
  • Las nuevas funcionalidades deberían estar deshabilitadas por defecto.
  • Esperar lo inesperado.
  • Muchos de los ataques eran realmente escaneos como el de ZMap.
  • Crowdsourcing les ayudó a encontrar la solución a su duda sobre la vulnerabilidad.
  • No existe todavía una solución a la revocación de certificados
  • Hay que soprotar OpenSSL monetariamente.

No hay comentarios:

Publicar un comentario