10 jun 2021

ALPACA: ataque de confusión de protocolo sobre TLS

Un grupo de académicos de la Universidad de Ruhr en Bochum, la Universidad de Ciencias Aplicadas de Münster y la Universidad de Paderborn han revelado un nuevo tipo de ataque, que aprovecha las configuraciones incorrectas de seguridad de la capa de transporte (TLS) en los servidores, para redirigir el tráfico HTTPS desde el navegador de la víctima a un punto final diferente, en otra dirección IP, y permite robar información confidencial.

Los ataques han sido denominados ALPACA, abreviatura de "Application Layer Protocol Confusion - Analyzing and mitigating Cracks in TLS Authentication"

"Los atacantes pueden redirigir el tráfico de un subdominio a otro, lo que resulta en una sesión TLS válida", dice el estudio. "Esto rompe la autenticación de TLS y los ataques entre protocolos pueden ser posibles cuando el comportamiento de un servicio de protocolo puede comprometer al otro en la capa de aplicación".

TLS es un protocolo criptográfico que sustenta varios protocolos de capa de aplicación como HTTPS, SMTP, IMAP, POP3 y FTP para asegurar las comunicaciones a través de una red con el objetivo de agregar una capa de autenticación y preservar la integridad de los datos intercambiados mientras están en tránsito.

Los ataques ALPACA son posibles porque TLS no vincula una conexión TCP al protocolo de capa de aplicación previsto, explicaron los investigadores. Por lo tanto, se podría abusar de la falla de TLS para proteger la integridad de la conexión TCP para "redirigir el tráfico TLS para el punto final y protocolo del servicio TLS previsto a otro punto final sustituto".

Dado un cliente (es decir, un navegador web) y dos servidores de aplicaciones (es decir, el previsto y el sustituto), el objetivo es engañar al servidor sustituto para que acepte datos de la aplicación del cliente, o viceversa. Dado que el cliente utiliza un protocolo específico para abrir un canal seguro con el servidor previsto (por ejemplo, HTTPS) mientras que el servidor sustituto emplea un protocolo de capa de aplicación diferente (por ejemplo, FTP) y se ejecuta en un punto final TCP separado, la confusión culmina en lo que se llama un ataque de protocolo cruzado (Cross-Protocol attack).

Se han descubierto al menos tres escenarios hipotéticos de ataques entre protocolos, que un adversario puede aprovechar para eludir las protecciones TLS y apuntar a servidores FTP y de correo electrónico. Sin embargo, los ataques dependen del requisito previo de que el atacante pueda interceptar y desviar el tráfico de la víctima en la capa TCP/IP.

En pocas palabras, los ataques toman la forma de un esquema de intermediario (MitM) en el que el actor malintencionado atrae a una víctima para que abra un sitio web bajo su control para activar una solicitud HTTPS de origen cruzado con una carga útil FTP especialmente diseñada. Luego, esta solicitud se redirige a un servidor FTP que utiliza un certificado que es compatible con el del sitio web, lo que culmina en una sesión TLS válida.

En consecuencia, la configuración incorrecta en los servicios TLS puede explotarse para filtrar las cookies de autenticación u otros datos privados al servidor FTP (ataque de carga), recuperar una carga útil JavaScript maliciosa del servidor FTP en un ataque XSS almacenado (ataque de descarga) o incluso ejecutar un reflejó XSS en el contexto del sitio web de la víctima (Reflection Attack).

Se espera que todos los servidores TLS que tienen certificados compatibles con otros servicios TLS se vean afectados. En una configuración experimental, los investigadores encontraron que al menos 1.4 millones de servidores web eran vulnerables a ataques de protocolos cruzados, y 114.197 de los servidores se consideraban propensos a los ataques utilizando un servidor SMTP, IMAP, POP3 o FTP explotable con un certificado confiable y compatible.

Para contrarrestar los ataques entre protocolos, los investigadores proponen utilizar extensiones de negociación de Application Layer Protocol Negotiation (ALPN) y Server Name Indication (SNI) para TLS. Los mismo se pueden utilizar al momento del Handshake para informar de forma segura al servidor sobre el protocolo previsto que se desea utilizar y el nombre de host al que se está intentando conectar.

Muchos proveedores han actualizado sus servidores de aplicaciones para eliminar vectores de explotación o agregar contramedidas en la capa de aplicación y/o implementación de TLS. Los encargados de mantenimiento de la biblioteca TLS han revisado las implementaciones de ALPN y SNI y han actualizado su código y documentación para permitir una fácil implementación de contramedidas por parte de los desarrolladores. Para evitar los ataques en el modelo de atacante de navegador puro, los proveedores de navegadores han bloqueado más puertos de aplicaciones estándar y han desactivado el rastreo de contenido en más escenarios.

Las respuestas específicas se enumeran a continuación:

  • Microsoft Internet Explorer bloqueó más puertos de servidor que no eran HTTP y deshabilitó el rastreo de contenido para solicitudes HTTP a puertos no estándar (CVE-2021-31971).
  • Sendmail corrigió un error para detectar solicitudes HTTP cuando se usa STARTTLS y, desde Sendmail 8.17, existen contramedidas adicionales en la capa de aplicación para bloquear las solicitudes HTTP.
  • Courier 5.1.0 implementó soporte para ALPN.
  • FileZilla implementó contramedidas en la aplicación y la capa TLS.
  • Vsftpd 3.0.4 implementó contramedidas en la aplicación y la capa TLS.
  • Nginx 1.21.0 implementó mitigaciones en la capa de aplicación en el proxy de correo.
  • Crypto / TLS (Go) ahora impone la superposición de ALPN cuando se negocia en ambos lados.

Se espera que los hallazgos se presenten en Black Hat USA 2021 y USENIX Security Symposium 2021. Se puede acceder a artefactos adicionales relevantes para el ataque ALPACA a través de GitHub.

Fuente: THN

Suscríbete a nuestro Boletín

2 comentarios:

  1. "aprovecha las configuraciones incorrectas en los servidores de seguridad de la capa de transporte (TLS)" es difícil de leer; debe ser "aprovecha las configuraciones incorrectas de 'seguridad de la capa de transporte' (TLS) en los servidores"

    ResponderBorrar

Gracias por dejar un comentario en Segu-Info.

Gracias por comentar!