Vulnerabilidad en SSL y TLS
Sin lugar a duda, una de las conferencias más espectantes durante la Ekoparty de este año ha sido la de Thai Duong y Juliano Rizzo titulada "BEAST: Surprising crypto attack against HTTPS". El interés de dicha conferencia es evidente, un elevado número sitios Web y aplicaciones que utilizan SSL y que implementan CBC como principal cifrado de bloques son susceptibles de ser vulnerados. El problema radica en la forma en la que CBC es implementado en las versiones previas a TLS 1.1.
El modo de operación CBC (Cipher Block Chaining) fue desarrollado por IBM en 1976. El modelo presentaba ciertas ventajas adicionales frente a ciertos modos de cifrado existentes en el momento como el ECB (Electronic Codebook) donde cada mensaje era dividido en bloques y cada uno de estos bloques era cifrado de forma independiente. El problema de esta implementación era la aparicion de bloques cifrados (ciphertext) idénticos en el caso de que el bloque en texto plano fuera el mismo, es decir, dos bloques de texto plano idénticos generaban el mismo bloque cifrado, vulnerando totalmente la confidencial del mensaje. A diferencia de este método, en el módo de operacion CBC a cada bloque de texto plano (plaintext) se le aplica una función XOR con el ciphertext anterior antes de ser cifrado consiguiendo de esta forma que cada ciphertext sea dependiente de todos los bloques plaintext generados hasta ese punto. Además para hacer cada mensaje único se emplea un vector de inicialización (IV) en el primer bloque.
La vulnerabilidad radica en al forma en la que dicho IV es generado. En las versiones previas a TLS 1.1 en lugar de utilizar un IV aleatorio para cada mensaje TLS, se usa el ciphertext del último bloque del último mensaje como IV para el siguiente mensaje. Este en el principio empleado para desarrollar un ataque contra HTTPS mediante el cual es posible obtener la cookie de autenticación de una sesión SSL pudiendo así interceptar sesiones de servicios como los de PayPal.
Durante una comunicación HTTPS todo el mensaje HTTP es cifrado, incluidas por tanto las cabeceras y el cuerpo de las mismas. SSL recibe el mensaje HTTP "en bruto" de la capa aplicación y posteriormente es fragmentado en bloques de longitud menor o igual a 2^14 bytes. Los bloques cifrados (ciphertext) resultantes son enviados al servidor.
El exploit desarrollado por Thai Duong y Juliano Rizzo permite ir deduciendo byte a byte las cabeceras enviadas en cada petición tras un número N de solicitudes POST. La forma de llevar a cabo el ataque es mediante código Javascript encargado de inyectar segmentos de texto plano en el stream cifrado enviado por el navegador. Gracias al conocimiento de antemano de patrones comunes en las solicitudes POST y a la deficiente implementación de CBC (IVs iniciales no aleatorios) es posible llevar a cabo este ataque denominado "blockwise chosen-boundary attack".
Para una descripción más detallada de todo el proceso puede consultar el paper técnico presentado en la Ekoparty.
La vulnerabilidad (CVE-2011-3389) por tanto permite obtener la cookie de autenticación incluso si HTTPS está en uso y secure flag está activado.
Especialistas en seguridad han sugerido el uso de RC4 (también conocido como ARC4 o ARCFOUR) para mitigar de forma temporal la vulnerabilidad descubirta por Thai Duong y Juliano. En el caso de los navegadores se recomienda forzar el uso de TLS 1.1 o 1.2. En Internet Explorer puede descargase e instalarse el Fix-It recientemente publicado por Microsoft.
Desarrolladores de Chrome y Firefox están actualmente trabajando para incluir en la versión estable de su navegador una solución que mitigue el problema de seguridad.
Fuente
