TicketBleed: Un "Heartbleed" para los productos F5 BIG-IP

El nombre de esta vulnerabilidad que ha sido publicada esta semana tiene claras reminiscencias, claramente, al ya famoso Heartbleed (al que le dediqué un capítulo en el libro de Hacking Web Technologies). De hecho, tiene mucho que ver, aunque a menor escala, ya que en lugar de conseguir un volcado de 64 Kas de memoria, se consigue el volcado de 31 bytes de memoria aleatoria en cada petición, lo que lo hace menos efectivo. Además, F5 TLS solo está presente en los productos de F5 BIG-IP, y la versión vulnerable no en todos. No obstante, el bug es peligroso y debe parchearse cuanto antes.

Figura 1: TicketBleed: Un "Heartbleed" para los productos F5 BIG-IP

El fallo de TicketBleed reside en la implementación que hace el software de F5 TLS en las reconexiones rápidas de sesiones TLS, debido a cómo gestiona el código del producto los Session ID y los Session Tickets cuando se intenta reutilizar una sesión TLS anterior. La idea es bastante sencilla, y tiene que ver con mejorar el rendimiento de los sistemas criptográficos en la web. Os lo intento explicar resumidamente para que entendáis el bug. Si queréis más detalles, la lectura obligatoria es el libro de Cifrado de las Comunicaciones Digitales.

Figura 2: TicketBleed (CVE-2016-9244)

El protocolo TLS tiene un impacto en el rendimiento de los protocolos que se tunelicen sobre él por culpa de los algoritmos criptográficos que añaden privacidad a la comunicación. Estos son especialmente costosos en la fase de negociación inicial de las claves y menos costosos luego en el cifrado y descifrado de paquetes una vez que ya ha quedado establecida la negociación inicial - el famoso saludo -.

TLS Resumption in a nutshell

Como sobre el protocolo TLS pueden ir protocolos no orientados a conexión, es decir, que no mantienen sesiones vivas sino que realizan peticiones discretas y arrítmicas - como visitar una web, leer durante unos minutos una noticia y hacer clic en un link que navega a otra página dentro del mismo servidor - en los protocolos de cifrado se creo el concepto de reconexión rápida, es decir, re-aprovechar la fase inicial de una negociación TLS que no haya caducado para mejorar la velocidad. 

Figura 3: RFC 5077 TLS Session Resumption withos Server-Side State

En el estándar RFC 5077 se especifica que esta es una característica que debe tener soportada el servidor y que para ello el cliente debe enviar el Session ID y el Session Ticket, es decir, el identificador de la sesión que se quiere recuperar y la información necesaria para recuperarla. 

Figura 4: Especificación de gestión del SessionID

El servidor deberá devolver el mismo SessionID al cliente si se puede reutilizar esta sesión, por lo que cuando el cliente pide una reconexión debe enviar un SessionID y un SessionTicket. El servidor comprueba que el SessionID no está vacío y que es válido, por lo que devuelve una sesión con el mismo SessionID que copia directamente desde el SessionID que envía el cliente.

Y aquí está el problema.

La longitud del SessionID puede ser de 32 bytes, pero puede ser también solo de 1 byte. Si un cliente crea una conexión con un SessionID de 1 byte de longitud y el el servidor TLS copia 32 bytes de la memoria donde está el SessionID que ha recibido del cliente copiado, lo que contendrá el SessionID que se envía desde el servidor será 1 byte con el SessionID que envió el cliente, más 31 bytes de la memoria del servidor, en concreto de la memoria que utiliza el proceso TLS, por lo que puede venir cualquier cosa, como en el caso de HeartBleed.

Figura 5: Código vulnerable en F5 TLS

Por supuesto, cada petición solo "leakea" 31 bytes, pero si son los de una contraseña, un id o cualquier otra información sensible, el impacto puede ser muy alto. Además, como en el caso de HeartBlead, se puede poner un cliente a forzar el volcado de estos 31 bytes durante días y ver qué ha ido cayendo en el canasto, que seguro que habrá algo jugoso.

Figura 6: Test de TicketBleed y script en Go para probarlo tú mismo

