Los piratas informáticos pueden meterse con las conexiones HTTPS enviando datos a su servidor de correo electrónico

Una imagen muy estilizada de un candado.

Cuando visita un sitio web protegido por HTTPS, su navegador no intercambia datos con el servidor web hasta que se ha asegurado de que el certificado digital del sitio es válido. Eso evita que los piratas informáticos con la capacidad de monitorear o modificar los datos que pasan entre usted y el sitio obtengan cookies de autenticación o ejecuten código malicioso en el dispositivo visitante.

Pero, ¿qué pasaría si un atacante intermediario pudiera confundir al navegador para que se conectara accidentalmente a un servidor de correo electrónico o servidor FTP que usa un certificado que es compatible con el que usa el sitio web?

Los peligros de hablar HTTPS con un servidor de correo electrónico

Debido a que el nombre de dominio del sitio web coincide con el nombre de dominio en el correo electrónico o el certificado del servidor FTP, el navegador, en muchos casos, establecerá un Transport Layer Security conexión con uno de estos servidores en lugar del sitio web que el usuario pretendía visitar.

Debido a que el navegador se comunica en HTTPS y el servidor de correo electrónico o FTP utiliza SMTP, SFTP u otro protocolo, existe la posibilidad de que las cosas salgan terriblemente mal; una cookie de autenticación descifrada podría enviarse al atacante, por ejemplo, oa un atacante podría ejecutar código malicioso en la máquina visitante.

El escenario no es tan descabellado como algunas personas podrían pensar. De hecho, una nueva investigación encontró que aproximadamente 14,4 millones de servidores web utilizan un nombre de dominio que es compatible con la credencial criptográfica de un servidor de correo electrónico o FTP que pertenece a la misma organización. De esos sitios, alrededor de 114.000 se consideran explotables porque el servidor de correo electrónico o FTP utiliza software que se sabe que es vulnerable a tales ataques.

Estos ataques son posibles debido a la falla de TLS para proteger la integridad de la conexión TCP en sí, en lugar de la integridad del servidor que habla HTTP, SMTP u otro idioma de Internet. Los atacantes intermediarios pueden aprovechar esta debilidad para redirigir el tráfico TLS desde el servidor y el protocolo previstos a otro punto final y protocolo sustitutos.

“El principio básico es que un atacante puede redirigir el tráfico destinado a un servicio a otro, porque TLS no protege la dirección IP o el número de puerto”, me dijo Marcus Brinkmann, investigador de la Universidad Ruhr de Bochum en Alemania. “En el pasado, la gente ha considerado ataques en los que el atacante MitM redirige un navegador a un servidor web diferente, pero estamos consi derando el caso en el que el atacante redirige el navegador desde el servidor web a un servidor de aplicaciones diferente, como FTP o correo electrónico”.

Grietas en la piedra angular

Normalmente abreviado como TLS, Transport Layer Security utiliza un cifrado fuerte para demostrar que un usuario final está conectado a un servidor auténtico que pertenece a un servicio específico (como Google o Bank of America) y no un impostor disfrazado de ese servicio. TLS también encripta los datos mientras viajan entre un usuario final y un servidor para garantizar que las personas que pueden monitorear la conexión no puedan leer o manipular el contenido. Con millones de servidores que dependen de él, TLS es la piedra angular de la seguridad en línea.

en un trabajo de investigación publicado el miércoles, Brinkmann y otros siete investigadores investigaron la viabilidad de usar lo que ellos llaman ataques de protocolo cruzado para eludir las protecciones TLS. La técnica implica que un atacante MitM redirija solicitudes HTTP de origen cruzado a servidores que se comunican a través de SMTP, IMAP, POP3 o FTP u otro protocolo de comunicación.

Los principales componentes del ataque son (1) la aplicación cliente utilizada por el usuario final objetivo, indicada como C; (2) el servidor que el objetivo pretendía visitar, indicado como SEn t

; y (3) el servidor sustituto, una máquina que se conecta mediante SMTP, FTP u otro protocolo que sea diferente del único servidorEn t utiliza pero con el mismo dominio que aparece en su certificado TLS.

Los investigadores identificaron tres métodos de ataque que los adversarios de MitM podrían utilizar para comprometer la navegación segura de un objetivo en este escenario. Ellos son:

