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
Artigo p/ ler depois ++
Aprofundamento em desserialização insegura (vlw pela call N1nja):
https://klezvirus.github.io/Advanced-Web-Hacking/Serialisation/
Aprofundamento em desserialização insegura (vlw pela call N1nja):
https://klezvirus.github.io/Advanced-Web-Hacking/Serialisation/
Quando eu falo de um ataque complexo clientside, falo de algumas chains muito bem elaboradas.
Tipo essa do Vitor Falcão(busfactor) com o XssDoctor. Conseguiram ela escalando um self xss pra um full xss, usando CSPT (client side path traversal) + JSON + SelfXss -> Cookie path -> xss:
https://blog.vitorfalcao.com/posts/hacking-high-profile-targets/
Link novo: https://vitorfalcao.com/posts/hacking-high-profile-targets/
Mad respect 🫡
Tipo essa do Vitor Falcão(busfactor) com o XssDoctor. Conseguiram ela escalando um self xss pra um full xss, usando CSPT (client side path traversal) + JSON + SelfXss -> Cookie path -> xss:
Link novo: https://vitorfalcao.com/posts/hacking-high-profile-targets/
Mad respect 🫡