El investigador Filippo Valsorda ha puesto un sitio en la web para que puedas comprobar si un servidor de F5 BIG-IP tiene este software F5 TLS vulnerable a TicketBleed o no. Nosotros lo hemos añadido a nuestro sistema de pentesting persistente Faast, pero si tienes equipos F5 BIG-IP deberías asegurarte que tienes todo actualizado a la última versión.

Saludos Malignos!

DROWN Attack: Descifrar HTTPs TLS por bugs en SSLv2

Coincidiendo con el 1 de Marzo y la RSA Conference, tenemos un nuevo ataque criptográfico a HTTPs al que se le ha puesto un nombre llamativo. En este caso The DROWN (Decrypting RSA with Obsolete and Weakened eNcryption) Attack que viene a afectar a aproximadamente una tercera parte de los servidores HTTPs en Internet.

Figura 1: The Drown Attack

El ataque se describe en el paper que han publicado en el sitio, pero básicamente lo que hacen es aprovecharse de que un servidor permita conexiones SSLv2 inseguras y conexiones TLS para capturar las sesiones TLS y descifrar las claves RSA que se usan en la conexión TLS mediante el ataque a SSLv2. Es decir, tal y como dice el paper necesitan capturar unas 1.000 sesiones TLS utilizando intercambios de claves RSA, después hacer unas 40.000 conexiones SSLv2 y realizar 2 elevado a 50 operaciones de cifrado simétrico para descifrar 1 sesión TLS. Pero si el premio es gordo, hay que ir a por ello.

Figura 2: Resumen del proceso de ruptura de 1 sesión TLS

Los servidores vulnerables son los que permitan ambos protocolos, es decir, TLS y SSLv2, además de aquellos que comparten claves públicas en frontales y alguno de ellos soporta SSLv2. En la web han publicado una herramienta para comprobar si tu sitio es vulnerable o no.

Figura 3: Sitios vulnerables a DROWN

En la siguiente lista tenéis, por ejemplo, sitios de microsoft.com vulnerables a DROWN. Como veis a este bug le han asignado el CVE-2016-0703. Nosotros hemos añadido esta comprobación a la lista de plugins de nuestro motor de Faast para que puedas erradicar estos protocolos inseguros lo antes posible.

Figura 4: Sitios de microsoft con vulnerabilidad DROWN

El paper que describe el proceso de explotación paso por paso lo tienes en la web de The Drown Attack, puro para amantes de criptografía, por lo que si quieres entender bien RSA te recomiendo que leas el libro de Cifrado de las comunicaciones digitales.

Saludos Malignos!

¿Por qué sale el candado rojo en los mensajes de Gmail?

Supongo que muchos ya estaréis al día de que Gmail ha añadido una nueva función para mejorar la información sobre los mensajes de correo electrónico que recibe de forma insegura. Si todavía no has visto ninguno, te recomiendo que vayas a la carpeta de Spam de tu cuenta de Gmail y busques por allí, verás que hay más de uno seguro que tiene el candadito rojo de correo inseguro.

Figura 1: ¿Por qué sale el candado rojo en los mensajes de Gmail?

Ese candado rojo abierto al lado del mensaje significa que la conexión que el servidor de correo saliente del dominio del remitente hizo con el servidor de correo entrante de Gmail no se hizo sobre un túnel TLS o SSL. Es decir, cuando se entregó ese mensaje de correo electrónico a Gmail para que lo pusiera en tu buzón, se hizo por el puerto 25 sin cifrado alguno, por lo que cualquiera que pudiera esnifar el tráfico de la red en medio podría haberlo leído.

Figura 2: Mensaje enviado por SMTP sin cifrado puerto 25

Esto lo tienes explicado en la página de soporte que ha añadido Google en su knowledge base, y no hay mucho que puedas hacer a nivel de usuario para que tus correos electrónicos lleguen sin candado, ya que es algo de configuración del servidor de correo electrónico que utilizas para enviar los mensajes.

Figura 3: Explicación de Google sobre el candado rojo

Si cuando envías un mensaje de correo electrónico llega a las cuentas de Gmail con el candado, entonces es que tu servidor de correo electrónico no has configurado el servidor SMTP de correo saliente para que envíe todo el tráfico cifrado.

Figura 4: Información sobre los puertos con cifrado en Gmail para SMTP

