SSL/TSL bajo ataque(I): BEAST
TLS (Transport Layer Security) y su antecesor SSL (Security Socket Layer) son los protocolos de seguridad más usados en la navegación web y en el comercio electrónico. Originariamente, el protocolo TCP/IP no contenía protección criptográfica alguna que ocultara a terceras personas situadas en los nodos intermedios de la ruta la información transmitida entre los servidores situados en sus extremos, lo que hacía a las comunicaciones vulnerables a ataques de sniffing y de eavesdroping.
Sin embargo, la necesidad de implementar transacciones comerciales seguras a través de Internet llevó a los diseñadores del navegador Netscape a incluir una nueva subcapa de seguridad situada entre las capas 4 (transporte, TCP) y 5 (aplicación, HTTP) de la pila de protocolos OSI. Esta nueva capa de seguridad consistía en un protocolo orientado a la conexión que cifraba las comunicaciones entre un servidor y un cliente utilizando para ello un sistema de criptografía simétrica (por lo general, AES). Antes de iniciar cada conexión, servidor y cliente realizaban un apretón de manos (handshake) a lo largo del cual intercambiaban sus certificados electrónicos, los verificaban, y finalmente se ponían de acuerdo en el uso de una clave de criptografía simétrica, que era elegida por el ordenador del cliente y transmitida al servidor por medio de la clave pública de este último. Tras ello, se iniciaba la comunicación entre ambos dispositivos utilizando cifrando los mensajes utilizando el algoritmo AES.
En las dos últimas décadas se han desarrollado diversos vectores de ataque. En este artículo, analizaremos BEAST, que afecta a TSL 1.0 y a todas las versiones de SSL:
En SSL/TSL, AES funciona utilizando el modo CBC (Cipher Block Chaining) de cifrado en cadena, en cuya virtud, el texto a cifrar P2 se combina con el resultado del cifrado del bloque anterior C1, mediante la operación lógica xor.
Al resultado se le aplica la función de cifrado, tal y como se señala en la ecuación y en la imagen subsiguiente:
C2 = Ek(C1 xor P2)
El bloque cifrado anterior que se combina con el bloque de texto plano, recibe el nombre de vector de inicialización.
Esta estructura del cifrado de bloques es susceptible de un tipo de ataque concebido a principios de la década de los años 2000 por los criptógrafos Phillip Rogaway y Wei Dai:
El ataque de Wei Dai
Supongamos que el cliente Blas inicia una comunicación con el servidor Ana a través de SSL/TSL. Una tercera persona, María, consigue asumir el papel de hombre en el medio e interceptar las comunicaciones de ambos, que sin embargo no puede descifrar por no conocer la clave simétrica. María consigue entonces atraer a una página web suya a Blas, cuyo navegador tiene deshabilitada la política del mismo origen. El script del servidor de María, que se ejecuta en el navegador de Blas, puede enviar paquetes de información de contenido arbitrario hacia el servidor de Ana, utilizando para ello la conexión SSL/TSL abierta entre ambos. Dichos paquetes de información son encriptados utilizando el cifrado AES.
En el ataque concebido por Wei Dai, María capturaría una petición (request) encriptada de HTTP enviada por Blas a Ana, que estaría compuesta por varios bloques de cifrado. De lo que se trataría es de adivinar el contenido del texto plano de cada uno de estos bloques, comenzando por el primero de ellos. Para ello, el script de la web de María enviaría al navegador de Blas un bloque de texto plano de prueba (M), con el objetivo de que lo reenvíe al servidor de Ana. Blas lo encriptará utilizando el modo CBC del cifrado AES y la contraseña de la conexión SSL/TSL con Ana, enviando tras ello el bloque encriptado M’, que es capturado por María.
Aprovechando esta propiedad, tenemos que:
M = Ck xor Ci-1 xor Pi
M’ = Ek(Ck xor M)
M’ = Ek(Ck xor Ck xor Ci-1 xor Pi)
M’ = Ek(Ci-1 xor Pi)
Tras el envío del bloque M’, María lo interceptará y lo comparará con el bloque Ci. Si ambos son iguales, María habrá adivinado el texto plano correspondiente al bloque Ci, que será igual a Pi.
Dado que cada bloque tiene 128 bits de tamaño, María necesitaría del orden de 264 intentos para adivinar el contenido del bloque en cuestión. Por esa razón, este ataque fue considerado impracticable hasta la publicación en el año 2017 del trabajo de los criptógrafos Thai Duong y Juliano Rizzo, que consiguieron manipular hábilmente los límites de los bloques del cifrado AES, permitiendo adivinar byte por byte el contenido de cada bloque, y provocando que fuesen necesarios tan sólo 256 intentos para adivinar el contenido de cada byte. El nuevo método de ataque fue recibió el nombre BEAST (Browser Exploit Against SSL/TSL).
El ataque BEAST
Supongamos que enviamos al servidor de María una petición HTTPS, con método POST y solicitando el URL /AAAAAA. La petición tendría la siguiente estructura:
POST /AAAAAA HTTP/1.1
REQUESTHEADERS[…]
REQUESTBODY[…]
Para simplificar, supongamos que el tamaño del bloque de cifrado es tan sólo de 8 bytes. A la hora de proceder al encriptado de la petición, ésta se dividiría en bloques según el esquema siguiente:
Como se puede comprobar, el atacante conoce de antemano el contenido de los dos primeros bloques, y de casi todo el tercer bloque, con excepción de su último byte, que contiene el inicio de la sección de encabezados (headers) de la petición. Al atacante le basta con realizar como mucho 256 intentos (uno por cada carácter ASCII) para adivinar el contenido del último byte, que corresponde al carácter R. Una vez que el contenido de dicho byte ha sido determinado, el URL de la petición se reduce en un carácter, y pasa a consistir en 5 As consecutivas /AAAAA, en lugar de 6. Como consecuencia de ello, el límite del bloque se desplaza una posición a la izquierda, y con ello es posible adivinar el segundo byte de la sección de encabezados, que equivale al carácter E. Mediante la sucesiva manipulación del límite del bloque, la atacante María es capaz de descifrar progresivamente el contenido de todo la sección, y con ello robar las cookies de sesión de Blas.
Para que el ataque, tal y como se ha descrito, tenga éxito es necesario que el script de la página web de María pueda enviar desde el navegador de Blas peticiones HTTP portadoras de cookies al servidor de Ana. Los autores descubrieron que, cuando menos, tres APIs utilizadas en el ámbito de la navegación web soportaban semejante característica: HTML5 WebSocket API, Java URLConnection API y Silverlight WebClient API. En la actualidad, se estima que cerca del 30% de los equipos informáticos utilizan navegadores vulnerables al ataque BEAST.