La vulnerabilidad en SSL/TLS en detalle
Hace unos días corrió como la pólvora el descubrimiento y posterior demostración, por parte de los investigadores Thai Duong y Juliano Rizzo, de una vulnerabilidad en los protocolos de seguridad TLS 1.0 y SSL 3.0, lo cual permitiría descifrar las peticiones de clientes realizadas a sitios como PayPal. Se trata del primer ataque realizado al protocolo TLS que termina con éxito y básicamente se traduce en que millones de páginas que realizan transacciones bancarias y de pagos, estarán vulnerables de ahora en adelante.
Sin embargo, aunque en la Red se puede encontrar fácilmente esta descripción, la verdad es que pocos se centran en lo importante: ¿qué se debería hacer ahora mismo para paliar esta vulnerabilidad?
Especialistas en seguridad han sugerido el uso RC4 para evitar la vulnerabilidad en SSL/TLS. A diferencia de AES, que se utiliza en la mayoría de los servidores, el algoritmo de cifrado de flujo no utiliza el cifrado de bloque de encadenamiento (CBC). Las implementaciones de CBC en todas las versiones hasta SSL 3.0/TLS 1.0 son vulnerables a los ataques.
En el corazón del problema están los vectores de inicialización (IVs) que no son asignados al azar para cada bloque (los vectores se supone que aseguran que los bloques idénticos no generan la misma cifra). Esto permite que las cookies que se transmite de forma cifrada se puedan descubrir mucho más rápido con "conjeturas" que con la fuerza bruta. Para tener éxito, sin embargo, se debe utilizar un Man-in-the-middle (MITM) para interceptar la conexión de la víctima servidor y comunicarse con el servidor en el contexto de la víctima.
Un analista de seguridad de Google llamado Adam Langley, ha publicado más detalles sobre este enfoque. Según Langley, algunos códigos JavaScript que sigue siendo el tema de la especulación la semana pasada se inyectan en el navegador de la víctima a través de un iFrame en el ataque MITM. La secuencia de comandos envía al servidor miles de peticiones SSL especialmente diseñadas y evalúa las respuestas. Lo que los investigadores de seguridad Thai Duong y Rizzo Juliano presentaron fue BEAST (Browser Exploit Against SSL/TLS, Exploit de Navegador Contra SSL/TLS), herramienta para automatizar este ataque.
El problema puede ser resuelto por el cambio a la versión de TLS 1.1, que fue adoptada en 2006: en ella, los vectores de inicialización de CBC son aleatorios, lo que hace que el ataque descrito resulte ineficaz. Sin embargo, el cambio es potencialmente problemático porque no todos los servidores y navegadores son compatibles con el estándar.
Según el análisis por el especialista en seguridad Zoller Thierry, Chrome y Firefox utilizar los servicios de seguridad de red (NSS), que sólo admiten TLS 1.0. Windows Vista, XP, 2000 y 2003 Server, así como 2008 Server también son incapaces de utilizar TLS 1.1 de forma predeterminada. Sólo Windows 7 y 2008 Server R2 puede utilizar TLS 1.1. Opera 10, por el contrario, funciona incluso con TLS 1.2. Sin embargo, no sirve de nada cambiar la configuración del navegador, si el servidor no es compatible con la norma.
OpenSSL, que tiende a ser utilizado con servidores web Apache, todavía no ofrece TLS 1.1: en este caso, la única medida eficaz es cambiar a GnuTLS o RC4. Las suites de cifrado que se utiliza se puede definir en el fichero de configuración ssl.conf de OpenSSL. Las instrucciones sobre cómo modificar un servidor Microsoft IIS 7 se puede encontrar en el PDF <a href="http://www.phonefactor.com/resources/CipherSuiteMitigationForBeast.pdf">Cipher Suite Mitigation for BEAST</a>.
Mientras tanto, Google ha implementado una solución en la versión para desarrolladores de Chrome que había sido propuesto por los desarrolladores de OpenSSL en 2004. Para que sea más difícil para los atacantes controlar el texto que se inyecta, los paquetes se separan, y se añade uno vacío antes de cada paquete. La adición de paquetes vacíos como medida de protección fue implementada en OpenSSL hace algún tiempo. Sin embargo, Zoller dijo que la medida no está activada por defecto por razones de compatibilidad.
Hasta ahora, la mayoría de los desarrolladores y operadores de servidores web no han sido demasiado reactivos, una razón para esto podría ser que la herramienta BEAST no se ha hecho pública... todavía.
| Comentarios |
|












