El 7 de abril de 2014 se anunció una grave vulnerabilidad llamada "Heartbleed". Heartbleed es una vulnerabilidad dentro de la serie OpenSSL 1.0.1 software que se describe en el anuncio NIST CVE-2014-0160. En resumen, esta vulnerabilidad permite a los piratas informáticos acceder a partes de la memoria de un sistema vulnerable, lo que puede dar lugar a la exposición de contraseñas, datos confidenciales y claves privadas de certificados en los sistemas afectados. Heartbleed logra esto explotando una debilidad en la "TLS Heartbeat Extension," exponiendo la memoria del servidor. Peor aún, este ataque de latido puede repetirse sin que la víctima lo sepa, y cada iteración revela otra instantánea de 64k de memoria al atacante. Esta gravísima vulnerabilidad expone los datos más sensibles de los sistemas afectados.
La buena noticia: la vulnerabilidad tiene un parche. Sin embargo, la adopción generalizada de la serie OpenSSL 1.0.1 software, unida a los dos años que lleva existiendo esta vulnerabilidad, significa que los riesgos atribuibles a Heartbleed son enormes. Las estimaciones actuales predicen que más de 500.000 sistemas pueden ser vulnerables. En concreto, la vulnerabilidad Heartbleed afecta a los sistemas que utilizan OpenSSL 1.0.1 (a-f). Lamentablemente, dado que este software está tan ampliamente implementado, muchas plataformas de SO populares se ven afectadas y, por tanto, son vulnerables. Le sugiero que visite el sitio web del CERT para obtener una lista más completa de las plataformas afectadas. Vale la pena mencionar que esta es una historia en desarrollo, y como tal, la lista de plataformas afectadas es probable que cambie.
Es importante comprender que esta vulnerabilidad no se limita únicamente a los servidores web. Dada la popularidad de OpenSSL, la tendencia actual a la "Internet de los objetos" y el hecho de que muchos dispositivos modernos vienen ahora con interfaces de configuración web protegidas por SSL , el alcance de los dispositivos potencialmente vulnerables es inmenso. Desde los enrutadores de red hasta los sistemas de control industrial pueden ser vulnerables.
Determinar el alcance de su exposición a esta vulnerabilidad puede ser un reto no trivial para una gran organización. La determinación de la vulnerabilidad incluirá sin duda una revisión de las plataformas corporativas afectadas y de las versiones de OpenSSL utilizadas en esos sistemas. Además, si está ejecutando la última versión de OpenSSL, existen métodos de script que se pueden utilizar para consultar de forma interactiva un sistema para determinar su vulnerabilidad, como la línea command a continuación:
echo -e "quit\n" | openssl s_client -connect 192.168.1.1:443 -tlsextdebug 2>&1 | grep 'server extension "heartbeat" (id=15)' || echo safe
Por último, hay sitios en línea que, dado un host y un puerto DNS , pueden comprobar si existe la vulnerabilidad Heartbleed.
Si uno determina que su sitio o servidor es vulnerable, ¿entonces qué? ¿Cuál es la mejor forma de actuar?
Si se determina que un servidor es vulnerable, entonces para estar completamente seguro, uno debe asumir que todos los datos sensibles que puedan haber estado alguna vez en la memoria de ese sistema han sido comprometidos. Es importante recordar que esta vulnerabilidad forma parte del código base de OpenSSL desde hace más de dos años. Y dada la naturaleza irrastreable de esta exposición, no hay forma segura de determinar el alcance de cualquier ataque, por lo que todos los datos de los sistemas afectados deben ser sospechosos.
- Todas las cuentas afectadas deberán restablecer sus contraseñas.
- Todos los certificados de sistemas vulnerables con claves privadas no protegidas por un HSM o un hardware criptográfico deben revocarse y sustituirse por certificados que contengan claves nuevas.
- Cualquier dato sensible tendría que ser evaluado en cuanto a su compromiso.
También es importante entender que esto no es un compromiso de PKI, SSL, TLS o certificados X.509. Heartbleed es más bien un exploit de los sistemas que utilizan PKI. Y como tal, cualquier nuevo certificado que se requiera para reintroducir los sistemas vulnerables, estaría sujeto a los requisitos del certificado original que se utilizaron para crear los certificados originales. Dicho esto, CSS siempre sugiere que durante cualquier evento de reintroducción o reinscripción de certificados, se realice un análisis del tamaño de la clave, el algoritmo hash y los requisitos de encadenamiento como parte del proceso general de inscripción de certificados.
