POODLE o cómo un caniche mató a SSL

Poodle o Poodlebleed es una vulnerabilidad en el diseño de la versión 3.0 de SSL. Poodle es en realidad un acrónimo de Padding Oracle On Downgraded Legacy Encryption. La vulnerabilidad permite el descifrado de texto plano de conexiones seguras. El error fue descubierto por el equipo de seguridad de Google, concretamente por el investigador Bodo Möller en colaboración con Thai Duong y Krzysztof Kotowicz. Ver paper.

Y si no soportas TLS pues aguanta SSL...

Aunque SSL 3.0 tiene casi 15 años, muchos servidores y navegadores web siguen utilizando hoy en día. Cuando los navegadores web fallan al intentar usar una versión de SSL más reciente (es decir, TLS 1.0, 1.1 o 1.2), pueden recurrir a una conexión SSL 3.0. Aquí es donde comienza el problema.
Debido a que un atacante puede provocar fallos en la conexión, incluyendo el rechazo de conexiones TLS 1.0/1.1/1.2 , puede forzar el uso de SSL 3.0 y luego explotar el bug Poodle con el fin de descifrar el contenido transmitido de forma segura entre un servidor y un navegador.

Este ataque es similar al ataque BEAST y también permite extraer el texto plano por partes desde una conexión SSL, por lo general los datos de cookies. Pero a diferencia del ataque BEAST no requiere un control tan extensivo del formato del texto en claro y por lo tanto es más práctico.

Cómo muerde el CANICHE

Veamos cómo un atacante podría obtener un texto cifrado (normalmente una cookie de sesión) y ser capaz de descifrarlo mediante este ataque.

Por si alguien todavía no lo sabe, SSL utiliza o un cifrado stream RC4 o un cifrado de bloques en modo CBC. En este último caso a modo muy genérico podríamos decir que el texto en claro se divide en bloques de tamaño fijo (n bytes) que se cifran con la misma clave (simétrica) dando como resultado bloques cifrados con el mismo tamaño. Como hemos dicho, el tamaño de los bloques a cifrar a de ser fijo, por lo que a la hora de dividir el mensaje en claro casi siempre es necesario rellenar un bloque para que tenga la misma longitud: es lo que se conoce como esquema de relleno o padding.

Luego en modo Cipher-block chaining (CBC), se aplica una operación XOR a cada bloque de texto plano con el bloque cifrado anterior antes de ser cifrado: Pi = dK(Ci) ⊕ Ci-1. Además, para hacer cada mensaje único se utiliza asimismo un vector de inicialización (IV).

Consideremos la siguiente petición HTTP que mediante el uso 3DES es dividida en varios bloques de 8 bytes (la misma idea funciona con bloques de 16 bytes si se utiliza AES):

Como veis el último bloque tiene 7 bytes de padding (representados por "•"). Antes de enviarse se cifra con 3DES o AES en modo CBC y el receptor tendrá que descifrar la cadena utilizando el siguiente esquema:

El gran problema es que con CBC en SSLv3 no se especifica el contenido de los bytes de padding ni se comprueba la integridad del padding (MAC). Es decir, "•" podría ser cualquier cosa porque el receptor no puede comprobarlo. En el ejemplo sólo basta comprobar que el último byte, el que no es de padding, sea un 7. Evidentemente el atacante sólo podrá ver el texto cifrado pero puede aprovecharse de este fallo.

Para ello duplica la petición cifrada pero sobrescribe el último bloque y la envía al receptor hasta que éste no la rechaze, de forma similar a la que se hacía cuando preguntábamos al "oráculo" con BEAST (padding oracle). La respuesta del servidor la obtendremos muy rápido si tenemos en cuenta que sólo le hará falta enviar como mucho 256 peticiones (8 bytes = 2⁸ = 256 posibilidades). Después de eso, el atacante concluirá que DK(Ci)[15] ⊕ Cn-1[15]=15 y habrá obtenido el último byte de la cookie: Pi[15]=15 ⊕ Cn1[15] ⊕ Ci1[15].

A continuación para obtener el resto de bytes de la cookie el atacante simplemente tiene que aumentar la longitud de la URL y disminuir cualquier parte posterior al valor de la cookie para que se particione de la siguiente manera:

Como veis el valor de cada cookie es desplazado y basta repetir el proceso anterior para cada uno de sus bytes.

¿En verdad es tan peligroso este CANICHE?

Mientras que las recientes vulnerabilidades Heartbleed y Shellshock afectan a servidores, Poodle permite comprometer sólo a los clientes.
Esto requiere normalmente un exploit MiTM y que javascript esté habilitado en un navegador o que no haya algún programa que limite la ejecución de código javascript. Esto disminuye la peligrosidad global de este ataque que sin embargo debe suponer la "muerte" definitiva de SSL a favor de TLS.

¿Es mi servidor vulnerable?

Compruébalo tú mismo:

- https://www.tinfoilsecurity.com/poodle
- http://poodlebleed.com/

¿Y cómo me protejo del CANICHE?

Pues a nivel de navegador lo mejor es desactivar y olvidarse para siempre de SSLv3 o de los cifrados en modo CBC que utiliza. En Firefox puedes hacerlo entrando a la configuración (about:config) y poniendo a 1 security.tls.version.min o si usas Chrome puedes arrancarlo con el parámetro --ssl-version-min=tls1. Pero como puede darte problemas al intentar conectar con servidores que sólo usan protocolos de cifrado antiguos es recomendable el soporte TLS_FALLBACK_SCSV que impide el "downgrade" desde TLS a SSL.

Por otro lado si tienes un servidor y no temes dejar fuera a los infames usuarios que utilizan navegadores obsoletos puedes también desactivar SSL 3.0. Aquí puedes ver cómo hacerlo en apache o nginx.

Referencias:
- This POODLE Bites: Exploiting The SSL3.0 Fallback
- The Poodlebleed Bug
- POODLE attacks on SSLv3 (14 Oct 2014)
- Some POODLE notes
- Google Discloses Vulnerability In SSL Web Encryption Technology
- SSL is dead, long live TLS
- This POODLE bites: exploiting the SSL 3.0 fallback
- OpenSSL: SSLv3 POODLE Vulnerability Official Release