Caniche Es una raza de perro con patas que se parecen al algodón de azúcar. Es inteligente y un elemento básico habitual en las exposiciones caninas. Incluso los perros más amigables tienen propensión a morder. ¡Ahora vemos todo tipo de alertas de seguridad y problemas como el sangrado del corazón y el shock! La última incorporación es POODLE.
Todo esto comenzó cuando un equipo de Google desarrolló y probó un ataque llamado CANICHE (Padding Oracle On Downgraded Legacy Encryption) que descubrió una vulnerabilidad en el protocolo Secure Sockets Layer (SSL) versión 3 o, en resumen, SSLv3.
SSLv3 es un cifrado obsoleto pero que todavía se utiliza tanto en navegadores web nuevos como antiguos. (SSLv3 es un protocolo de 18 años que fue reemplazado por el protocolo TLS)
POODLE intenta forzar la conexión entre su navegador web y el servidor para bajar a SSLv3. El ataque POODLE aprovecha la función de negociación de la versión del protocolo integrada en SSL/TLS para forzar el uso de SSL 3.0 y luego utiliza esta nueva vulnerabilidad para descifrar contenido seleccionado dentro de la sesión SSL. El descifrado se realiza byte a byte y generará una gran cantidad de conexiones entre el cliente y el servidor.
¿Cómo lo hicieron?
Un atacante puede ejecutar un agente de JavaScript en un sitio web para hacer que el navegador de la víctima envíe una cookie con solicitudes HTTPS a https://xyz.com, intercepte y modifique los registros SSL enviados por el navegador de tal manera que exista una posibilidad no insignificante de que xyz.com acepte el registro modificado. Si se acepta el registro modificado, el atacante puede descifrar un byte de las cookies. Galletas
TLS 1.0 y versiones más recientes realizan una validación más sólida de los datos descifrados y, como tales, no son susceptibles al mismo problema. Pero para SSLv3 no hay solución.
¿Qué tan malo es esto y cómo te afecta?
Las conexiones seguras utilizan principalmente TLS (el sucesor de SSL), la mayoría de los usuarios se vuelven vulnerables porque los navegadores y servidores web bajarán a SSLv3 si hay problemas al negociar una sesión TLS. La mayoría de las implementaciones SSL/TLS siguen siendo compatibles con SSL 3.0 para interoperar con sistemas heredados en aras de una experiencia de usuario fluida. Un atacante que realice un ataque de intermediario podría provocar una degradación del protocolo a SSLv3 y aprovechar esta vulnerabilidad para descifrar un subconjunto de la comunicación cifrada y extraer información de ella. La vulnerabilidad POODLE solo funciona si el navegador del cliente y la conexión del servidor admiten SSLv3.
¿Cómo probar si mi navegador es vulnerable?
Vaya al sitio web poodletest.com para probar esto. Si ves un caniche, eres vulnerable. Si ves un Springfield Terrier, estás a salvo.
http://www.bolet.org/TestSSLServer/
http://code.google.com/p/sslaudit/
¿Qué puedo hacer para evitar esto? ¿Vacuna para caniches?
Como usuario final, deshabilite la compatibilidad con SSLv3 en su navegador web. Si está deshabilitado, POODLE NO puede degradar su navegador a él. Para fomentar las mejores prácticas de seguridad, recomiendo encarecidamente utilizar la versión más alta de TLS. Para la mayoría de los navegadores, debería ser TLS 1.2.
¿Esto afectará mi experiencia de navegación?
Esto tendrá un impacto en algunos navegadores más antiguos. Los sitios web que ya han dejado de admitir SSLv3 dejarán de ser compatibles con navegadores y sistemas operativos más antiguos. Los navegadores antiguos como Internet Explorer 6 que se ejecutan en Windows XP o versiones anteriores verán un error de conexión SSL.
SSL v3 estará deshabilitado de forma predeterminada en futuras versiones de muchos navegadores web.
¿Cómo desactivar esto en el servidor?
CloudFlare anunció que estaba deshabilitando SSLv3 de forma predeterminada en sus servidores. Lo mismo hicieron muchos proveedores de servicios.
Si está ejecutando Apache, simplemente realice este cambio en su configuración entre las otras directivas SSL:
Protocolo SSL Todos -SSLv2 -SSLv3
Esto deshabilita las versiones 2 y 3 del protocolo SSL.
¿Cómo pueden los desarrolladores evitar esto?
.NETO
Utilice la propiedad SecurityProtocol para habilitar TLS.
Para obtener detalles sobre cómo utilizar la propiedad SecurityProtocol, visite:
http://msdn.microsoft.com/en-us/library/system.net.servicepointmanager.securityprotocol(v=vs.110).as…
http://msdn.microsoft.com/en-us/library/system.net.securityprotocoltype(v=vs.110).aspx
Como ejemplo, para forzar TLS 1.2 en una implementación C# .NET, usaría:
System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12;
JAVA
NOTA: TLS 1.2 se admitió por primera vez en JDK 7 y será predeterminado en JDK 8: https://blogs.oracle.com/java-platform-group/entry/java_8_will_use_tls
Utilice el método SSLContext.getInstance para habilitar TLS.
Para obtener detalles sobre cómo utilizar el método SSLContext.getInstance, visite:
http://docs.oracle.com/javase/7/docs/api/javax/net/ssl/SSLContext.html#getInstance(java.lang.String)
http://docs.oracle.com/javase/7/docs/api/javax/net/ssl/SSLContext.html#getInstance(java.lang.String,…
http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#SSLContext
Por ejemplo, para usar el proveedor de capa de seguridad predeterminado para habilitar TLS, usaría:
objeto = SSLContext.getInstance(“TLS”);
Para forzar TLS 1.2 mientras usa Java Secure Socket Extension (JSSE) de Sun, usaría:
objeto = SSLConnect.getInstance(“TLSv1.2”, “SunJSEE”);
rizo
Utilice la opción CURLOPT_SSLVERSION para habilitar TLS.
Para obtener detalles sobre cómo utilizar la opción CURLOPT_SSLVERSION, visite:
http://curl.haxx.se/libcurl/c/CURLOPT_SSLVERSION.html
Como ejemplo, para forzar a cURL a usar TLS 1.0 o posterior, usarías:
C/C++/C#:
curl_easy_setopt(curl, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1);
PHP:
curl_setopt($curl_request, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1);
En cURL 7.34.0 o posterior, para forzar TLS 1.2, usarías:
C/C++/C#:
curl_easy_setopt(curl, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1_2);
PHP:
curl_setopt($curl_request, CURLOPT_SSLVERSION, CURL_SSLVERSION_TLSv1_2);
RielesCarma El equipo se preparó en modo de defensa total para tapar todos los agujeros que quedaron abiertos por esta vulnerabilidad. Aplicamos los parches necesarios a nuestras aplicaciones para desactivar las opciones SSL/TLS inseguras.
Referencias
http://arstechnica.com/security/2014/10/ssl-broken-again-in-poodle-attack/
https://www.imperialviolet.org/2014/10/14/poodle.html
http://blog.cryptographyengineering.com/2014/10/attack-of-week-poodle.html
https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/
http://www.theregister.co.uk/2014/10/16/poodle_analysis/
http://www.theregister.co.uk/2014/10/14/google_drops_ssl_30_poodle_vulnerability/
http://www.pcworld.com/article/2834015/security-experts-warn-of-poodle-attack-against-ssl-30.html
http://www.alertlogic.com/blog/poodle-man-middle-attack-sslv3/
https://www.us-cert.gov/ncas/alerts/TA14-290A
https://www.openssl.org/~bodo/ssl-poodle.pdf
http://www.makeuseof.com/tag/stop-poodle-from-biting-your-browser/
https://community.qualys.com/blogs/securitylabs/2014/10/15/ssl-3-is-dead-killed-by-the-poodle-attack
Deshabilitar caniche
https://www.linode.com/docs/security/security-patches/disabling-sslv3-for-poodle