# Ataque POODLE

El ataque POODLE (del inglés "Padding Oracle On Downgraded Legacy Encryption") es un exploit man-in-the-middle que aprovecha Internet y la característica del software de clientes de bajar a SSL 3.0. Si los atacantes explotan exitosamente esta vulnerabilidad, en promedio, solo necesitan hacer 256 solicitudes SSL 3.0 para revelar un byte de los mensajes cifrados. Bodo Möller, Thai Duong y Krzysztof Kotowicz del Equipo de Seguridad de Google descubrieron esta vulnerabilidad; la hicieron pública el 14 de octubre de 2014 (a pesar de que el estudio estaba fechado en "Septiembre de 2014"). Ivan Ristic no considera el ataque POODLE tan serio como Heartbleed o Shellshock. El 8 de diciembre de 2014 se anunció una variación al ataque POODLE que impactaba TLS.
El identificador de la vulnerabilidad del ataque POODLE original es CVE-2014-3566. La empresa F5 Networks también registró el CVE-2014-8730, vea ataque POODLE contra TLS.

## Explotación de degradación elegante

POODLE ejemplifica una vulnerabilidad que tiene éxito gracias a un mecanismo diseñado para reducir la seguridad en aras de la interoperabilidad. Tales fallas requieren un cuidado especial en el diseño de sistemas en los dominios con altos niveles de fragmentación. En este tipo de dominios degradación seguridad agraciado puede llegar a ser común.

## Prevención

Para mitigar el ataque POODLE, un enfoque consiste en desactivar completamente SSL 3.0 en el lado del cliente y el servidor. Sin embargo, algunos clientes y servidores antiguos no admiten TLS 1.0 y superiores. Por lo tanto, los autores del artículo sobre los ataques POODLE también insisten en la implementación de TLS_FALLBACK_SCSV tanto en navegador como en la aplicación de servidor, lo que hace los ataques de degradación imposible.
Otra mitigación es implementar "división de registros anti-POODLE". Divide los registros en varias partes y asegura que ninguno de ellos puede ser atacado. Sin embargo, el problema de la división es que, aunque válido de acuerdo con la especificación, puede también causar problemas de compatibilidad debido a problemas en las implementaciones de servidor. Opera 25 ha implementado esta mitigación además de TLS_FALLBACK_SCSV.
El navegador Chrome de Google y sus servidores ya soportan TLS_FALLBACK_SCSV. Google declaró en octubre de 2014 se tenía previsto eliminar por completo el uso de SSL 3.0 de sus productos dentro de unos pocos meses. La degradación a SSL 3.0 se ha deshabilitado en Chrome 39, lanzado en noviembre de 2014.
Mozilla ha deshabilitado SSL 3.0 en Firefox 34 y ESR 31.3, que fueron puestos lanzados en diciembre de 2014, y ha añadido soporte de TLS_FALLBACK_SCSV en Firefox 35.
Microsoft ha publicado un boletín de seguridad para explicar cómo deshabilitar SSL 3.0 en Internet Explorer y Windows OS, y el 29 de octubre de 2014, Microsoft lanzó un "Fix it" que inhabilita SSL 3.0 en Internet Explorer en Windows Vista / Server 2003 y superiores y anunció el plan para deshabilitar SSL 3.0 por defecto en sus productos y servicios dentro de unos meses. Microsoft deshabilitó el repliegue a SSL 3.0 en Internet Explorer 11 para los sitios de modo de protección el 10 de febrero de 2015. Microsoft anunció sus planes de desactivar completamente SSL 3.0 por defecto en IE 11 el 14 de abril de 2015.
Safari de Apple (en OS X 10.8, iOS 8.1 y posteriores) se ha protegido contra POODLE retirando el uso a todos los protocolos CBC en SSL 3.0, Sin embargo, esto deja sólo RC4 que también está completamente roto por los ataques RC4 en SSL 3.0.
Para evitar el ataque POODLE, algunos servicios web han abandonado el uso de SSL 3.0. Los ejemplos incluyen CloudFlare y Wikimedia.
NSS versión 3.17.1, publicado el 3 de octubre de 2014, y 3.16.2.3, lanzado el 27 de octubre de 2014, introdujo la compatibilidad con TLS_FALLBACK_SCSV, y NSS desactivará SSL 3.0 por defecto en abril de 2015. versiones de OpenSSL 1.0.1j, 1.0.0o y 0.9.8zc, lanzado el 15 de octubre de 2014, introdujo la compatibilidad con TLS_FALLBACK_SCSV. La versión LibreSSL 2.1.1, lanzado el 16 de octubre de 2014, deshabilitó SSL 3.0 por defecto.

## Ataque POODLE contra TLS

Una nueva variante del ataque POODLE original fue anunciada el 8 de diciembre de 2014. Este ataque explota las fallas de implementación del modo de cifrado CBC en los protocolos TLS 1.0 al 1.2. A pesar de que las especificaciones TLS requieren de los servidores que comprueben el relleno, algunas implementaciones no lo validan correctamente, lo que hace que algunos servidores vulnerables a POODLE incluso si deshabilitan SSL 3.0. SSL Pulse mostró que "aproximadamente el 10% de los servidores son vulnerables al ataque POODLE contra TLS" cuando esta vulnerabilidad fue anunciada. La CVE-ID de F5 Networks es la CVE-2.014-8730. La entrada en NVD del NIST afirma que este CVE-ID es para ser utilizado sólo para la implementación F5 Networks de TLS, y que otros proveedores cuyos productos tienen la misma falta en la validación del relleno en sus implementaciones como A10 Networks y Cisco Systems necesitan emitir su propio CVE-ID por sus errores de implementación, porque esto no es un defecto en el propio protocolo y es un defecto en la implementación del protocolo.
El ataque POODLE contra TLS se encontró que era más fácil de iniciar que el ataque inicial POODLE contra SSL. No hay necesidad de rebajar los clientes a SSL 3.0, lo que significa que se necesitan menos pasos para ejecutar un ataque con éxito.