Para ello, debes hablar con tu proveedor, o si gestionas tú el servidor de correo electrónico activar la opción de conexión TLS o SSL por los puertos 25 o 465 con SSL yo 587 con TLS. Ojo, si tu cuenta es de Gmail, actívalo si tus mensajes llegan con ese candado, que podría ser que hubieras configurado tu cliente de correo electrónico con SMTP en lugar de IMAP.

Figura 5: Conexión a tu buzón usando IMAP con SSL para enviar y recibir e-mails

Por supuesto, esto no garantiza que el correo electrónico no haya podido ser interceptado por alguien en medio que haga un ataque de man in the middle con capacidad de tener certificados emitidos a nombre de los servidores de correo electrónico, tal y como se explicaba en este gráfico de servilleta que apareció en uno de los documentos filtrados por Edward Snowden.

Figura 6: Explicación de Muscular de la NSA para espiar Gmail

Si no hay un proceso de Certificate Pinning entre los servidores de correo electrónico saliente y servidor de correo entrante, entonces el atacante podría dar al servidor de correo saliente un certificado falso emitido por una entidad certificadora controlada en la que confíe el servidor de correo saliente y descifrar los mensajes.

Figura 7: Correo de Gmail enviado sin cifrar

Gmail entre sus servidores utiliza autenticación mutua, pero si el servidor viene desde un servidor de correo saliente de tercero entonces solo hay conexiones SSL o TLS, pero no Mutual SSL o Mutual TLS, ya que para ello debería haber un intercambio de certificados entre ambos servidores a nivel de configuración.

Figura 8: Gmail permite las conexiones SMTP puerto 25 sin cifrado

Este es un esfuerzo más desde de Google por cifrar el tráfico de Internet y ayuda a evitar la interceptación de correos por parte de atacantes, pero desde luego, mientras que no haya Mutual TLS/SSL entre todos los servidores de correo electrónico, los estados podrán seguir espiando el correo como lo hacían antes y la única solución sigue siendo usar PGP o S/MIME para tener cifrado end-to-end, así que, el que no salga el candado no garantiza que nadie haya podido espiar ese mensaje desde que salió del cliente de correo electrónico del remitente. Si quieres saber más sobre criptografía, ya sabes que una lectura recomendable es el libro de Cifrado de las comunicaciones digitales.

Saludos Malignos!

RC4 No More: Robo de cookies en HTTPS/TLS y Cracking de redes WiFi con WPA/TKIP

Los investigadores Mathy Vanhoef y Frank Piessens han agitado el ya agitado mundo de la criptografía - recordemos que las investigaciones de FREAK y SKIP TLS son aún muy recientes - con la implementación práctica de ataques contra conexiones HTTPS/TLS que permiten robar las cookies de una web y contra el cifrado TKIP (Temporary Key Integrity Protocol) que utilizan las redes WPA. Ambos ataques se basan en aplicar un ataque práctico contra el algoritmo RC4, utilizado en ambos entornos.

Figura 1: RC4 No More: Robo de cookies en HTTPS/TLS y Cracking WiFI WPA-TKIP

Todo el trabajo ha sido publicado en un paper titulado "All your biases belong to us: Breaking RC4 in WPA-TKIP & TLS", donde se analizan todas las debilidades o sesgos conocidos en la generación del Keystream usado en RC4, cómo ponerlos en un ataque práctico que implementa un algoritmo de optimizado para que sean útiles y funcionales en dos entornos en los que se utiliza RC4, como son las conexiones TLS en el protocolo HTTPS, y el cifrado del tráfico en las redes WiFi WPA-TKIP.

Figura 2: All your biases belong to us. Breaking RC4 in WPA-TKIP and TLS

La base del estudio son los sesgos, o lo que es lo mismo, las posibilidades que tienen determinados bytes de un keystream utilizado en RC4 de tener determinados valores de manera independiente o dependientes del valor que tengan otros bytes. Para que sea fácil de entender, cuando se genera un keystream en RC4, éste debería ser totalmente aleatorio, pero tal y como se construyen en la práctica estos keystream no es así.

Figura 3: Una de las tablas de sesgos de probabilidad aplicada

Algunos de estos sesgos de probabilidad ya eran conocidos, y lo que han hecho los investigadores ha sido ponerlos en práctica, además de generar nuevos sesgos en bytes en base a resultados de experimentación empíricos.

