¿Qué hizo Heartbleed?

En la penúltima charla del día, Zakir Durumeric de la Universidad de Michigan habla de que pasó después de que Heartbleed fuese descubierto.
En abril de 2014, cuando se descubrió el bug Heartbleed en OpenSSL se estima de que el 24-55% de los servidores HTTPS era vulnerable.
La extensión de TLS denominada Heartbeat permite establecer el estado activo de una conexión, no era muy usada porque en la mayoría de los casos se podía hacer eso a nivel TCP. El problema era muy sencillo: la extensión tiene un campo de longitud para los datos que se utilzaban como respuesta a la pregunta de si estaba vivo, que no se comprobaba al responder, con lo que se respondía con datos de otras partes de la memoria del servidor.
Una vez descubierto, el equipo de Zakir se puso a la tarea de modificar su herramienta ZMap para examinar el millón de mayores sitios web de Internet y si tenían la vulnerabilidad, a base de enviarles un paquete con una longitud de cero, que en las versiones correctas no devolvía ningún paquete y en las versiones vulnerables enviaba un paquete con cero bytes de respuesta.
48 horas después de publicarse, hicieron su scan, con el resultado:

• 45% soportaban SSL
• de esos, sólo 60% soportaban Heartbeat
• De esos, 18% eran potencialmente vulnerables, ...

Con ese porcentaje, estimaron que entre 25% y 55% eran vulnerables.
¿Y respecto al resto de internet? se estima que el 11% de las direcciones IPv4 soportaban Heartbeat, y aproximadamente la mitad eran vulnerable, un 6% de las direcciones IPv6 eran vulnerable.
¿Cuándo se parchearon todos? Pues respecto a los top 1M, hacia el 19 de abril sólo había un 4% de ellos vulnerables, pero no ha bajado del 3% todavía.
El problema es que a partir de 22 horas después, ya había ataques indiscriminados a toda la Internet. Pero el número de atacantes era pequeño, sólo 11 equipos escanearon Amazon y la universidad de Michigan a la vez, lo que significaría que pocos hosts estaban escaneando toda la Internet, per sí que había más escaneos centrados por ejemplo en Amazon (201 hosts).
Pero midiendo el nivel de parcheado, se vio que los sitios que fueron notificados que eran vulnerables el 28 de abril tenían un nivel de parches un 50% de los que fueron notificados el 5 de mayo.
El problema más grave es que la vulnerabilidad requería cambiar el certificado de la web, pero sólo un 11% de los notificados lo cambiaron, y muchos de ellos los cambiaron por otros certificados con la misma clave pública que era vulnerable.
Conclusiones:

• El ecosistema de código abierto no recibió la atención suficiente para evitar esta vulnerabilidad.
• El ecosistema de HTTPS es muy frágil, después de Heartbleed hubo varias vulnerabilidades adicionales.
• El uso de una PKI no está listo para revocar miles o millones de certificados de una vez.