jueves, abril 10, 2014

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!

22 comentarios:

Alejandro Eguía dijo...

Excelente Chema, muy claro como siempre.

Anónimo dijo...

Estoy de acuerdo, muy bien explicado. Es la explicación que andaba buscando.

Samuel dijo...

Muy buena explicación Chema. Solo un apunte, en el artículo escribes "Para ello en SSLv3 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". Para conseguir decirle que el tamaño es de 64K se tendrá que especificar en dos bytes, ¿cierto?

Vicente Motos dijo...

Muy bien explicado!

Uno que pasaba dijo...

Hola Chema,

Hay un pequeño detalle que no es cierto en lo que afirmas.

Donde dices:
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.

Hay que dejar claro una cosa: No puedes salirte de la memoria asignada al proceso con lo cual con MUY poca probabilidad vas a dar con una sección de memoria que no hubiese estado usada ya por la aplicación que usa OpenSSL.

Vas a dar con regiones liberadas con muchisima probabilidad pertenecientes al proceso atacado y no a otros.

Es muy grave ya que puedes obtener en claro peticiones HTTP de otras personas conteniendo credenciales pero mucho mas lejos de dar con claves TrueCrypt y demás que están en la región de memoria de OTRO proceso (podría darse el caso de que se le asigne una región de memoria al proceso atacado donde antes había una clave de TrueCrypt pero hasta donde se, y como es lógico, se hace un borrado activo al cerrarlo).

Un saludo.

Maligno dijo...

@uno que pasaba, right! lo cambio.

Saludos!

Francisco Oca dijo...

Un detallito: SFTP va sobre SSH. En todo caso estaría afectado FTPs que va sobre SSL.

Un saludo!

Manfred Aguilar dijo...

Maligno tengo una duda, mencionas que
Google conocía el bug desde 2013 pero porqué entonces no se le había dado importancia antes a esto, porqué hasta ahora sale a la luz de esta manera ? Espero respondas a mi duda

Anónimo dijo...

Hola, al intentar acceder a https://www.twitter.com me aparece esto:

"www.twitter.com utiliza normalmente la encriptación (SSL) para proteger la información. Cuando Chrome ha intentado establecer conexión con www.twitter.com, www.twitter.com ha devuelto inusuales e incorrectas. Por tanto, es posible que un atacante esté intentando suplantar la identidad de www.twitter.com o que una pantalla de inicio de sesión Wi-Fi haya interrumpido la conexión. Tu información sigue estando protegida ya que Chrome detuvo la conexión antes de que se llevara a cabo cualquier intercambio de datos.
Los ataques y errores de red suelen ser temporales, así que es probable que esta página funcione más adelante. También puedes probar a utilizar otra red.
Información técnica: Chrome no puede utilizar el certificado que ha recibido durante este intento de conexión para proteger tu información porque el formato del certificado no es correcto.
Tipo de error: Malformed certificate
Destinatario: twitter.com
Emisor: VeriSign Class 3 Extended Validation SSL CA
Hashes de clave pública: sha1/FXnwvO30nbpcJgjDK6bH+rGSqEo=
sha256/qaKZwjzvNNGAc/ryUbwfqL2oArYbz4OPU22TnZ8MxNc=
sha1/rkrX+bOA4RKTMrtS3loJDFlbM9a=
sha256/OTV6OSADZrQuFMltaBc+5XvltK1Ljeify/yvlthNjvM=
sha1/sYEIGhmkwJQf+uiVKMEkyZs0rMc=
shae256/JbQbUG5JMJUol6brnx0x3vZF6jilxsapbXGVfjhN8Fg="

¿Está esto relacionado con el heartbleed? ¿Qué debería hacer?

dude dijo...

Gracias por este post tan bien explicado!

Solo me queda una duda, en los tiempo que corren ¿El sistema operativo permite que un proceso acceda a la memoria de los otros (sin hacer nada especial)? Asumiendo que la respuesta es sí ¿No debería el servidor web estar ejecutándose con privilegios de administrador para que esto sea posible?

Anónimo dijo...

[Sarcasmo]
Menos mal que OpenSSL es de código abierto, que si no...
[/Sarcasmo]

Anónimo dijo...

Siempre es atractiva la teoría de la conspiración porque la explicación más obvia (negligencia) es aburrida: http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse

PS. I work for the NSA and my comments don't represent the views of my employer.

Anónimo dijo...

