POODLE (que significa " Padding Oracle On Downgraded Legacy Encryption ") es una vulnerabilidad de seguridad que aprovecha el respaldo a SSL 3.0 . [1] [2] [3] Si los atacantes explotan con éxito esta vulnerabilidad, en promedio, solo necesitan realizar 256 solicitudes SSL 3.0 para revelar un byte de mensajes cifrados. Bodo Möller, Thai Duong y Krzysztof Kotowicz del equipo de seguridad de Google descubrieron esta vulnerabilidad; divulgaron la vulnerabilidad públicamente el 14 de octubre de 2014 (a pesar de que el documento estaba fechado "septiembre de 2014" [1] ). [4] El 8 de diciembre de 2014, se anunció una variación de la vulnerabilidad POODLE que afectaba a TLS . [5]
El CVE-ID asociado con el ataque POODLE original es CVE - 2014-3566. F5 Networks también presentó una solicitud para CVE - 2014-8730, consulte la sección Ataque POODLE contra TLS a continuación.
Para mitigar el ataque POODLE, una estrategia es desactivar por completo SSL 3.0 en el lado del cliente y del servidor. Sin embargo, algunos clientes y servidores antiguos no admiten TLS 1.0 y versiones posteriores. Por lo tanto, los autores del artículo sobre los ataques POODLE también recomiendan la implementación de TLS_FALLBACK_SCSV en el navegador y el servidor, [6] lo que hará que los ataques de degradación sean imposibles. [1] [7]
Otra mitigación es implementar una "división de registros anti-POODLE". Esta divide los registros en varias partes y garantiza que ninguna de ellas pueda ser atacada. Sin embargo, el problema de la división es que, aunque es válida según la especificación, también puede causar problemas de compatibilidad debido a problemas en las implementaciones del lado del servidor. [8]
Puede encontrar una lista completa de versiones de navegadores y niveles de vulnerabilidad a diferentes ataques (incluido POODLE) en el artículo Seguridad de la capa de transporte .
Opera 25 implementó esta mitigación además de TLS_FALLBACK_SCSV. [9]
El navegador Chrome de Google y sus servidores ya admitían TLS_FALLBACK_SCSV. Google declaró en octubre de 2014 que planeaba eliminar por completo la compatibilidad con SSL 3.0 de sus productos en unos pocos meses. [7] La opción de respaldo a SSL 3.0 se ha desactivado en Chrome 39, lanzado en noviembre de 2014. [10] SSL 3.0 se ha desactivado de forma predeterminada en Chrome 40, lanzado en enero de 2015. [11]
Mozilla deshabilitó SSL 3.0 en Firefox 34 y ESR 31.3, que se lanzaron en diciembre de 2014, y agregó soporte para TLS_FALLBACK_SCSV en Firefox 35. [12]
Microsoft publicó un aviso de seguridad para explicar cómo deshabilitar SSL 3.0 en Internet Explorer y el sistema operativo Windows , [13] y el 29 de octubre de 2014, Microsoft lanzó una solución que deshabilita SSL 3.0 en Internet Explorer en Windows Vista / Server 2003 y superiores y anunció un plan para deshabilitar SSL 3.0 de forma predeterminada en sus productos y servicios dentro de unos meses. [14] Microsoft deshabilitó la opción de respaldo a SSL 3.0 en Internet Explorer 11 para los sitios en modo de protección el 10 de febrero de 2015, [15] y para otros sitios el 14 de abril de 2015. [16]
Safari de Apple (en OS X 10.8, iOS 8.1 y posteriores) mitigó POODLE al eliminar el soporte para todos los protocolos CBC en SSL 3.0, [17] [18] sin embargo, esto dejó a RC4 que también está completamente dañado por los ataques RC4 en SSL 3.0. [ cita requerida ] POODLE fue completamente mitigado en OS X 10.11 (El Capitan 2015) e iOS 9 (2015).
Para evitar el ataque POODLE, algunos servicios web dejaron de ofrecer soporte para SSL 3.0. Algunos ejemplos son CloudFlare [19] y Wikimedia [20] .
Las versiones 3.17.1 (publicadas el 3 de octubre de 2014) y 3.16.2.3 (publicadas el 27 de octubre de 2014) de Network Security Services introdujeron compatibilidad con TLS_FALLBACK_SCSV, [21] [22] y NSS deshabilitará SSL 3.0 de manera predeterminada en abril de 2015. [23] [ necesita actualización ] Las versiones 1.0.1j, 1.0.0o y 0.9.8zc de OpenSSL , publicadas el 15 de octubre de 2014, introdujeron compatibilidad con TLS_FALLBACK_SCSV. [24] La versión 2.1.1 de LibreSSL , publicada el 16 de octubre de 2014, deshabilitó SSL 3.0 de manera predeterminada. [25]
El 8 de diciembre de 2014 se anunció una nueva variante del ataque POODLE original. Este ataque explota los fallos de implementación del modo de cifrado CBC en los protocolos TLS 1.0 - 1.2. Aunque las especificaciones TLS requieren que los servidores comprueben el relleno, algunas implementaciones no lo validan correctamente, lo que hace que algunos servidores sean vulnerables a POODLE incluso si desactivan SSL 3.0. [5] SSL Pulse mostró que "alrededor del 10% de los servidores son vulnerables al ataque POODLE contra TLS" antes de que se anunciara esta vulnerabilidad. [26] El CVE-ID para el error de implementación de F5 Networks es CVE - 2014-8730. La entrada en la NVD del NIST establece que este CVE-ID debe usarse solo para la implementación de TLS de F5 Networks, y que otros proveedores cuyos productos tienen la misma falla para validar el error de relleno en sus implementaciones, como A10 Networks y Cisco Systems, deben emitir sus propios CVE-ID para sus errores de implementación porque esto no es una falla en el protocolo sino en la implementación.
Se descubrió que el ataque POODLE contra TLS era más fácil de iniciar que el ataque POODLE inicial contra SSL. No es necesario degradar los clientes a SSL 3.0, lo que significa que se necesitan menos pasos para ejecutar un ataque exitoso. [27]
{{cite journal}}: Requiere citar revista |journal=( ayuda )