Un grupo de investigadores suizo demuestra la existencia de una
vulnerabilidad de revelado de información en SSL/TLS, que puede permitir a
un atacante identificar la clave utilizada para el cifrado de una sesión.
SSL (Secure Sockets Layer, capa de conexión segura) y TLS (Transport Layer
Security, capa de seguridad del transporte) son dos métodos utilizados
para ofrecer cifrado y integridad de datos en las comunicaciones entre dos
entes a través de una red informática.
SSL fue inicialmente desarrollado e implementado por Netscape en 1994 para
ofrecer a los usuarios la garantía que la información sensible transmitida
a través de Internet permanecía totalmente privada e íntegra, incluso
cuando un atacante disponía de la opción de capturar la sesión (tráfico
entre el cliente y el servidor). El protocolo TLS es una propuesta de
estándar, recogida en el RFC 2246, que nace como una evolución de SSL 3.0.
Aunque tradicionalmente el uso más frecuente de SSL/TLS es para el cifrado
de las páginas web, en realidad estos protocolos de transporte son
totalmente independientes del protocolo de aplicación. Es decir, se puede
utilizar SSL/TLS para el cifrado de protocolos de aplicación como Telnet,
FTP, SMTP, IMAP o el propio HTTP.
SSL/TLS no ofrecen únicamente la capacidad de cifrar la información, sino
que también permiten a cada una de las partes identificarse de forma
fehaciente, lo que evita posibles ataques de suplantación o de
interceptación de sesiones («man-in-the-middle»).
Para el cifrado del tráfico, SSL/TLS utilizan algoritmos de clave
simétrica (como DES, AES…) o bien clave variable (RC4, por ejemplo)
mientras que para la autenticación de los participantes se utilizan
certificados digitales (tecnología de clave pública y privada).
La vulnerabilidad descubierta permite a un atacante, que disponga de la
capacidad de monitorizar y manipular múltiples sesiones SSL/TLS donde se
utilice una clave fija para el cifrado de la sesión, como puede ser una
contraseña, utilizar un vector de ataque específico que le permita la
identificación de esa clave de cifrado.
De una forma muy resumida, la operación de cifrado de SSL/TLS conlleva
calcular un código de autenticación que se añade al texto a cifrar. Este
texto más código es dividido en bloques del tamaño de entrada del
algoritmo de cifrado (normalmente, 8 bytes), rellenando los posibles bits
libres. Una vez obtenidos estos bloques, se les aplica el algoritmo de
cifrado.
El receptor de los bloques cifrados debe proceder a separar las diversas
partes (texto, código de autenticación, bits de relleno y longitud del
bloque) y realizar la verificación del relleno. Si la verificación es
exitosa, se procede a verificar el código de autenticación.
Esto puede ser aprovechado por un atacante, que disponga de la capacidad
de interceptar y manipular el tráfico de las sesiones, para determinar
cual es la contraseña utilizada para el cifrado. Midiendo el tiempo de
respuesta se puede identificar cual es el error identificado: en la
verificación del relleno o en la verificación del código de autenticación.
El ataque consiste básicamente en estos pasos:
1. El atacante intercepta el bloque que desea descifrar (la contraseña)
que envía uno de los participantes de la sesión.
2. El atacante envía al otro participante un bloque construido por él a
partir del bloque interceptado.
3. El servidor remitirá un mensaje de error al atacante. Este mensaje
indicará que tipo de error se ha producido, si durante la verificación de
los bits de relleno o durante la verificación del código de autenticación.
Este tipo de ataque requiere que el mensaje utilizado para el cifrado sea
el mismo durante un gran número de sesiones. En el ejemplo práctico
utilizado por los investigadores suizos, se ha utilizado un cliente de
correo, que periódicamente consulta al servidor de correo la posible
existencia de nuevos mensajes.
OpenSSL, un desarrollo de código abierto que implementa los protocolos
SSL/TLS, ha publicado una nueva versión que impide la realización de este
tipo de ataque, ya que siempre se realiza la verificación del código de
autenticación incluso cuando la primera verificación es errónea. De esta
forma, el atacante no recibe la suficiente información para discernir el
tipo de error detectado.
xavi@hispasec.com
Deja una respuesta