Aunque por el nombre no lo parezca, SSLv3 fue prácticamente el primer protocolo que se creó para proteger nuestras comunicaciones a través de Internet. La versión 1.0 nunca se publicó, y la 2.0 apenas duró un año por sus fallos de seguridad. Ese protocolo, SSLv3, nació hace 15 años, en 1996. Más tarde (1999) se publicó una actualización, TLS 1.0, que fue evolucionando hasta lo que tenemos ahora, TLS 1.2.
Pues bien, hace unas horas varios ingenieros de Google han descubierto un ataque para SSLv3, al que han bautizado POODLE (Padding Oracle On Downgraded Legacy Encryption, o en su traducción menos glamourosa, "Oráculo del relleno para cifrado antiguo y degradado"). A grandes rasgos, permitiría a un atacante capaz de modificar el tráfico entre tu navegador y el servidor leer ciertos datos que deberían estar protegidos, como tus cookies.
Primer paso: conseguir degradar la conexión a SSLv3
Por temas de compatibilidad, prácticamente todos los servidores y navegadores hoy en día implementan SSLv3. Así, cuando se encuentren que la otra parte no soporta protocolos más modernos, podrán seguir estableciendo una comunicación segura. Por ejemplo, Internet Explorer 6 no soporta ni TLS 1.0, así que muchos servidores ofrecen SSLv3 para no dejar sin servicio a esos usuarios.
Hasta aquí parece todo bien, ¿verdad? En realidad no. Primera pregunta que deberíamos hacernos: ¿cómo sabe el navegador si el servidor con el que se está comunicando sólo soporta SSLv3?
Si recordamos cómo funcionaba HTTPS, había una primera fase de negociación, en la que el navegador "se presenta" y le comunica al servidor qué versión del protocolo soporta. En una situación normal, el navegador ofrecería TLS 1.2, por ejemplo, y el servidor podría responder diciendo la versión más moderna que soporta es TLS 1.0, así que ambos usarían TLS 1.0. De esta forma, se garantiza la compatibilidad y el uso de la versión más segura disponible.
Un atacante puede interferir en la conexión para forzar a que se use el protocolo inseguro SSLv3
Pero hay un problema, y es que si el navegador ofrece TLS 1.2 pero no recibe respuesta, automáticamente enviará otra petición ofreciendo TLS 1.1, y así sucesivamente con versiones más antiguas hasta que el servidor seguro responda. Es decir, que un atacante que controle la conexión podría interferir y parar esas primeras ofertas de negociación, y esperar a que el cliente envíe una oferta con SSLv3, que sí dejará pasar.
Desde el punto de vista del servidor, se habrá recibido una petición de un navegador que sóo soporta SSLv3, así que se iniciará la conexión segura con este protocolo. Así de fácil, el atacante prepara la conexión a su gusto para poder realizar el ataque en sí.
Segundo paso, el padding oracle: toquetando el texto cifrado
El segundo paso del ataque es considerablemente más complejo. SSLv3 tiene dos modos de funcionamiento: o bien un cifrado continuo con RC4, que ya se sabía que es vulnerable, o bien un algoritmo de cifrado por bloques en modo CBC. En este modo, se dividen los datos a cifrar en bloques de un tamaño fijo de bytes, y se cifra cada uno y se combina con el texto sin cifrar del anterior.
La combinación es en realidad una operación, la XOR (denotada por ⊕), de la que lo único que nos interesa saber es que es reversible. Esto es, si C = A ⊕ B, queremos sacar A y conocemos B y C, entonces A = B ⊕ C.
Por aquí a alguno le habrá surgido la duda: ¿qué pasa si no podemos dividir los datos a cifrar en bloques del tamaño requerido? Por ejemplo, ¿qué hacemos para cifrar 35 bytes de datos con bloques de 8 bytes?
El relleno o "padding" es el punto débil, el que filtra la información al atacante
Lo que se hace es añadir un padding, un relleno para completar esos bytes que nos faltan. Ese padding es casi aleatorio. Si necesitamos rellenar n bytes, pondremos n-1 con datos aleatorios y en el último el número n. Es decir, que si necesito un padding de tres bytes, podríamos usar A8 B3 03. Normalmente cualquier padding será válido, salvo en un caso. Si no es necesario un padding (la longitud del texto a cifrar encaja perfectamente en los bloques), se añade un bloque más para que el último bloque, que serían datos reales, no se descarte como relleno. Y si tenemos un bloque entero (8 bytes), entonces sabremos el último byte del último bloque tiene que ser 7. Si no lo es, el servidor que reciba esa petición lo descartará y devolverá un error.
Pues bien, resulta que con ese conocimiento sobre el padding y toqueteando un poco el texto cifrado que se envía, se puede conseguir adivinar los datos sin cifrar.
POODLE, el ataque en sí
Para este ataque, se supone que el atacante puede hacer peticiones desde el navegador al servidor, por ejemplo con un código en Javascript. Estas peticiones tendrán la siguiente forma cuando las haga el navegador:
GET ruta Cookie: ???? \r\n\r\n cuerpo de la petición MAC padding
La longitud de la cookie (lo que queremos descifrar) y del código MAC son fijos, y el atacante puede controlar tanto la ruta como el cuerpo de la petición. Así, puede modificarlos para forzar que el padding ocupe un bloque entero de 8 bytes, y que además el primer carácter de la cookie caiga en la posición final de un bloque, al que llamaremos el bloque Bi .
El código Javascript hace la petición, el navegador la cifra y la envía al servidor. Antes de que llegue, el atacante intercepta el paquete y hace un pequeño truco: copia el bloque Bi en el último bloque, el que contiene el padding cifrado. Si da la casualidad de que el servidor acepta la petición, el atacante habrá obtenido una información muy valiosa: el primer carácter de la cookie.
Este proceso, que parece casi mágico, lo explicamos en el siguiente esquema:
En el esquema, el atacante conoce todos los bloques cifrados, y desconoce los predescifrados - si se me permite el palabro - y, por supuesto, el texto descifrado. Pero como el servidor ha aceptado la petición, sabe que el último byte del bloque Bn-1 (en la imagen, Y) combinado (XOR) con el último byte del bloque predescifrado (en la imagen, ?) da como resultado un 7. Entonces puede sacar el valor de ? con la siguiente operación: ? = 7 ⊕ Y. Así, ya tiene todo lo que necesita para sacar el último byte del bloque que nos interesa, esa D en la imagen: D = ? ⊕ X.
El atacante probará muchas veces este esquema hasta que el servidor acepte la petición modificada (de media, uno de cada 256 intentos). Y una vez que tenga el primer byte, repetirá el proceso con el segundo, y con el tercero, y así hasta que tenga todos los datos de la cookie o de cualquier otra cabecera HTTP.
¿Qué se puede hacer con POODLE entre manos?
Ahora que ya hemos explicado cómo funciona el ataque: ¿qué se puede lograr con él? Lo cierto es que no es ni de lejos tan potente como otras vulnerabilidades que hemos visto hace poco, como Shellshock o Heartbleed.
El ataque no es tan grave como otros: hay que poder hacer un MITM y tener tiempo para ejecutarlo (varios minutos)
El ataque es lento (256 peticiones SSL por byte dan unos cuantos minutos para descifrar algo útil), y sólo serviría para datos que se envíen continuamente en las peticiones HTTP, como las cookies. Eso sí, esas cookies pueden tener los datos de tu sesión y si alguien las descifra, podría usarlas para entrar desde su navegador con tu cuenta en el servicio que haya sido atacado.
Por otra parte, para llevar a cabo POODLE se necesita tener una posición intermedia entre el usuario y el servidor, lo cual impide que cualquiera pueda hacer este tipo de ataques. En resumen, no es un problema especialmente grave, aunque afecte potencialmente a cualquier navegador moderno y a muchos servidores.
¿Cómo me puedo proteger de POODLE?
Las recomendaciones para protegerse de POODLE empiezan con la recomendación de dejar de soportar ya SSLv3. Firefox dejará de soportarlo en la siguiente versión, Firefox 34, programada para finales de noviembre. Mientras, se puede usar una extensión para desactivarlo. En Chrome ya están probando ahora mismo cambios para desactivar SSLv3 por completo.
Además, se recomienda activar una característica en los servidores y navegadores llamada TLS_FALLBACK_SCSV , que mitigaría el ataque al parar esos intentos de que se use SSLv3 en la conexión. Si ambos la tienen activada, cualquier oferta del navegador para una versión de SSL/TLS que no sea la más moderna que soporte el servidor fallará. Esto es, si el navegador pide SSLv3 a un servidor que soporta TLS 1.2, el servidor rechazará la conexión y se evitaría así que un atacante fuerce protocolos menos seguros.
En resumen, un fallo no especialmente grave pero que debería ser la puntilla a un protocolo inseguro que ha de ser abandonado ya. Además, al haber sido descubierto por la propia Google y divulgado a todos los desarrolladores relacionados (Mozilla, OpenSSL, etc) antes de su publicación, es poco probable que sea explotado al estilo Heartbleed.
Más información
Para más información sobre el tema, os dejamos con varios enlaces (en inglés):
