• Tweet

Los investigadores dicen que han descubierto una falla en el protocolo Secure Sockets Layer (SSL), que permite a los atacantes inyectar texto en el tráfico cifrado que se transfiere entre dos extremos.

La vulnerabilidad en la capa de transporte del protocolo de seguridad, permite realizar el ataque de “hombre-en-el-medio” los atacantes pueden introducir texto en el inicio de una sesión SSL, dijo Ray Marsh, un investigador de seguridad que descubrió el error. Una transacción típica de SSL puede ser dividida en varias sesiones, proporcionando al atacante la amplia oportunidad de colocarse cuando las contraseñas son restablecidas y ejecutar otros comandos dentro de la comunicación que se cree esta autenticada estenográficamente.

Los ataques han sido efectivos tanto para servidores web Apache y Microsoft IIS los cuales tienen comunicaciones muy variadas con aplicaciones cliente. Un consorcio de algunas de las compañías de tecnología más grandes del mundo se ha reunido desde finales de septiembre para discutir a fondo un nuevo estándar que reparé esta falla. Se espera que este jueves sea presentado un esbozo en el “Internet Engineering Task Force”.

"Una garantía básica de seguridad hecha por TLS es violada como consecuencia de este problema", dijo Steve Dispensa, CTO de PhoneFactor, un proveedor de “two-facto”para la autenticación de servicios, la empresa donde trabaja Ray. "Va a tomar tiempo lanzar y aplicar los cambios necesarios para el protocolo , ya que cada navegador y servidor en todo el mundo tendra que poner un parche".

Dispensa y Ray, de manera rápida señalaron que la vulnerabilidad probablemente fuera más efectiva si se aprovechaba en común con algunos otros problemas de seguridad, por ejemplo un fallo en un router de casa o los fallos recientes de DNS descubiertos por el investigador Dan Kaminsky. Y aun así, un atacante no puede leer los datos cifrados que viajan de un servidor a un cliente.

De hecho, Moxie Moulinsart, un investigador de seguridad, quien ha denunciado reiteradamente graves deficiencias en SSL, dijo que los ataques son difíciles de realizar en el mundo real, en gran parte porque rara vez se utiliza una tecnología conocida para la autenticación del certificado del cliente.

"Es inteligente, pero que yo sepa, la mayoría de la gente usa SSL para webmail, banca en línea, etc. No tienen problemas", escribió en un correo electrónico. "No he encontrado que estos ataques sean muy útiles en la práctica."

Pero Ray y Dispensa dijeron que hay ataques que no dependen en absoluto de la autenticación de certificados clientes. Sostuvieron que la capacidad del atacante para inyectar texto plano en una secuencia de datos autenticados representa una amenaza importante. Y dijeron que el ataque tiene implicaciones especiales para tarjetas inteligentes y otras tecnologías que se basan en autenticación de certificados cliente.

" Existe un acuerdo general entre los proveedores más grandes en el mundo, en que esto es un problema grande", dijo Dispensa.

En este momento desarrolladores de GNU TLS OpenSSL han desarrollado parches y están en el proceso de prueba. Otros proveedores de hardware y software que implementan SSL s eencuentran también en diversas etapas de prueba para sus parches. Dispensa y Ray presentaron sus conclusiones en virtud de un acuerdo de no divulgación con gran número de representantes de la empresa, el 29 de septiembre en Mountain View, California, Se negaron a dar el nombre de esta empresa.

Las partes involucradas tenían previsto continuar trabajando en una solución en secreto durante el resto del año. Por casualidad un investigador independiente documentó recientemente los principios de la falla en el protocolo e hizo públicas algunas de las conclusiones, lo que llevó a Ray a divulgar sus investigaciones. La falla ha existido en TLS desde que la especificación se publicó a mediados de 1990.

La vulnerabilidad proviene de la capacidad de cualquiera de las partes involucradas en la transacción SSL de poder renegociar el período de sesiones, por lo general una u otra pueden actualizar sus claves criptográficas. Debido a que HTTP carece de la funcionalidad de dirigir al cliente para que presente la solicitud dentro de un nuevo canal autenticado, el servidor debe aplicar la autenticación con carácter retroactivo.

Por: Dan Goodin

TRaducción Alejandro Reyes