Heartbleed y el caos de seguridad en Internet

Desde que se publicó el bug de Heartbleed ha sido un día duro en Eleven Paths, como en muchas otras compañías de Internet para conseguir tener los sistemas actualizados sin sufrir interrupciones de servicio, para lo que hubo que tensar los procedimientos de emergencia y trabajar muchas horas y con intensidad. Si no te has enterado aún de qué este fallo, voy a intentar hacerte entender la magnitud del fallo para que tomes tus medidas de seguridad.

¿Dónde está el fallo de HeartBleed?

El fallo se encuentra en una de las implementaciones más populares de SSL, la capa de cifrado y autenticidad que da seguridad a muchos de los protocolos de Internet, como son HTTPs, FTPs, SSTP, o muchos otros. Según Shodan hay más de 5 Millones de servidores que tienen instalado OpenSSL expuesto a Internet aunque solo una parte de ellos tienen alguna versión vulnerable, que como sabéis ya es la 1.0.1. 

En concreto, el bug está en la implementación que hace esta capa de cifrado del "latido del corazón" o HeartBeat, que se usa para mantener la sesión SSL activa después del "saludo de manos" o Handshake. El funcionamiento si quieres una explicación detallada, la tienes en el libro de Cifrado de las comunicaciones digitales, pero digamos que cuando un cliente quiere establecer una sesión segura usando SSL con un servidor, lo primero que hace es negociar una clave de cifrado simétrico con el servidor que les permita enviar toda la información de forma segura. 

Para que esa clave de cifrado simétrico se intercambie de forma segura se usa un negociación, llamada HandShake, para lo que se usa el certificado digital y las claves PKI que tiene configuradas el servidor. Es decir, el servidor cuenta con us clave privada y su clave pública para firmar las comunicaciones y realizar procesos de cifrado asimétrico. Como sabéis, la gracia de PKI es que lo que se cifra con la clave pública solo puede ser descifrado con la clave privada. Por eso el servidor envía su clave pública al cliente y este usará la clave pública para cifrar la información que le va a enviar al servidor, lo que garantiza que aunque alguien intercepte la comunicación no va a poder descifrarla si no tiene la clave privada.

Una vez que el cliente ya tiene la clave pública del servidor para cifrar las comunicaciones ya pasa a negociar la clave de cifrado simétrico, usando diferentes posibles esquemas en función de las características que tengan servidor y cliente. Este proceso permitirá al cliente generar una clave simétrica y comunicarse con el servidor de forma segura lo que concluye con que tanto servidor como cliente conocen la clave simétrica de cifrado que se usará en esa sesión sin que nadie haya podido interceptarla.

A partir de ese momento se comenzarán a transmitir los datos del protocolo de aplicación que se esté protegiendo, que será HTTP, Telnet, FTP o los protocolos VPN en la red privada virtual, todo ello cifrado siempre con la clave simétrica negociada.

Como este proceso de saludo es costoso computacionalmente, se creo el "latido del corazón" o HeartBeat, que permite al cliente decirle al servidor "no cierres la sesión y fuerces otro saludo, que sigo trabajando contigo en esta sesión". Para ello en SSLv3 se envía una estructura de datos TLS1_HB_REQUEST de 4 bytes en la va el tipo el tamaño y un payload de 1 byte,  en los que se permite decir qué tamaño tiene el mensaje de HeartBeat y engañar en el tamaño a la que el servidor responde con un mensaje TLS1_HB_RESPONSE que se compone a partir del mensaje original.

Figura 1: Mensajes en SLV3 para mantenimiento del HearBeat

Y ahí está el bug.

El bug está en que el cliente puede enviar un mensaje TLS1_HB_REQUEST con un payload en el que diga que su tamaño es 65.535 (64 kB). Cuando el servidor vaya a construir la respuesta de TLS1_HB_RESPONSE va a copiar el mensaje TLS1_HB_REQUEST de memoria para a partir de él configurar la respuesta - a modo de Echo como hacen muchos protocolos -, comenzará a leer el paquete TLS1_HB_REQUEST en la posición de memoria en la que se haya ubicado hasta el final de la longitud del paquete, que la lee del mismo payload que va en él.

Como el atacante ha dicho que su tamaño de respuesta es de 65.535 leerá 64 kB de lo que haya en la memoria y lo pondrá todo en TLS1_HB_RESPONSE... todo lo que haya en 64 kB de memoria de un servidor, con lo que podrá aparecer de todo.

¿64 Kilobytes es tanto?

64 kB no es mucho si sólo vinieran los mismos 64 kB, pero es que la memoria cambia constantemente, y cada vez que se pide un TLS1_HB_RESPONSE va a venir una sección distinta. Cuando se crea un exploit para Linux o para Windows, siempre hay que conseguir un Information Leak, que permita saber en qué dirección de memoria se encuentra cargado el proceso. En este caso, basta con "pegar un tiro" con un HeartBeat malicioso y recibir una parte de la memoria. "Pegar otro tiro" y se recibirá otra parte. Brutal. Esto lleva a que la gente se pueda bajar Gigas y Gigas de datos distintos de la memoria de los servidores en pedazos de 64 Kilobytes. Brutal ++.