Figura 4: Análisis de sesgos introducidos en los dos primeros bytes del keystream

Con ellos, han sido capaces de realizar ataques para robar las cookies de una página web protegidas por una conexión HTTPs con TLS en unas 52 horas de media, lo que no es mucho teniendo en cuenta que mucha gente no mata las cookies, así que cualquiera que pueda estar capturando el tráfico en un backbone, en la red local, o en la red WiFi, podría tener una cookie de sesión válida en un par de días.

Figura 5: Escenario de robo de cookie de sesión con RC4 No More 

En el siguiente vídeo se puede ver una demostración práctica de cómo se roban las cookies de una web en un entorno como el descrito.

Figura 6: Robo de cookie de sesión con RC4 No More

Este tipo de ataques se podría realizar a cualquier conexión TLS, como por ejemplo algunas conexiones VPN, por lo que la recomendación es, como dicen los investigadores, RC4 No More. Si tienes aún un sitio web que permita RC4 o tienes una red WPA-TKIP - que antes se atacaba solo mediante el craking WPA de la clave en base a diccionarios - , asume que en poco tiempo cualquiera podría acceder a tus datos. Para los que quieran conocer más sobre los algoritmos criptográficos, os recomiendo que le deis una buena lectura al libro de Criptografía: De la cifra clásica a RSA.

Saludos Malignos!

Logjam o el bug que pudo usar la NSA para ver el tráfico de tu VPN con TURBULENCE

Hoy mismo se acaba de publicar información sobre Logjam, un nuevo fallo de seguridad en los certificados digitales de los sitios web al estilo de FREAK. En este caso, este fallo que viene también de los años 90 podría venir a explicar cómo la NSA podría haber estado descifrando las comunicaciones VPN para poder acceder al tráfico mediante un esquema de man in the middle tal y como se describe en el proyecto TURBULENCE.

Figura 1: Logjam o el bug que pudo usar la NSA para ver el tráfico de tu VPN con TURBUENCE

Para ponernos en situación, hace un tiempo, como parte de las filtraciones de Edward Snowden,  el periódico alemán Der Spiegel publicó un conjunto de diapositivas de un proyecto del año 2009 de la NSA llamado TURBULECE. Dicho proyecto detalla cómo la NSA tiene tecnología para poder hacer un ataque man in the middle a las conexiones VPN aprovechando algún tipo de debilidad, tal y como se detalla en la imagen siguiente.

Figura 2: Esquema de man in the middle en VPN de TURBULENCE

Conseguir responder a qué vulnerabilidad se podría estar utilizando era parte de la investigación de muchos criptógrafos, y ahora se ha publicado la investigación de Logjam, que parece estar en condiciones de explicar esta infraestructura por medio de un bug que viene de los años 90 y que puede permitir hacer un ataque de man in the middle forzando al servidor a utilizar claves Diffie-Hellman (DH) de 512 bits de longitud, lo que se conocen como claves DHE_EXPORT ya que fueron las que estaban aprobadas por el gobierno de Estados Unidos para su exportación - exactamente igual que sucedía en el bug de FREAK y sus algoritmos de cifrado aprobados para exportación -.

Figura 3: Paper que describe el bug de logjam

Conociendo que muchos certificados se crearon con el soporte para DHE_EXPORT, los investigadores han sido capaces de hacer un ataque de man in the middle forzando al servidor a utilizar claves DHE_EXPORT.

Figura 4: Esquema de man in the middle usando Logjam

Por supuesto, este downgrade no es suficiente por sí mismo y es necesario contar con una buena cantidad de claves DHE_EXPORT precomputadas y crackeadas - el paper habla de las más comunes - para en tiempo real lograr romper el 80% de las conexiones TLS.

Figura 4: Tiempo medio de ruptura de conexiones

Este bug se suma a la larga lista de fallos de ataques a SSL que hemos visto en los últimos tiempos, como FREAK, Bar Mitzvah, Poodle, Lucky13, BEAST, TIME, BREACH, etcétera, y obliga otra vez a los servidores a poner certificados digitales nuevos sin el soporte para DHE_EXPORT en la negociación Diffie-Hellman. Nuestro servicio de Pentesting Persistente Faast detecta esta debilidad desde el mismo día que se hizo pública.

