Logo de Heartbleed

Una buena parte de los usuarios de servicios de banca online, comercio electrónico y redes sociales se ha acostumbrado a ver en la barra de direcciones de su navegador las siglas HTTPS y un icono que representa un candado. Cuando accedemos a un sitio web bajo HTTPS asumimos que es un sitio seguro y que el intercambio de datos que realizamos está cifrado, por tanto, libre de terceros que intenten interceptar nuestras comunicaciones.

Sin embargo, desde la madrugada del lunes al martes se está hablando mucho de las conexiones SSL, concretamente, de los servicios que ofrecen conexiones cifradas apoyándose sobre OpenSSL puesto que se ha descubierto una grave vulnerabilidad de este componente que pone en riesgo las comunicaciones de muchos de los sitios web que, quizás, usemos a diario. Aunque el problema nos afecta a todos los que usamos internet a diario, no nos toca hacer nada como usuarios, sino que son los administradores de sistemas quienes tienen mucho trabajo estos días.

OpenSSL es una de las bibliotecas de criptografía más usadas en los servidores web (alrededor de un 17% de los servidores web que ofrecen conexiones seguras con SSL se apoyaban en este componente y presentaban esta vulnerabilidad); por tanto, que aparezca una vulnerabilidad es algo para tomarse muy en serio. Catalogada con el código CVE-2014-0160, esta vulnerabilidad ha sido descubierta por expertos de Google y la compañía de seguridad Codenomicon y ha sido "bautizada" bajo el apelativo de Hearthbleed al estar vinculada a la funcionalidad heartbeat de OpenSSL.

Impacto y gravedad de la situación

Para que nos hagamos una idea del impacto de esta vulnerabilidad, estarían afectadas todas las versiones de OpenSSL lanzadas en los dos últimos años y permitiría a un tercero con no muy buenas intenciones interceptar comunicaciones de sitios web bajo HTTPS y otros servicios como el correo electrónico o conexiones VPN. Servicios como Tor o Wikimedia se han apresurado a lanzar sendos comunicados sobre esta vulnerabilidad, el impacto que tiene en sus servicios y recomendaciones para mitigar el impacto; poco después de conocerse OpenSSL lanzó una nueva versión para corregir esta vulnerabilidad y distribuciones Linux como RedHat actualizaron sus repositorios para que los administradores de sistemas pudieran actualizar su versión de OpenSSL.

¿Y por qué tanto revuelo? ¿Por qué es tan grave esta vulnerabilidad? Para entender mejor la gravedad de esta vulnerabilidad, creo que es importante que entendamos cuál es el bug que se ha encontrado. Hay que partir de la base que el protocolo SSL/TLS es complejo y se basa en la criptografía asimétrica, es decir, en una clave pública y una clave privada que reside en el servidor que ejerce de prestatario de los servicios que estamos utilizando.

La clave privada, como su nombre indica, no se comparte con nadie y es la base sobre la se apoya el cifrado de las comunicaciones; sin embargo, la funcionalidad heartbeat que implementaba OpenSSL presenta un fallo en el que responde con un dato que revela porciones de la memoria interna utilizada por este proceso.Dicho de otra forma, OpenSSL estaba revelando datos de la memoria del servidor en el que se estaba ejecutando y, claro está, entre los datos que están en su memoria se encuentra la clave privada (necesaria para realizar los cálculos de cifrado y descifrado de mensajes). Con este escenario, sin el que el administrador del sistema sea consciente, la clave privada podría haber quedado expuesta a un tercero que hubiese explotado esta vulnerabilidad, desmontando la seguridad de este tipo de comunicaciones.

Los riesgos de la vulnerabilidad Hearthbleed de OpenSSL

Para entender mejor el impacto que supone esta vulnerabilidad, hemos hablado con Yago Jesús, experto en seguridad IT y editor del blog Security by Default. Yago nos comentó que no es la primera vez que se han detectado bugs en OpenSSL pero, aún así, el trabajo de la comunidad de desarrolladores de OpenSSL es muy bueno y han desarrollado un pilar muy importante sobre el que se apoyan múltiples servicios que operan en la red.