2 dias despues de comenzar oficialmente la operacion PONLEFRENO con la que denunciar los puntos negros con windows XPired edition instalado y resulta que la urbana va con las ruedas pinchadas ...

Anónimo dijo...

La solución es muy simple:
Dejad de usar OpenSSL !!
Porque se ve que es bastante "open..."

Antc dijo...

Está claro que se pueden obtener paquetes de 64 bits, además de que son diferentes en cada respuesta, pero ¿cómo sabe el atacante a que parte corresponden y como unirlos para obtener información y no un conjunto de bits?

Javier Coloma dijo...
Este comentario ha sido eliminado por el autor.
Javier Coloma dijo...

a Titulo anecdótico una tira comica sobre el bug

http://xkcd.com/1354/

Anónimo dijo...

Dos breves notas dadas la imprecisiones del artículo:

a) Al menos los sistemas Linux (y supongo que cualquier OS moderno) borran la memoria física antes de asignarla a otro proceso, por lo que usar openssl con apache, por ejemplo, no hará que las claves de cifrado de disco, etc se vayan a ver comprometidas por este bug. Es fallo es grave, sí, pero no tanto. Eso sí, todo lo que pase por el servicio podría verse, en principio, comprometido.

b) Las protecciones ASLR no tienen nada que ver con este problema, ni aumentan su gravedad.

El Desertor dijo...

Impresionante. Así contado por ti parece hasta una chorrada de la que todo el mundo debería darse cuenta enseguida ¿cómo es posible?
Será que lo explicas muy bien, quiero creer que solo es por eso.

PD: No tiene que ver pero soy un Usuario Ignorante Avanzado, y no se muy bien por dónde empezar, para poder entender con mayor profundidad todo lo que explicas, como "funciona internet", los protocolos... lo que tu sabes ¿por dónde empezar? (Oigo las risas)

Juanfer Sendra dijo...
Este comentario ha sido eliminado por el autor.
Juanfer Sendra dijo...

Tengo contratado un servidor cloud VPS con un certificado de Thawte SSL 123 y está infectado por Heartbleed y no hay manera de acceder a la web en wordpress, WooCommerce, los tiempos de espera son... vamos, que no carga nunca, siempre se produce un redireccionamiento o time-out...

Desde el soporte técnico llevan casi una semana intentando solucionarlo pero todavía no han conseguido eliminar o actualizar el OPENSSL para CENTos... y así llevamos, casi una semana que la página en Wordpress NO funciona y presenta un blucle de redireccionamiento... desde el panel de control apenas podemos trabajar por la lentitud ya que todas la páginas está encriptadas... alguien tiene un caso similar ¿?

whatgoesaround dijo...

Hola, Chema, me presento con este knickname y ya dejo claro que soy un internauta normal y corriente con un nivel tirando a tristemente bajillo, aunque no soy 100% ignorante (pero estudios de informática nada de nada). Excelente la explicación y déjame que te felicite por el blog y todos sus contenidos y artículos, realmente es impresonante vuestro trabajo de investigación y se aprende la hostia leyendo. Es brutal lo de este fallo y sus implicaciones globales en la red. Un comentario me ha parecido muy agudo:"Siempre es atractiva la teoría de la conspiración porque la explicación más obvia (negligencia) es aburrida". En cuanto a lo del programa Bullrun, ¿realmente esa agencia británica de espionaje electrónico podría estar detrás? ¿Qué sentido tendría? ¿O es que las herramientas para espiar que han creado son tan brutales que se les pueden ir de las manos las consecuencias, o les dan igual con tal de controlar a los borreguitos? No viene ahora al caso, pero leo por ahí que la seguridad y privacidad en Tor también están seriamente comprometidas, y también en la aplicación Tails. Descubrí hace unas semanas el "Pequeño libro rojo del activista en la red" de Marta Peirano, que leeré. Entonces, sin que vaya todo esto en perjuicio de Marta, hasta muchas de las herramientas que ella recomienda pueden estar quedándose obsoletas. La relación es que ya uno, ni sus datos,tienen garantizadas la seguridad y la privacidad en internet. En fin, Chema, felicidades de nuevo y un saludo.

Entrada destacada

Navaja Negra: La CON de Albacete el 29 de Septiembre @navajanegra_ab @elevenpaths @0xWord

Es la sexta edición de esta CON que comenzó hace ya más de un lustro en la ciudad de Albacete , reúne el próximo 29 de Septiembre a una b...

Entradas populares