POODLE ( Padding Oracle On Downgraded Legacy Encryption ) es un tipo de ataque a la seguridad informática como “ man in the middle ”, cuando un atacante, al bloquear TLS 1.0 y aumentar el número de intentos de conexión, hace que los clientes y usuarios de Internet utilicen SSL software de seguridad de la versión 3.0 a la fuerza [1] . Una vez que el sistema se ha revertido a SSL 3.0, el atacante utiliza el ataque Padding Oracle .
Este tipo de vulnerabilidad fue descubierta por los miembros del equipo de seguridad de Google , Bodo Möller, Tai Duong y Krzysztof Kotowicz [1] . Anunciaron públicamente el descubrimiento de la vulnerabilidad el 14 de octubre de 2014 [2] , a pesar de que el artículo correspondiente está fechado algo antes, septiembre de 2014. El 8 de diciembre del mismo año se anuncia una versión de la vulnerabilidad tipo POODLE, que también afecta al tráfico TLS [3] . La vulnerabilidad POODLE original se agregó a la base de datos de Vulnerabilidades de seguridad de la información comúnmente conocidas ( CVE ) con el identificador CVE -2014-3566 [4] . F5 Networks también ha solicitado que se agregue a la base de datos una versión del ataque POODLE contra TLS , a la que se le ha asignado el identificador CVE -2014-8730 [5] .
Debido a que este ataque explota las vulnerabilidades del protocolo SSL 3.0 y no existe una solución razonable al problema de estas vulnerabilidades, para garantizar una conexión segura, se hizo necesario abandonar por completo el uso de este protocolo [1 ] . En octubre de 2014, Google anunció su intención de dejar de admitir por completo el protocolo SSL 3.0 en sus productos en los próximos meses [6] . La capacidad de recurrir a SSL 3.0 se deshabilitó en Chrome 39, lanzado en noviembre de 2014 [7] . La compatibilidad con el protocolo SSL 3.0 quedó obsoleta de forma predeterminada en Chrome 40, lanzado en enero de 2015 [8] . El 29 de octubre de 2014, Microsoft lanzó una revisión que deshabilitó la compatibilidad con SSL 3.0 en Internet Explorer y Windows Vista / Server 2003 y versiones posteriores. El mismo día, Microsoft anunció que planea deshabilitar el soporte SSL 3.0 por defecto en sus productos y servicios dentro de unos meses [9] . El 10 de febrero de 2015, Microsoft deshabilitó la capacidad de recurrir a SSL 3.0 en los navegadores Internet Explorer 11 para sitios en modo seguro [10] . Para otros sitios, esto se hizo el 14 de abril de 2015 [11] .
POODLE es un ejemplo de una vulnerabilidad que puede explotarse con éxito mediante un mecanismo diseñado para reducir intencionalmente la seguridad de un enlace por motivos de compatibilidad. Para trabajar con servidores heredados, muchos clientes TLS utilizan el llamado "baile de degradación", que es el siguiente: en el primer intento de establecer comunicación a través del protocolo TLS , el cliente solicita al servidor que utilice la última versión de TLS compatible . por el cliente Si este intento falla, el cliente intenta establecer una conexión utilizando una versión anterior del protocolo TLS hasta que se establezca la conexión. Esta degradación intencional de la seguridad por parte del cliente puede deberse a interrupciones de la red y ataques malintencionados. Por lo tanto, si un atacante que controla la sección de red entre el servidor y el cliente interfiere con el proceso de protocolo de enlace TLS y descarta todos los mensajes del cliente con una oferta para establecer una conexión segura utilizando el protocolo TLS versión 1.0 y superior, los clientes que admitan la "degradación dance" estarán dispuestos a limitarse a un protocolo SSL 3.0 . Como resultado, se utilizan conjuntos de cifrado SSL inseguros para ocultar datos, utilizando el cifrado de flujo RC4 o el modo de cifrado CBC , susceptible al ataque Padding Oracle . En el caso de una explotación exitosa de esta vulnerabilidad , un atacante solo necesitaría realizar un promedio de 256 solicitudes SSL 3.0 para descifrar con éxito 1 byte de mensajes cifrados [1] [12] [13] .
Es necesario tener más cuidado al diseñar sistemas ubicados en dominios altamente fragmentados, ya que estos dominios pueden tener un mecanismo generalizado para degradar la seguridad del enlace por parte de los atacantes . Una forma que permite a un atacante reducir la protección del canal es emular interrupciones de comunicación cuando se utiliza el protocolo TLS [14] .
Un enfoque para prevenir los ataques de POODLE es deshabilitar completamente el soporte para el protocolo SSL 3.0 tanto en el lado del cliente como en el lado del servidor . Sin embargo, es posible que algunos clientes y servidores heredados no admitan la versión 1.0 o superior de TLS . En tales casos, los autores del artículo sobre los ataques POODLE recomiendan que el navegador y el servidor admitan el mecanismo TLS_FALLBACK_SCSV [15] , que evita que los atacantes aprovechen la vulnerabilidad [1] .
Otro enfoque para protegerse contra la vulnerabilidad es la implementación del mecanismo de "división de registros Anti-POODLE": la división de datos en varias partes, cada una de las cuales está garantizada para no ser atacada con esta vulnerabilidad . Sin embargo, el problema con el enfoque de intercambio de datos es que, a pesar de la implementación exacta del mecanismo de acuerdo con la especificación, este enfoque no evita problemas de compatibilidad debido a deficiencias en el lado del servidor del mecanismo [16] .
Por ejemplo, en el navegador Opera 25 , este mecanismo se implementa además del mecanismo "TLS_FALLBACK_SCSV" [17] . Las diferentes versiones de los navegadores Google Chrome y los servidores relacionados también brindaron soporte para el mecanismo "TLS_FALLBACK_SCSV". Mozilla deshabilitó la compatibilidad con SSL 3.0 en sus navegadores Firefox 34 y ESR 31.3 lanzados en diciembre de 2014 y admitió el mecanismo "TLS_FALLBACK_SCSV" en Firefox 35 [18] .
Microsoft ha publicado un aviso de seguridad que explica cómo deshabilitar SSL 3.0 en Internet Explorer y Windows OS [19] .
El navegador Safari de Apple (para OS X 10.8, iOS 8.1 y posteriores) contrarrestó los ataques de POODLE al desaprobar todos los protocolos CBC en SSL 3.0 , pero este enfoque aún brindó soporte para RC4 , que también es susceptible a ataques RC4 en el protocolo SSL 3.0 [20 ] . La vulnerabilidad del ataque POODLE se cerró por completo en OS X 10.11 (El Capitan 2015) e iOS 9 (2015). Para evitar ataques de POODLE, algunos servicios (como CloudFlare y Wikimedia, por ejemplo) se han deshabilitado para SSL 3.0 [21] .
El conjunto de bibliotecas de Network Security Services versión 3.17.1 y 3.16.2.3 brindó soporte para el mecanismo "TLS_FALLBACK_SCSV" [22] [23] , posteriormente el soporte para el protocolo SSL 3.0 se desactivó de forma predeterminada [24] . Las bibliotecas OpenSSL versiones 1.0.1j, 1.0.0o y 0.9.8zc brindan soporte para el mecanismo "TLS_FALLBACK_SCSV" [25] . En LibreSSL versión 2.1.1, la compatibilidad con SSL 3.0 está desactivada de forma predeterminada [26] .
El 8 de diciembre de 2014 se anunció una nueva variación del clásico ataque CANICHE [3] . Este tipo de ataque aprovecha las deficiencias en la implementación del modo de cifrado CBC en los protocolos TLS 1.0 - 1.2. Aunque las especificaciones de TLS requieren que los servidores verifiquen el llamado "padding" (un conjunto de bits adicionales que se agregan a una clave , contraseña o texto sin formato mediante cifrado para ocultar su verdadero valor), algunas implementaciones de este protocolo no dan abasto. con su correcta validación, lo que deja a algunos servidores vulnerables a los ataques de POODLE incluso si SSL 3.0 está deshabilitado. Este tipo de ataque POODLE se reconoce como más peligroso que el clásico debido al hecho de que, al atacar, los atacantes no necesitan provocar artificialmente que la protección del canal vuelva a SSL 3.0, lo que significa que se necesitan menos operaciones para completar un ataque exitoso. . El proyecto SSL Pulse descubrió que "alrededor del 10 % de todos los servidores se ven afectados por ataques de modificación de TLS POODLE" antes de que se anunciara esta vulnerabilidad [27] . A este error se le asignó CVE-ID CVE-2014-8730 en la implementación de TLS de F5 Networks. La información de la base de datos nacional de vulnerabilidades del NIST muestra que este CVE-ID se asigna a implementaciones de TLS erróneas realizadas solo por F5 Networks. Otros proveedores que tienen el mismo error de implementación de "relleno" (como A10 y Cisco Systems ) deberían emitir sus propios CVE-ID , según la base de datos nacional de vulnerabilidades , ya que sus versiones de TLS no funcionan correctamente debido a una falla en el protocolo. pero una implementación errónea de este protocolo [5] .