"Parece que con este ataque, cualquiera puede y ¿ha podido? obtener esa clave privada asociada al certificado. Esto es un problema muy grave, principalmente porque no sabes si ha sucedido o no, el ataque es 'limpio' no deja trazas, con lo que existe un riesgo de que te haya tocado a ti".

El gran revuelo que se ha generado, precisamente, radica en lo silencioso que podría ser un ataque explotase esta vulnerabilidad. Podrían haberse capturado claves privadas de servicios de gran calado y usarlos para descifrar comunicaciones o suplantar estos servicios para engañar al usuario e interceptar sus comunicaciones sin que éste se diese cuenta.

En este caso, si tu implementación de OpenSSL es vulnerable, lo más razonable es que revoques tu certificado SSL y consigas otro nuevo en el que la clave privada no haya podido ser comprometida. Según nos comentó Yago, esta vulnerabilidad es potencialmente grave y, de hecho, todo el revuelo generado está más que justificado porque se podrían haber comprometido muchos sitios web sin saberlo.

Concretamente, los principales riesgos son:

a) Que alguien pueda suplantar tu servidor web ya que teniendo la parte pública (se obtiene conectándote al servidor) y la parte privada (a través del ataque), nada impediría configurar un servidor web con esos datos y ser a todos los efectos 'tu' sitio web. Esto no hace que automáticamente alguien que ponga www.tusite.com sea redirigido al servidor del atacante (aquí interviene el protocolo DNS) pero, si el atacante consigue montar un ataque man-in-the-middle, puede redirigir las conexiones a su servidor y suplantar el sitio original. El navegador web no mostrará ningún tipo de alerta cuando negocie la sesión SSL, por tanto, el usuario no sería consciente del engaño.

"Esta práctica podría ser de mucha utilidad para países que coartan la libertad de expresión, por ejemplo China. Con este ataque podrían haberse hecho con la parte privada del certificado SSL de cualquier sitio web vulnerable y que sea de interés, y de esa forma poder espiar a sus ciudadanos".

b) Al tener la clave privada, que es la base para descifrar las comunicaciones entre un cliente y el servidor, el tráfico SSL se podría descifrar sin problema. Por tanto, si alguien estuviese a la escucha de nuestras comunicaciones (realizando sniffing), el cifrado de las comunicaciones no le importaría porque sería capaz de descifrarlas y acceder a la información circulante por la red.

Actualizar la versión de OpenSSL, el primer paso para solventar el problema

¿Y cuál es la solución? Como nos podemos imaginar, la solución pasa por la instalación de la nueva versión de OpenSSL que se ha lanzado, precisamente, para corregir esta vulnerabilidad. Quizás nos podría parecer algo simple pero cuando hablamos de sistemas que están en explotación, la actualización de un paquete de software no siempre es un proceso inmediato; los cambios requieren pruebas y revisiones. Evidentemente, esta vulnerabilidad no es algo a pasar por alto, es importante aplicar la solución publicada por OpenSSL lo antes posible para evitar la exposición de la clave privada pero, además, es importante revocar el certificado SSL de los servicios web que estaban afectados por esta vulnerabilidad para, así, anularlo en el caso que éste hubiese sido interceptado. Al generar los certificados de nuevo, los posibles certificados interceptados dejarían de tener validez y no se podrían usar con fines deshonestos.

Nota: Durante las primeras horas se comentó que esta vulnerabilidad afectaba a dos tercios de los servidores web; sin embargo, el impacto es mucho más pequeño (aunque no por ello menos preocupante).

Como bien comentaba Ricardo Galli en Twitter, el dato de "dos tercios" se corresponde con la proporción de servidores que se apoyan en Apache y en Nginx que, a su vez, se apoyan sobre OpenSSL; sin embargo, no todos los servidores web están bajo HTTPS (no siempre se usa SSL) así que la realidad es que el impacto es menor. Según los datos que ha publicado Netcraft, el impacto es del 17% de los servidores web que ofrecen servicios bajo SSL con certificados de autoridades de certificación reconocidas.
Fuente