¿Qué se pueden llevar de la memoria de un servidor?

Todo. Claves de los servicios, el código de las aplicaciones, las cuentas de usuarios y contraseñas en texto claro de cualquier servido HTTP que corra en ellos, las claves privadas de los certificados digitales de los servidores, etcétera. Hasta el último byte de código o datos que sean utilizados en la conexión SSL en un servidor tienen que pasar por memoria, así que ahí están todas las e información que supuestamente deberían estar seguras.

Si tu servidor no tiene ningún servicio que use SSL y no tienes OpenSSL instalado y en ejecución no estás afectado, pero si uno solo de los servicios - incluso los de hosting compartido - tiene una VPN, un SSH, un HTTPs, un SSTP, o similar que tire de OpenSSL entonces todo está listo.

El bug ha afectado a muchos de los servicios claves de Internet. Google conocía este bug desde diciembre de 2013 y aún está actualizando servidores para evitar el impacto. Yahoo! está enfangado en las actualizaciones, Amazon ha avisado a todos sus clientes de sus problemas pidiendo las passwords, y... hasta nosotros nos vimos afectados en los servidores, lo que nos obligó a lanzar un procedimiento de emergencia notificando .

¿Qué se debe hacer?

En el caso de que tu servidor haya sido afectado debes hacer un cambio de cualquier clave que tenga el servidor. Todas deben ser cambiadas. De servicios, de conexiones a bases de datos, árboles LDAP, de cifrado de disco, de administración de servicios, de todo.

Si tienes un servicio por encima, tipo FTP, HTTP, etcétera, debes asumir que todos los datos que se hayan transmitido han podido caer en manos indebidas, así que cambia las credenciales de todos los usuarios de aplicaciones web, fuerza un reseteo de contraseñas, mata las cookies de sesión de todas las conexiones que hubiera activas y asume que todo tu código ha caído en manos externas.

Por supuesto, hay que cambiar los certificados digitales de todo que pueden estar comprometidos - las claves privadas de los certificados están también en memoria - y por tanto si alguien las ha obtenido puede utilizarlas para descifrar todas las comunicaciones a tu servidor y ver el tráfico.

Cambiar los certificados digitales no es nada sencillo, ya que si tienes apps que hagan uso de Certificate Pinning deberás actualizar los certificados que validan dichas apps, así que espera que tu Android, tu iPhone o tu Windows Phone empiecen a pedir actualizar apps a saco. 

Desde el punto de vista de usuario, no solo deberás actualizar las app, sino que como no sabes qué credenciales han podido caer en qué servidor, deberías cambiar todos las passwords. Si no tienes un 2FA, es un buen momento para ponerlo en tu cuenta de Google, Hotmail o Apple y asegurarte que toda las cuentas cuentas de servicio tienen como correo electrónico de recuperación de contraseña una cuenta con Segundo factor de autenticación.

En muchos frameworks de Internet basados en sistemas Linux, como WordPress, PrestaShop, Moodle, Joomla, RoundCube, etcétera, etcétera, es muy común el uso de OpenSSL, así que por si acaso algunos de tus usuarios no ha cambiado la contraseña, dale un vistazo a la posibilidad poner un segundo factor con Latch.

Si tienes muchos servicios en tu Hosting, afina los firewalls y los IDS para detectar esos paquetes de respuesta de TLS1_HB_Reponse de 64 kB.

¿Esto una puerta trasera o un fallo de programación?

Como os podéis imaginar las especulaciones apuntan a que esto es la famosa "capacidad avanzada" que el programa BULLRUN filtrado por Edward Snowden hablaba. No tiene sentido que OpenSSL tuviera un fallo gordisimo años atrás que permitía descifrar el tráfico, que Apple no sea capaz de verificar los certificados digitales de forma correcta en el escándalo del Goto Fail y que se hayan descubierto fallos similares en otras implementaciones de cifrado.

Figura 2: Filtración del programa BULLRUN

Las especulaciones decían, según los documentos filtrados, que la NSA podría haber impulsado la inyección de errores en las implementaciones más usadas de software criptográfico y por supuesto todo el mundo miró a TrueCrypt - actualmente bajo estudio pero con pocas noticias - y OpenSSL. 

Sea como fuere, este bug está entre el Top 10 de bugs de seguridad en Internet seguro por la facilidad de explotación y su impacto. Solo el RCP DCOM o el MS08-67 - que hace las delicias de los que comienzan a aprender a usar Metasploit - de Microsoft creo que se podrían igualar. En esos podías ejecutar remotamente una shell con un exploit bastante sencillo, en este puedes conseguir los datos de forma silenciosa - los HeartBeats no dejan traza en los servidores web - esperar a que llegue la password y entrar.

Actualización: Detección con Faast

En Faast, nuestro servicio de Pentesting Persistente en Eleven Paths hemos introducido ya el plugin de detección de Heartbleed para localizar servidores vulnerables en nuestros procesos de auditoría.

Figura 3: Detección de Heartbleed con Faast

Saludos Malignos!