Aunque las nuevas aplicaciones de mensajería como WhatsApp, Telegram y Messenger han ocupado una gran parte de nuestras comunicaciones diarias, el correo electrónico sigue siendo una de las formas más populares de comunicación. En esta publicación, hablaremos sobre la explotación posterior de una vulnerabilidad que revelamos recientemente a uno de los proveedores de correo electrónico más populares de Israel.

Al igual que Facebook, Google y otras empresas de renombre, el proveedor de correo electrónico opera un programa de recompensas por errores en el que alienta a los investigadores de seguridad a encontrar e informar vulnerabilidades en sus servicios.

Dicho esto, la compañía solicitó permanecer en el anonimato en este momento, para el propósito de esta publicación, nos referiremos a ella como Y.

La vulnerabilidad

Los clientes de correo electrónico utilizan un subconjunto de HTML para proporcionar capacidades de formato que no están disponibles con texto plano, cosas como imágenes, enlaces, colores, etc. Esto coloca a los proveedores de correo electrónico en un lugar peligroso. Por un lado, deben filtrar HTML peligroso y, por otro lado, quieren que su correo electrónico se procese correctamente.

Teniendo esto en cuenta, comenzamos a profundizar en el filtro HTML de Y.
Enviamos correos electrónicos con varias cargas útiles a nuestra cuenta de correo de Y. Por ejemplo, al enviar el siguiente HTML como cuerpo del correo electrónico:

<div> <div> hola <script src = “//example.com” > </script> mundo </div> </div>
   

Recibimos el correo electrónico con el siguiente HTML:

<div> <div> hola mundo </div> </div>

Como puede ver, el filtro Y eliminó la etiqueta del script.
Sin embargo, al enviar lo siguiente:

<div> <div> hola <scrXipt src = “//example.com” > </scrXipt> mundo </div> </div>

No se realizaron cambios en el cuerpo del correo electrónico, lo que nos hizo creer que Y usa una lista de denegación.
En otras palabras, el filtro HTML de la Y probablemente esté buscando palabras clave específicas para eliminar como <script>, onerror, onload y más. En este punto, intentamos imaginar cómo se podría implementar un filtro de lista de denegación; después de unos minutos, se nos ocurrió el siguiente pseudocódigo:

function removeDangerousKeywords ( cuerpo ) { palabras clave = [ / en [ az ] + / i, / <script / i, / *… * / ]; para ( palabra clave de palabras clave ) { cuerpo = cuerpo . replaceAll ( palabra clave , "" );    }

   

    cuerpo de regreso ;

}

Aparte del problema obvio con una lista de denegación ( ¿y si olvidó bloquear algo?)

Notamos que el orden en el que eliminamos las palabras clave peligrosas se puede usar para omitir el filtro, incluso si tenemos una lista perfecta que contiene todo las palabras clave peligrosas.

Nos dimos cuenta de que el cuerpo del correo electrónico cambia a medida que el filtro desciende por la lista de palabras clave.
Esto significa que podemos diseñar una carga útil que el filtro transformará en una peligrosa a medida que elimina las palabras clave en orden.

Después de algunos intentos, se nos ocurrió la siguiente carga útil que funcionó.

<img src = v en <script> error = alerta ( ubicación . origen ) />

Como puede ver, las cargas útiles utilizan la etiqueta <script> para ocultar el atributo "onerror". Dado que la regla responsable de eliminar dichos atributos se ejecuta antes que la regla que elimina las etiquetas de script, nuestra carga útil no será detectada.

Ahora podríamos ejecutar JavaScript arbitrario en la cuenta de cualquier usuario que abriera nuestro correo electrónico. Esto podría permitirnos realizar cualquier acción como usuario, desde leer todos los correos electrónicos del usuario hasta enviar otros nuevos.

Después de la explotación

Si bien el Cross-Site Scripting (XSS) almacenado en el cuerpo del correo electrónico es un gran problema, es importante recordar que una vez que el usuario vuelva a cargar la página, el atacante ya no tendrá acceso a su cuenta. El atacante tendría que seguir enviando nuevos correos electrónicos a su objetivo y esperar que se abran para recopilar información de forma continua.

Queríamos profundizar en este escenario y ver qué se podía hacer desde el punto de vista del atacante con este tipo de acceso temporal.

Primero examinamos las cookies de correo Y, ya que potencialmente podrían permitir la toma de control de la cuenta. Descubrimos que no podían ser explotados ya que Y usa el indicador de solo HTTP para sus cookies sensibles.

A continuación, miramos la configuración de la cuenta, intentamos incrustar nuestra carga útil en la firma del usuario. De esa manera, cuando se enviara un nuevo correo electrónico, nuestro script se ejecutaría nuevamente, dándonos acceso continuo. Esto resultó ser otro callejón sin salida, nuestro método para eludir el filtro HTML de Y'.s no engañó al punto final de la firma de correo electrónico.

Al probar el punto final responsable de guardar la firma del correo electrónico, notamos un campo interesante llamado "api" que contenía la URL de la API utilizada por el cliente de correo electrónico Y. Intentamos modificarlo y, para nuestra sorpresa, funcionó. Lo hicimos enviando la siguiente solicitud:

La propiedad "api" de la cuenta ahora apuntaba a un dominio bajo nuestro control. Sin embargo, no era obvio para qué se usaba, ya que las solicitudes del cliente de correo electrónico web aún se enviaban a la API Y original.

Fue solo cuando abrimos la aplicación móvil Y cuando descubrimos que todas las solicitudes de nuestra cuenta llegaban a nuestro dominio. Configuramos rápidamente un proxy entre nuestro servidor y la API Y original, reiniciamos la aplicación y, como era de esperar, pudimos interceptar todas las comunicaciones entre la aplicación y la API Y.

Impacto de la vulnerabilidad almacenada XSS

El atacante podría usar la vulnerabilidad Stored XSS para obtener acceso continuo a la cuenta modificando la propiedad "api" de la cuenta. Una vez que se actualizaba la API, la aplicación móvil Y enviaba todas las solicitudes a través de los servidores del atacante, lo que le daba un control total sobre la cuenta.

Clasificamos este problema como una vulnerabilidad de asignación masiva, ya que el usuario no debería haber configurado esta propiedad. Finalmente, codificamos un exploit utilizando las dos vulnerabilidades que funcionarían de la siguiente manera:

1. Enviamos un correo electrónico con nuestra carga útil XSS a nuestro objetivo
2. El objetivo abre el correo electrónico
3. Nuestro script inyectado envía todos los correos electrónicos de los usuarios a nuestro servidor
4. Nuestro script inyectado sobrescribe el punto final de la API del usuario
5. La próxima vez que nuestro objetivo use la aplicación móvil Y, todo su tráfico fluirá a través de nuestro servidor, dándonos un control total sobre la cuenta.

Compartimos nuestros hallazgos con el equipo de seguridad de Y, quien rápidamente solucionó todas las vulnerabilidades en unas pocas horas. Y también ha confirmado que no había evidencia de abuso de esta vulnerabilidad, ya que todas las cuentas apuntaban al dominio de la API Y.

Pensamientos finales

Como investigadores, fue un privilegio contribuir a proteger la privacidad de la comunidad de usuarios de Y mail, como lo hacemos continuamente con nuestros propios clientes de Imperva.