Un equipo de investigadores de varias universidades de Alemania ha desarrollado un nuevo ataque MITM en HTTPS que puede extraer cookies de sesión y otros datos confidenciales, 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 utilizan certificados TLS comunes.
La esencia del ataque es que si tiene control sobre una puerta de enlace de red o un punto de acceso inalámbrico, el atacante puede redirigir el tráfico web a otro puerto de red y organizar el establecimiento de una conexión con un servidor de correo o FTP que admita el cifrado TLS y utilice un Certificado TLS común con el servidor HTTP y el navegador del usuario asumirá que se ha establecido una conexión con el servidor HTTP solicitado. Dado que el protocolo TLS es universal y no está vinculado a protocolos a nivel de aplicación, el establecimiento de una conexión cifrada para todos los servicios es idéntico y el error de enviar una solicitud al servicio incorrecto se puede determinar solo después de establecer una sesión cifrada mientras se procesa el comandos de la solicitud enviada.
En consecuencia, si, por ejemplo, redirige una conexión de usuario originalmente dirigida a HTTPS a un servidor de correo que utiliza un certificado compartido con el servidor HTTPS, la conexión TLS se establecerá exitosamente, pero el servidor de correo no podrá procesar la información transmitida. Comandos HTTP 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:
- “Subir” para recuperar una Cookie con parámetros de autenticación. El método es aplicable si el servidor FTP cubierto por el certificado TLS le permite cargar y recuperar sus datos. En esta variante de ataque, el atacante puede lograr la retenció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 guardado o registra las solicitudes entrantes por completo. Para atacar con éxito, el atacante necesita extraer de alguna manera el contenido almacenado. El ataque es aplicable a Proftpd, Microsoft IIS, vsftpd, filezilla y serv-u.
- "Descargar" para organizar secuencias de comandos entre sitios (XSS). El método implica que el atacante, como resultado de algunas manipulaciones individuales, puede colocar datos en un servicio que utiliza un certificado TLS común, que luego puede emitir en respuesta a una solicitud del usuario. El ataque es aplicable a los servidores FTP, servidores IMAP y servidores POP3 mencionados anteriormente (courier, cyrus, kerio-connect y zimbra).
- "Reflexión" para ejecutar JavaScript en el contexto de otro sitio. El método se basa en devolver al cliente la parte de la solicitud, que contiene el código JavaScript enviado por el atacante. El ataque es aplicable a los servidores FTP mencionados anteriormente, a los servidores IMAP cyrus, kerio-connect y zimbra, así como al servidor SMTP de sendmail.
Por ejemplo, cuando un usuario abre una página controlada por un atacante, esta página puede iniciar una solicitud de un recurso desde un sitio donde el usuario tiene una cuenta activa (por ejemplo, bank.com). Durante un ataque MITM, esta solicitud dirigida al sitio web bank.com puede redirigirse a un servidor de correo electrónico que utiliza un certificado TLS compartido con bank.com. Dado que el servidor de correo no finaliza la sesión después del primer error, los encabezados de servicio y los comandos como "POST/HTTP/1.1" y "Host:" se procesarán como comandos desconocidos (el servidor de correo devolverá "500 comandos no reconocidos" para cada encabezado).
El servidor de correo no comprende las características 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 que en el cuerpo de la solicitud POST puede especificar una línea con un comando para el servidor de correo. Por ejemplo, puedes pasar: CORREO DE: alert(1); al cual el servidor de correo devolverá un mensaje de error 501 alert(1); : dirección con formato incorrecto: alerta(1); puede que no siga
Esta respuesta será recibida por el navegador del usuario, que ejecutará el código JavaScript en el contexto no del sitio web abierto inicialmente por el atacante, sino del sitio web bank.com al que se envió la solicitud, ya que la respuesta llegó dentro de una sesión TLS correcta. , cuyo certificado confirmó la autenticidad de la respuesta de bank.com.
Un análisis de la red global mostró que en general alrededor de 1.4 millones de servidores web están afectados por el problema, por lo que es posible realizar un ataque mezclando solicitudes utilizando diferentes protocolos. Se determinó la posibilidad de un ataque real en 119 servidores web, a los que acompañaban servidores TLS basados en otros protocolos de aplicación.
Se han preparado ejemplos de exploits para servidores ftp pureftpd, proftpd, microsoft-ftp, vsftpd, filezilla y serv-u, servidores IMAP y POP3 dovecot, courier, exchange, cyrus, kerio-connect y zimbra, servidores SMTP postfix, exim, sendmail , mailenable, mdaemon y opensmtpd. Los investigadores han estudiado la posibilidad de realizar un ataque sólo en combinación con servidores FTP, SMTP, IMAP y POP3, pero es posible que el problema también se produzca con otros protocolos de aplicación que utilizan TLS.
Para bloquear el ataque, se propone utilizar la extensión ALPN (Application Layer Protocol Negotiation) para negociar una sesión TLS teniendo en cuenta el protocolo de la aplicación y la extensión SNI (Server Name Indication) para vincularse al nombre del host en el caso de utilizar Certificados TLS que cubren varios nombres de dominio. En el lado de la aplicación, se recomienda limitar el número de errores al procesar comandos, después de lo cual se finaliza la conexión. El proceso de desarrollo de medidas para bloquear el ataque comenzó en octubre del año pasado. Ya se han tomado medidas de seguridad similares en Nginx 1.21.0 (proxy de correo), Vsftpd 3.0.4, Courier 5.1.0, Sendmail, FileZill, crypto/tls (Go) e Internet Explorer.
Fuente: opennet.ru