Internet se ha roto, otra vez (I)

Poco se puede aportar ya al fallo de implementación criptográfica Heartbleed (ya tenemos disponibles plugins para FOCA y Faast). Se trata de un grave problema que tendrá (y es posible que haya tenido) graves repercusiones. Sin embargo, no es la primera catástrofe (criptográfica o no) en la red. ¿Las ha habido peores? ¿Es realmente una catástrofe, o lo han sido sus «daños colaterales»?

La mejor explicación de Heartbleed. Fuente: http://xkcd.com/1354/

En la versión OpenSSL 1.0.1 se introdujo la implementación del protocolo RFC6520, que describe la extensión hearbeat en TLS/DTLS. Al introducir esta extensión, se pretendían evitar constantes renegociaciones. Servidor y clientes se enviaban «latidos» para mantenerse «informados». OpenSSL lo implementó mal, con desastrosas consecuencias. En la práctica, basta realizar ciertas peticiones a un servidor que trabaje con la versión vulnerable de OpenSSL, para que devuelva un buen trozo de información (64ks, un «heartbeat») que, literalmente, puede contener cualquier cosa: desde cookies de sesión de usuarios conectados en ese momento, pasando por contraseñas, o incluso la propia clave privada del servidor. Esto quedó demostrado con el reto de Claudfare, que solventó finalmente Indutny en cuestión de horas gracias a esta herramienta que programó él mismo.

Pero de esto ya se ha hablado mucho. Lo verdaderamente curioso son los efectos colaterales, tanto de la vulnerabilidad, como de las reacciones en la comunidad.

¿Cuáles son los escenarios y probabilidades de ser vulnerable? Para conocer el verdadero impacto podemos hablar de los diferentes escenarios, más o menos catastróficos, que se pueden presentar.

Muchas formas de ser vulnerable

• Un usuario puede verse afectado porque un atacante haya «consultado» el servidor y, casualmente o no, haya dado en un trozo de memoria con la contraseña o cookie de ese usuario. Tanto por cookie como por contraseña, la cuenta está comprometida. Es poco probable que atacantes hubieran realizado esto de forma masiva antes del día de la revelación, pero sí es muy posible que, pocas horas después, se dedicaran a atacar servidores todavía vulnerables de forma masiva. De hecho se ha confirmado para la Canada Revenue Agency.
• Un usuario puede verse afectado porque hayan robado la clave privada de un servidor. En este escenario, se dan varios subcasos, porque el atacante ha podido conseguir varias cosas: 
• Si el servidor no usaba perfect forward secrecy (e incluso si se usaba, pero con menor probabilidad), y además el atacante obtuvo previamente (con ataques MiTM) tráfico cifrado… estas conversaciones pueden ser ahora descifradas ahora con la clave. Un descifrado con efectos retroactivos.
• Si se obtuvo la clave privada, es posible suplantar criptográficamente al servidor (siempre que se redirija al usuario a ese servidor sin que lo note). O sea, el phishing perfecto. El servidor atacado debe no solo regenerar, sino revocar las anteriores claves y certificarlas de nuevo (las CA están frotándose las manos)

• OpenSSL se encuentra en muchos entornos, protocolos y dispositivos. VPNs, routers… incluso en entornos que son difíciles de actualizar. ¿Qué ocurrirá con ellos y sus usuarios? Quizás no se les ha prestado tanta atención.
• Los clientes también pueden ser vulnerables. Usuarios de wget o curl que enlacen a una librería OpenSSL vulnerable y se conecten a servidores maliciosos, podrían estar ofreciendo trozos de memoria a un tercero.

Estos son los escenarios, por lo que es poco probable que algún usuario de internet se libre del problema. Pero, entonces ¿es una catástrofe, o no? Depende de si esto estaba siendo usado con anterioridad.

• Si no es así, la revelación y parcheo ha sido rápida, y la campaña de comunicación perfecta para que se entere hasta el último usuario de la red. El ruido ha sido mucho, pero se habría manejado razonablemente bien la situación.
• Si realmente alguien usó esto de forma masiva (cosa que nunca se podrá saber a ciencia cierta, aunque la Casa Blanca lo niegue explícitamente), el problema es un poco más grave (aunque no sabemos si más o menos grave que cualquier sistema de espionaje al que ya parece que estamos sometidos). Pero al menos, como consecuencia, una buena parte de los usuarios habrán modificado ya algunas claves, y los servidores regenerarán su material criptográfico. No está mal como sistema obligado de «limpieza» y regeneración.

Los «daños colaterales»

Pero lo mejor que ha conseguido Heartbleed es una sacudida de ciertos cimientos, que se pongan sobre la mesa asuntos necesarios. Algo que siempre es sano. Veamos brevemente qué ha pasado no con el terremoto en sí, sino con el tsunami que ha causado.