El bug en cuestión, denominado Heartbleed e identificado por mitre como CVE-2014-0160 permite al atacante acceder a parte de la memoria del sistema vulnerable y así obtener las claves con las que se podría acceder a la información protegida por la capa SSL/TLS de la comunicación.
La posible información filtrada se organiza en 4 categorías según su criticidad:
1- Primary key material: ni mas ni menos que la clave de un certificado X.509 por ejemplo. Este nivel de compromiso es costosísimo... para solucionarlo, además de aplicar el parche para OpenSSL es necesario revocar el certificado en cuestión y pedir uno nuevo, de lo contrario cualquier tráfico futuro podría ser espiado. Cualquier tráfico pasado es completamente legible para el atacante.
2- Secondary key material: un ejemplo de este tipo son las claves del home banking, de sitios webs que utilicen SSL/TLS, etc. Si tu banco aún es vulnerable yo cambiaría las credenciales, claro una vez que hayan solucionado el problema.
3- Protected content: en esta categoría cae toda la información que es transferida durante la comunicación cifrada. Por ejemplo archivos adjuntos descargados de una cuenta de correo, o transferidos a través de una VPN, etc.
4- Collateral: esta cuarta categoría es de baja importancia para el usuario del sistema, se trata de información acerca del entorno del sistema vulnerable, como direcciones de memoria y medidas de seguridad existentes.
Cómo saber si mis sistemas son vulnerables?
Bueno, hay al menos dos formas de saberlo. Una de ellas es identificando la versión de OpenSSL instalada en el sistema y la otra es probando la vulnerabilidad como Dios manda.Versión de OpenSSL instalada:
juan@moon:~/pruebas$ openssl version
OpenSSL 1.0.0e 6 Sep 2011
juan@moon:~/pruebas$
Las versiones de OpenSSL entre 1.0.1 y 1.0.1g se ven afectadas (la mía por ejemplo es vulnerable).
Podemos probar la vulnerabilidad de dos maneras, tercerizándolo (me da cierto miedo este camino, nunca sabemos con certeza las intenciones de terceros) por http://filippo.io/Heartbleed/
o usando el script provisto por Jared Stafford en http://pastebin.com/3NdQVHxn (que por algún motivo no coincide con la valoración de heartbleed test).
Ejemplo:
juan@moon:~/pruebas$ ./heartbleed.py XXXXXXXX
Connecting...
Sending Client Hello...
Waiting for Server Hello...
... received message: type = 22, ver = 0301, length = 66
... received message: type = 22, ver = 0301, length = 3982
... received message: type = 22, ver = 0301, length = 331
... received message: type = 22, ver = 0301, length = 4
Sending heartbeat request...
... received message: type = 21, ver = 0302, length = 2
Received alert:
0000: 02 46 .F
Server returned error, likely not vulnerable
juan@moon:~/pruebas$
Es probable que una de las dos pruebas no sea del todo precisa, y si nos remitimos a la versión de OpenSSL del servidor
[root@XXXXXX ~]# openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013
[root@XXXXXX ~]#
podemos confirmar que la prueba web es mas precisa que el script.
Cómo solucionarlo?
La solución al bug es sencilla, basta con actualizar la versión de OpenSSL, la mayoría de las distribuciones de linux ya la tienen disponible. La dificultad está en cómo tratar los sistemas que fueron comprometidos.
Lamentablemente no es posible (al menos por lo que leí) identificar qué sistemas fueron vulnerados, los administradores de sistemas que manejen información realmente importante deberían considerar fuertemente la idea de revocar los certificados y reemplazarlos.