Subir ataque. Para este ataque, asumimos que el atacante tiene alguna capacidad para cargar datos en Ssub y recupéralo más tarde. En un ataque de carga, el atacante intenta almacenar partes de la solicitud HTTP del navegador (específicamente el encabezado de la cookie) en Ssub. Esto podría ocurrir, por ejemplo, si el servidor interpreta la solicitud como una carga de archivo o si el servidor registra las solicitudes entrantes de manera detallada. En un ataque exitoso, el atacante puede recuperar el contenido en el servidor independientemente de la conexión de C a Ssub y recuperar la cookie de sesión HTTPS.

Descargar ataque: XSS almacenado. Para este ataque, asumimos que el atacante tiene alguna capacidad para preparar datos almacenados en Ssub y descárgalo. En un ataque de descarga, el atacante aprovecha las características benignas del protocolo para “descargar” datos previamente almacenados (y específicamente diseñados) de Ssub a C. Esto es similar a una vulnerabilidad XSS almacenada. Sin embargo, debido a que se utiliza un protocolo diferente de HTTP, incluso los mecanismos de defensa sofisticados contra XSS, como Content-Security-Policy
(CSP), se puede eludir. Muy probablemente, Ssub no enviará ningún CSP por sí mismo, y gran parte de la respuesta está bajo el control del atacante.

Ataque de reflexión: XSS reflejado. En un ataque de reflexión, el atacante intenta engañar al servidor Ssub para reflejar partes de la solicitud de C en su respuesta a C. Si tiene éxito, el atacante envía JavaScript malicioso dentro de la solicitud que se refleja en Ssub. Luego, el cliente analizará la respuesta del servidor, lo que a su vez puede conducir a la ejecución de JavaScript en el contexto del servidor web de destino.

El adversario de MitM no puede descifrar el tráfico de TLS, pero aún hay otras cosas que el adversario puede hacer. Obligar al navegador del objetivo a conectarse a un servidor de correo electrónico o FTP en lugar del servidor web previsto, por ejemplo, puede hacer que el navegador escriba una cookie de autenticación en el servidor FTP. O podría habilitar ataques de secuencias de comandos entre sitios que hacen que el navegador descargue y ejecute JavaScript malicioso alojado en el servidor FTP o de correo electrónico.

Hacer cumplir las protecciones de ALPN y SNI

Para evitar ataques entre protocolos, los investigadores propusieron una aplicación más estricta de dos protecciones existentes. El primero se conoce como negociación del protocolo de la capa de aplicación, una extensión TLS que permite que una capa de aplicación, como un navegador, negocie qué protocolo debe usarse en una conexión segura. ALPN, como se suele abreviar, se utiliza para establecer conexiones utilizando el protocolo HTTP / 2 de mejor rendimiento sin viajes de ida y vuelta adicionales.

Al hacer cumplir estrictamente ALPN como se define en el estándar formal, las conexiones creadas por navegadores u otras capas de aplicaciones que envían la extensión no son vulnerables a ataques entre protocolos.

Del mismo modo, el uso de una extensión TLS separada llamada indicación del nombre del servidor puede proteger contra ataques de nombre de host cruzado si está configurado para terminar la conexión cuando no se encuentra un host coincidente. “Esto puede proteger contra ataques entre protocolos en los que el servidor previsto y el sustituto tienen diferentes nombres de host, pero también contra algunos ataques del mismo protocolo, como la confusión del host virtual HTTPS o los ataques de confusión de contexto”, escribieron los investigadores.

Los investigadores están llamando a sus ataques de protocolo cruzado ALPACA, abreviatura de “protocolos de capa de aplicación que permiten ataques de protocolo cruzado”. Por el momento, ALPACA no representa una amenaza importante para la mayoría de las personas. Pero el riesgo que se plantea podría aumentar a medida que se descubran nuevos ataques y vulnerabilidades o se utilice TLS para proteger canales de comunicación adicionales.

“En general, el ataque es muy situacional y se dirige a usuarios individuales”, dijo Brinkmann. “Por lo tanto, el riesgo individual para los usuarios probablemente no sea muy alto. Pero con el tiempo, más y más servicios y protocolos están protegidos con TLS, y surgen más oportunidades para nuevos ataques que siguen el mismo patrón. Creemos que es oportuno e importante mitigar estos problemas a nivel de estandarización antes de que se convierta en un problema mayor “.

Leave a Reply

Your email address will not be published. Required fields are marked *