Se ha detectado una vulnerabilidad que afecta al protocolo criptográfico Secure Sockets Layer 3.0 (SSLv3) y que podría utilizarse para interceptar los datos transmitidos de un equipo a un servidor o viceversa, que en principio deberían estar cifrados. Tres investigadores de seguridad de Google dieron recientemente con el problema, al que denominaron Padding Oracle On Downgraded Legacy Encryption (POODLE) y asignaron el identificador CVE-2014-3566.
Es importante recalcar que se trata de una vulnerabilidad del protocolo SSLv3, no de un defecto de los certificados SSL, de su diseño ni de sus claves privadas. Los certificados no presentan problema alguno y, aunque se utilicen para proteger servidores compatibles con el protocolo SSL 3.0, no es necesario sustituirlos.
Según parece, la vulnerabilidad no es tan grave como Heartbleed (que afectaba a OpenSSL), ya que, para explotarla, el atacante debe tener un rol privilegiado en la red. No obstante, el riesgo de que se produzca un ataque de interposición «Man-in-the-Middle» aumenta si se utilizan puntos de acceso o redes Wi-Fi públicas.
Información adicional
Aunque SSL 3.0 es un protocolo criptográfico bastante antiguo (se introdujo en 1996), según el último informe de Netcraft, casi el 95 % de los navegadores web siguen permitiendo su uso. Al conectarse con servidores antiguos, muchos clientes que usan habitualmente el cifrado TLS (Transport Layer Security) pasan a utilizar automáticamente SSL 3.0, que resulta menos seguro. Según Google, un atacante que controle la red mediante la que se conectan el equipo y el servidor podría interferir con el handshake (el proceso que comprueba qué protocolo criptográfico admite el servidor) y hacer que la transmisión de datos se proteja con el protocolo SSL 3.0 en vez de usar otro más reciente. Un ataque de interposición «Man-in-the-Middle» realizado en estas condiciones permite descifrar las cookies HTTP seguras y, de este modo, robar datos o apropiarse de cuentas de servicios online. En el momento en el que se redactó esta entrada, muchos administradores de sitios web ya habían tomado medidas para que el servidor utilizara obligatoriamente el protocolo TLSv1 o versiones posteriores en lugar de SSL 3.0, pero no todo el mundo reacciona con la misma rapidez. Heartbleed ya demostró que las grandes empresas responden enseguida a problemas de este tipo, pero las de menor tamaño suelen tardar más en resolver las vulnerabilidades críticas.
Recomendaciones para las empresas
Para reducir los riesgos, recomendamos:
- usar la caja de herramientas de SSL, un recurso gratuito de Symantec, para comprobar si los servidores web de la empresa corren peligro;
- utilizar herramientas compatibles con el mecanismo TLS_FALLBACK_SCSV, que impide que los atacantes obliguen a los navegadores web a establecer una conexión mediante el protocolo SSL 3.0;
- desactivar el uso de conexiones SSL 3.0 o el cifrado en modo CBC con SSL 3.0;
- usar un firewall para aplicaciones web basado en la nube para extremar las precauciones (más información en nuestro sitio web);
- desconfiar de los mensajes sospechosos, ya que habrá quien pretenda aprovecharse de la incertidumbre y de la falta de conocimientos técnicos de algunas personas.
Mi compañero Christoffer Olausson aconseja lo siguiente para resolver el problema en Apache:
> SSLProtocol All -SSLv2 -SSLv3 <- Elimina SSLv2 y SSLv3
> apachectl configtest <- Prueba la configuración
> sudo service apache restart <- Reinicia el servidor
Google ya ha anunciado que, en cuestión de unos meses, sus productos dejarán de ser compatibles con el protocolo SSL 3.0, y Mozilla también ha anunciado que Firefox 34 (que saldrá a finales de noviembre) tampoco admitirá su uso.
Recomendaciones para los internautas
En el caso de los internautas, Symantec recomienda:
- comprobar si el navegador que usan permite el uso del protocolo SSL 3.0 (por ejemplo, en Internet Explorer se puede comprobar yendo a Opciones de Internet > Opciones avanzadas);
- asegurarse de que la URL de los sitios web que visitan empiece siempre por «https», lo que reduce el riesgo de ataques «Man-in-the-Middle»;
- estar pendiente de los avisos que reciban de sus proveedores de servicios y cambiar las contraseñas o actualizar el software si es necesario;
- comprobar la procedencia de los mensajes de correo electrónico en los que se solicita un cambio de contraseña y asegurarse de que los enlaces conducen al sitio web oficial, ya que podría tratarse de intentos de phishing.
Más información
Symantec ya ha publicado varios artículos relacionados con este tema en la base de conocimientos.
Artículo para usuarios de Symantec Managed PKI for SSL
https://knowledge.verisign.com/support/mpki-for-ssl-support/index?page=content&id=AR2182
Artículo para usuarios de Symantec Trust Center/Trust Center Enterprise
https://knowledge.verisign.com/support/ssl-certificates-support/index?page=content&id=AR2183
Manténgase al tanto de las novedades
¿Quiere que le informemos de todo lo relacionado con esta u otras vulnerabilidades? Síganos en Twitter o Facebook. Si tiene algún problema para gestionar sus certificados SSL o Code Signing, le invitamos a pasarse por nuestros foros técnicos.