Saludos Malignos!

Bar Mitzvah: Nuevo ataque a SSL/TLS te roba las sesiones

En la reciente Black Hat Asia 2015 se acaba de presentar un nuevo trabajo de investigación sobre las vulnerabilidades de las conexiones SSL/TLS cuando estas utilizan el algoritmo de cifrado RC4. Éste es uno de los algoritmos criptográficos comúnmente utilizado en el cifrado de comunicaciones digitales, y de él se conocen vulnerabilidades que lo hacen totalmente inseguro desde hace más de trece años. Ahora en este nuevo trabajo, publicado por Imperva se ha mostrado un ataque curioso al que han denominado Bar Mitzvah, y que está correctamente explicado en el artículo de investigación.

Figura 1: Bar Mitzvah: Nuevo ataque a SSL/TLS te roba las sesiones

Para entender los ataques, hay que describir primero el concepto de Invariance Weakness que ellos utilizan como base de su investigación. Esta debilidad se conoce desde hace tiempo y se produce por el sistema pseudo-aleatorio que tiene el algoritmo RC4 para generar las claves. Este fallo hace que el motor de aleatoriedad, produzca unas claves de cifrado inseguras concretas - a las que denominan "Hits" - con un patrón en forma de L que las caracteriza.

Figura 2: Claves inseguras en forma de L generan que los LSB (Least Significant Bit)
del Pseudo-Random Stream sean inseguros

En el paper "Weaknesses in the Key Scheduling Algorithm of RC4" se estudia en profundidad y se dice que, de todas las claves que se utilizan en una implementación RC4 hay muchas que tienen debilidades y podrían romperse.

Figura 3: Paper que estudia las debilidades de las claves utilizadas en RC4

Estas claves con el bug de Invariation Weakness permiten que un atacante pueda descifrar en poco tiempo los primeros 100 bytes de una conexión SSL/TLS, dejando parte del tráfico de la sesión al descubierto. Esos 100 bytes no son mucho, más teniendo en cuenta que el Handshake de la sesión SSL/TLS ya se lleva 35 bytes, pero conseguir descifrar 65 bytes puede ser más que suficiente, como han demostrado.

Ataque 1: Captura de tráfico de red sin ataque man in the middle

En un escenario de ataque de red en el que solo se pueda acceder al tráfico, se podrían estar escuchando todas las sesiones SSL y descifrar los 65 bytes de aquellas que vinieran cifradas con una clave "Hit". Una vez analizados esos 65 bytes, se procedería a ver qué contenido va en esos, para lanzar un ataque a posteriori.

Figura 4: Bytes que se pueden descifrar. Desde el 36 al 100 del Upstream.
(Upstream: del cliente al servidor)

El éxito del ataque es cuando en esos 65 bytes se puede sacar parte de la cookie de sesión de la aplicación. Con una parte de 65 bytes de una cookie de sesión de ASP.NET o de PHP, se puede realizar un ataque de fuerza bruta para conseguir obtener una cookie válida en tiempo y forma. Una vez conseguida las cookies, se podría hacer un hijacking completo. En el estudio, los investigadores también hacen sus cálculos de si en esos 65 bytes vienen partes de una contraseña, para saber cuánto se tardaría en crackear la contraseña de forma total.

Ataque 2: Captura de tráfico de red con un ataque man in the middle

Como se puede suponer en el ataque 1, para conseguir tener éxito hay que tener algo de fortuna para capturar las claves "Hits" y que en los 65 bytes que se pueden descifrar haya algo que permita crackear información sensible para secuestrar una cuenta o sesión. Sin embargo, si se tuviera un control en el cliente mediante un ataque de man-in-the-middle similar al que propone BEAST, se puede entonces generar mucho más tráfico en la sesión del cliente para conseguir más "Hits" y por tanto conseguir más partes de la cookie de sesión o de una clave.

Figura 5: Porcentajes de contraseñas crackeadas en ataques utilizando más o menos LSBs

Al final, existiendo estas debilidades, y conociendo todo lo que ya ha pasado en las redes WiFi que utilizan WEP - basado en RC4 - está claro que la conclusión a la que llegan los investigadores es la adecuada. Deshabilita RC4 en el servidor y en el cliente.

Saludos Malignos!