Un grupo de investigadores de varias universidades de Alemania, los cuales ha desarrollado un nuevo método de ataque MITM contra HTTPS, que permite extraer cookies con ID de sesión y otros datos sensibles, así como ejecutar código JavaScript arbitrario en el contexto de otro sitio. El ataque se llama ALPACA y se puede aplicar a servidores TLS que implementan diferentes protocolos de capa de aplicación (HTTPS, SFTP, SMTP, IMAP, POP3), pero usan certificados TLS comunes. El ataque permitiría redirigir el tráfico del navegador a un servicio diferente con el fin de acceder o exfiltrar información sensible.

Ataque a TLS por confusión de protocolos

Dado que el protocolo TLS es universal y no está vinculado a los protocolos de nivel de aplicación, el establecimiento de una conexión encriptada para todos los servicios es idéntico y un error al enviar una solicitud al servicio incorrecto se puede detectar solo después del establecimiento de una sesión encriptada durante el procesamiento. de los comandos de la solicitud enviada.

En consecuencia, si, por ejemplo, redirige la conexión de un usuario, inicialmente dirigida a HTTPS, a un servidor de correo que utiliza un certificado común con el servidor HTTPS, la conexión TLS se establecerá correctamente, pero el servidor de correo no podrá procesar los comandos HTTP transmitidos y devolverá una respuesta con un código de error. Esta respuesta será procesada por el navegador como una respuesta del sitio solicitado, transmitida dentro de un canal de comunicación cifrado correctamente establecido.

Se proponen tres opciones de ataque:

1. «Upload» para recuperar la Cookie con parámetros de autenticación: El método es aplicable si el servidor FTP cubierto por el certificado TLS le permite descargar y recuperar sus datos. En esta variante del ataque, un atacante puede lograr la preservación de partes de la solicitud HTTP original del usuario, como el contenido del encabezado de la Cookie, por ejemplo, si el servidor FTP interpreta la solicitud como un archivo a guardar o lo registra por completo. solicitudes entrantes. Para un ataque exitoso, un atacante necesita recuperar de alguna manera el contenido almacenado. El ataque es aplicable a Proftpd, Microsoft IIS, vsftpd, filezilla y serv-u.
2. «Download» para secuencias de comandos entre sitios (XSS): El método implica que un atacante, como resultado de algunas manipulaciones independientes, puede colocar datos en un servicio utilizando un certificado TLS común, que luego se puede emitir en respuesta a una solicitud del usuario. El ataque es aplicable a los servidores FTP, servidores IMAP y servidores POP3 antes mencionados (courier, cyrus, kerio-connect y zimbra).
3. Reflection para ejecutar JavaScript en el contexto de otro sitio: El método se basa en devolver una parte de la solicitud al cliente, que contiene el código JavaScript enviado por el atacante. El ataque es aplicable a los servidores FTP antes mencionados, los servidores IMAP cyrus, kerio-connect y zimbra, así como al servidor SMTP sendmail.

Por ejemplo, cuando un usuario abre una página controlada por un atacante, se puede iniciar una solicitud de un recurso desde un sitio en el que el usuario tiene una cuenta activa desde esta página. En un ataque MITM, esta solicitud al sitio web se puede redirigir a un servidor de correo que comparte un certificado TLS.

Dado que el servidor de correo no finaliza la sesión después del primer error, los encabezados de servicio y los comandos se procesarán como comandos desconocidos.

El servidor de correo no analiza los detalles del protocolo HTTP y para ello los encabezados de servicio y el bloque de datos de la solicitud POST se procesan de la misma manera, por lo tanto, en el cuerpo de la solicitud POST, puede especificar una línea con el comando al servidor de correo.

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.

Fuentes:

https://alpaca-attack.com/

https://blog.underc0de.org/alpaca-un-nuevo-tipo-de-ataque-man-in-the-middle-en-https/

https://unaaldia.hispasec.com/2021/06/ataque-a-tls-por-confusion-de-protocolos.html