OpenSSL – Heartbleed y el caos de seguridad en Internet

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 la1.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 protocolosVPN 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 enSSLv3 se envía una estructura de datos TLS1_HB_REQUEST de 4 bytes en la va un payload de 1 byte que le permite decir qué tamaño tiene el mensaje de HeartBeat, 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 unpayload 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 mensajeTLS1_HB_REQUEST de memoria para a partir de él configurar la respuesta – a modo de Echo como hacen muchos protocolos -, comenzará a leer el paqueteTLS1_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 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. Esto es además favorecido por las medidas antiexploting como ASLR que introducen los servidores para evitar que la zona de memoria en la que se coloca un proceso sea siempre predecible.

Cuando se crea un exploit para Linux o para Windows, siempre hay que conseguir unInformation 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 HeartBeatmalicioso y recibir una parte. “Pegar otro tiro”, y las propias medidas de protecciónantiexploiting harán que se reciba 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 ++.

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 un servidor tienen que pasar por memoria, así que ahí están hasta las claves TrueCrypt, FileVault o Bitlocker de todos los servidores. Fin, pueden tener todo, cambia todo.

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 SFTP, 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 .

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 Phoneempiecen 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.

Como os podéis imaginar las especulaciones apuntan a que esto es la famosa“capacidad avanzada” que el programa BULLRUN filtrado por Edward Snowdenhablaba. 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 – deMicrosoft creo que se podrían igualar. En esos podías ejecutar remotamente unashell 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

Fuente: http://www.elladodelmal.com/2014/04/heartbleed-y-el-caos-de-seguridad-en.html