CANICHE

POODLE (que significa " Padding Oracle On Downgraded Legacy Encryption ") es una vulnerabilidad de seguridad que aprovecha el mecanismo de reserva 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; la divulgaron públicamente el 14 de octubre de 2014 (a pesar de que el documento está fechado en "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 identificador CVE asociado al ataque POODLE original es CVE - 2014-3566 . F5 Networks también presentó una solicitud para CVE - 2014-8730 ; consulte la sección sobre el ataque POODLE contra TLS a continuación.

Para mitigar el ataque POODLE, una estrategia consiste en deshabilitar completamente SSL 3.0 tanto en el cliente como en el servidor. Sin embargo, algunos clientes y servidores antiguos no son compatibles con TLS 1.0 ni versiones posteriores. Por lo tanto, los autores del artículo sobre ataques POODLE también recomiendan la implementación de TLS_FALLBACK_SCSV en navegadores y servidores, ^{[ 6 ]} lo que imposibilitará los ataques de degradación. ^{[ 1 ] [ 7 ]}

Otra medida de mitigación consiste en implementar la "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 esta división es que, si bien 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 ]}

En el artículo "Seguridad de la capa de transporte" se puede encontrar una lista completa de las versiones de navegadores y los niveles de vulnerabilidad a diferentes ataques (incluido POODLE) .

Opera 25 implementó esta mitigación además de TLS_FALLBACK_SCSV. ^{[ 9 ]}

El navegador Chrome de Google y sus servidores ya eran compatibles con TLS_FALLBACK_SCSV. Google declaró en octubre de 2014 que planeaba eliminar por completo la compatibilidad con SSL 3.0 de sus productos en pocos meses. ^{[ 7 ]} La función de reserva a SSL 3.0 se ha deshabilitado en Chrome 39, lanzado en noviembre de 2014. ^{[ 10 ]} SSL 3.0 se ha deshabilitado por defecto 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 corrección que deshabilita SSL 3.0 en Internet Explorer en Windows Vista / Server 2003 y versiones posteriores y anunció un plan para deshabilitar SSL 3.0 de forma predeterminada en sus productos y servicios en unos meses. ^{[ 14 ]} Microsoft deshabilitó la opción de respaldo a SSL 3.0 en Internet Explorer 11 para sitios en modo protegido 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ó contra POODLE eliminando la compatibilidad con todos los protocolos CBC en SSL 3.0, ^{[ 17 ] [ 18 ]} sin embargo, esto dejó RC4, que también es completamente vulnerable a los ataques RC4 en SSL 3.0. POODLE fue mitigado por completo en OS X 10.11 (El Capitan 2015) e iOS 9 (2015).

Para prevenir el ataque POODLE, algunos servicios web dejaron de ser compatibles con SSL 3.0. Algunos ejemplos son CloudFlare ^{[ 19 ]} y Wikimedia . ^{[ 20 ]}

Las versiones 3.17.1 (lanzada el 3 de octubre de 2014) y 3.16.2.3 (lanzada el 27 de octubre de 2014) de Network Security Services introdujeron soporte para TLS_FALLBACK_SCSV, ^{[ 21 ] [ 22 ]} y NSS deshabilitará SSL 3.0 de forma predeterminada en abril de 2015. ^{[ 23 ]}Las versiones 1.0.1j, 1.0.0o y 0.9.8zc de OpenSSL , publicadas el 15 de octubre de 2014, introdujeron soporte para TLS_FALLBACK_SCSV. ^{[ 24 ]} La versión 2.1.1 de LibreSSL , publicada el 16 de octubre de 2014, deshabilitó SSL 3.0 por defecto. ^{[ 25 ]}

El 8 de diciembre de 2014 se anunció una nueva variante del ataque POODLE original. Este ataque explota 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 verifiquen el relleno, algunas implementaciones no lo validan correctamente, lo que hace que algunos servidores sean vulnerables a POODLE incluso si deshabilitan 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 el NVD del NIST indica que este CVE-ID debe usarse solo para la implementación de TLS de F5 Networks, y que otros proveedores cuyos productos presenten el mismo fallo de validación del error de relleno en sus implementaciones, como A10 Networks y Cisco Systems, deben emitir sus propios CVE-ID para sus errores de implementación, ya que esto no es un fallo 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 ]}

• Este POODLE muerde: Explotando el respaldo SSL 3.0 - La publicación original de POODLE
• 1076983 – (POODLE) Ataque de oráculo de relleno en SSL 3.0 Mozilla Bugzilla
• ¿Qué es el ataque POODLE? - Artículo de Acunetix que explica el algoritmo del ataque POODLE.