Primero fue el supuesto backdoor que la NSA implementó en el kernel de linux. Después vino Apple con su doble goto fail, que permitía interceptar comunicaciones en iOS y OS X, y ahora surge uno nuevo, que afecta a cerca de dos terceras partes de los servidores que hay en la actualidad.
El exploit aparece en la librería OpenSSL,
La versión open source del protocolo de comunicaciones seguras, y a un servidor le da qué pensar. El error lo han encontrado en una de sus funciones, llamada Heartbeat, y que es la encargada de gestionar la emisión y recepción de los keep-alive, un tipo de mensajes bastante parecidos al clásico ping que informa al servidor de que seguimos conectados, y que por tanto no debe cerrar la sesión.
En este tipo de mensajes se envía información, al igual que en el ping, que sirva al receptor para conocer cuándo se ha enviado, además de la extensión de esta cadena. De esta manera, el receptor conoce que por ejemplo debe leer 20 bytes, y recorre una a una las posiciones de la memoria para obtener esta información, que le permite compulsarla con la fecha actual y establecer el tiempo de respuesta.
¿Qué está pasando? Pues que al parecer esta restricción (el tamaño de la memoria ocupada por el keep-alive) puede obviarse, lo que permite a un atacante leer hasta 64kbs de memoria. Puesto que la información en memoria no es determinista, el atacante ahí se puede encontrar de todo, desde basura, hasta credenciales de acceso. Y puesto que está en memoria, sin cifrado de ningún tipo.
Esto, repetido una y otra vez te va a permitir leer todo lo que quieras de ese servidor (cada vez nos encontraremos nuevos datos).
Y ahora viene lo bueno. El bug aparece en septiembre del 2011 y se hace público en mayo del 2012, siendo resuelto antesdeayer, y no en todas las distribuciones. Para colmo, actualizar a la versión 1.0.1g solo implica que el exploit ya no es aprovechable, pero un atacante ya podría tener pleno acceso al servidor.
¿Qué podemos hacer como administradores?
Lo primero de todo actualizar la librería a la última versión, y luego cambiar las contraseñas del servidor ¿Conseguimos con esto solucionar cualquier problema? Lamentablemente no, el mal ya puede estar hecho, pero sí reducimos las posibilidades de seguir aprovechándose del mismo. Además, recomendaría consultar las cuentas con permisos superiores a usuario y eliminar aquellas que ya no usemos o directamente no sepamos de quien son. Se puede testear en este enlace (EN) si tu servidor es vulnerable (versiones desde la 1.0.1 hasta la 1.0.1f) y aplicar el parche (EN) en este otro.
¿En qué nos afecta como usuarios?
Se calcula que las dos terceras partes de los servidores que hay en el mundo están afectadas, por el simple hecho de que dos terceras partes cuentan con Linux como sistema operativo de servidor. Cada día nos conectamos a decenas de servicios de comunicación segura (Google, Facebook, Twitter, …), y todas estas conexiones pueden haber sido interceptadas en el clásico esquema man in the middle. Lo más inquietante es que el ataque no requiere escalado de permisos o alguna otra estrategia semejante. Solo constancia, y un continuo escaneo a esos mensajes keep-alive.
Y decía al principio del artículo que situaciones como estas me dan qué pensar, puesto que no entiendo cómo sabiendo que la librería está escrita en C, y por tanto, con una gestión de bit a bit de arrays, nadie cayó en la consideración de que un ataque como este podría llevarse a cabo. Es más, me pregunto qué sistemas de testeo han dejado pasar algo semejante, que claramente está mal diseñado (debería forzarse a leer únicamente la variable de posiciones que le pasas). Y más aún sabiendo que gobiernos como el de EEUU son parte importante de esa comunidad de agencias que están detrás del desarrollo de la mayoría de servicios de comunicación segura. Llamarme desconfiado…
