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!