Como evito duplicados em Bugbounty?
Salve, pessoal! Sejam bem-vindos à nossa nova série sobre Bug Bounty!
Para quem acompanha nosso grupo VIP no Telegram, este post é uma prévia do conteúdo detalhado que já compartilhamos por lá em vídeo. Para ter acesso a explicações mais aprofundadas e insights exclusivos, junte-se ao nosso grupo VIP através deste link!
Nesta primeira parte, vamos mergulhar em um dos maiores desafios dos bug hunters: os temidos relatórios duplicados.
É um cenário comum: você investe tempo e esforço, encontra uma vulnerabilidade, prepara um relatório impecável e, ao enviá-lo, recebe a notificação de que seu achado é um “duplicado”.
Isso acontece com frequência, especialmente para quem está começando ou para aqueles que migram de programas VDP (Vulnerability Disclosure Program), onde o objetivo é apenas pontuação, para programas pagos, onde a recompensa financeira depende da originalidade do seu achado.
A explicação para essa recorrência de duplicados é simples, mas muitas vezes ignorada: a competitividade no universo do Bug Bounty e a maturidade das empresas que oferecem esses programas.
Muitos profissionais vêm do mundo do pentest (teste de intrusão) e esperam ter o mesmo sucesso no Bug Bounty. No entanto, há uma diferença crucial:
- Pentest: A competitividade geralmente se resume a “quando foi o último pentest executado nesta empresa?”. O escopo e o tempo são limitados, e você é um dos poucos a testar.
- Bug Bounty: Centenas, ou até milhares, de hunters podem estar atacando o mesmo alvo simultaneamente. Enquanto você envia uma requisição para um endpoint explorando uma vulnerabilidade
Xcom seu conhecimentoYe usando a ferramentaZ, pode ter alguém do outro lado do mundo fazendo exatamente a mesma coisa, talvez com um background ou uma ferramenta ligeiramente diferente. É uma corrida contra o tempo e contra todos.
A famosa frase de Albert Einstein se aplica perfeitamente aqui: “Insanidade é continuar fazendo sempre a mesma coisa e esperar resultados diferentes.”
Se a maioria está usando as mesmas ferramentas e as mesmas metodologias, é natural que os resultados sejam semelhantes – e, consequentemente, que os duplicados se acumulem.
Para sair desse ciclo, precisamos pensar diferente.
Vamos pegar a fase de reconhecimento como exemplo. Ao iniciar um programa de Bug Bounty, você acessa a página (HackerOne, Bugcrowd, etc.), analisa o escopo e os domínios. Como você começa a busca?
Provavelmente, você executa algumas das ferramentas mais populares:
Sublist3rAmassMassDNSFindomainChaos clientShuffleDNS(para permutação de DNS)DNSxSubfinderAssetfinderCensysShodancrt.shhttprobegobusterdirsearchNaabuKiterunnerGauWaybackurlsKatanaDnsenumfierceAltdnsaquatone
Se você usa alguma dessas, sinto muito informar: você não é especial.
Centenas de milhares de bug hunters estão utilizando exatamente as mesmas ferramentas.
Elas seguem uma lógica específica, um caminho pré-definido, e o resultado será o mesmo para todos que as executam da mesma forma.
Vamos a um exemplo prático: a ferramenta HTTPX, amplamente utilizada para verificar a acessibilidade de URLs e a exposição de serviços HTTP.
Tenho certeza que sim, ou já ouviu falar de alguém que usa. O HTTPX faz requisições HTTP para verificar se uma URL está ativa e respondendo.
Recentemente, eu descobri um comportamento do HTTPX que me fez não encontrar uma vulnerabilidade específica em uma aplicação que eu sabia que existia. Parece simples, mas o detalhe está na forma como o HTTPX manipula URLs com parâmetros vazios.
O Problema:
Quando o HTTPX recebe uma URL com um parâmetro vazio na query string, como https://exemplo.com/?parametro=, ele remove o sinal de igual (=). A URL se torna https://exemplo.com/?parametro.
A Diferença Crítica:
Para quem programa, a diferença entre um valor vazio (empty string "") e um valor nulo (null) é gritante.
- Com igual (
?parametro=): Universalmente, é interpretado como uma chave (parametro) com um valor de string vazia (""). O backend recebe a chave esperada com um valor vazio. - Sem igual (
?parametro): Frequentemente, é interpretado como uma chave (parametro) com um valor nulo (null).
Sistemas como ASP.NET no IIS e Ruby on Rails fazem essa interpretação do “sem o igual” como valor nulo.
Na aplicação que eu estava testando, que usava ASP.NET, eu precisava que o parâmetro fosse interpretado como string vazia para acionar o comportamento vulnerável. Com o HTTPX removendo o =, a aplicação recebia um valor nulo, resultando em um erro e não acionando a falha que eu esperava.
Se eu confiasse cegamente no HTTPX, eu teria descartado aquele alvo como “não vulnerável”. Aqui está a diferença: questionar as ferramentas, entender o que elas realmente fazem e como isso afeta o resultado.
Ok, você pode pensar: “então não vou usar HTTPX”. E o Nuclei? O que você pode estar deixando para trás com ele?
Vamos supor que você está usando um template do Nuclei direcionado a uma tecnologia específica que sua aplicação usa, e o backend é realmente vulnerável. Tudo certo, não? O que pode dar errado?
Um Firewall (WAF) pode dar errado!
Quando o Nuclei encontra um WAF (Web Application Firewall), ele pode retornar que a falha não foi explorável ou que não há falha. Você assume que o alvo não é vulnerável e o descarta.
Pense na vulnerabilidade Log4j. Assim que foi descoberta, os maiores hunters e equipes de segurança foram atrás, encontrando muitas falhas. As empresas, para corrigir rapidamente, adicionaram camadas de proteção, como WAFs (Cloudflare é um exemplo).
O Cloudflare, por exemplo, rapidamente aprendeu os payloads de Log4j. Se você rodasse um template padrão do Nuclei contra um alvo protegido pelo Cloudflare, ele seria bloqueado, retornaria um erro (como “comportamento indevido detectado” ou um captcha), e você pensaria que a vulnerabilidade não existe.
A Sacada: Hunters experientes começaram a criar payloads e assinaturas de Log4j que o Cloudflare não conseguiria detectar. Eles buscavam bypasses para o WAF, permitindo que a exploração passasse despercebida.
Um hunter no Twitter compartilhou um bypass de Log4j que ele capturou dos próprios logs do seu servidor. Isso mostra a inteligência por trás: quando uma nova vulnerabilidade surge, o mundo inteiro tenta escaneá-la (para fins maliciosos ou Bug Bounty). Ao analisar esses logs, ele encontrou um payload que não era detectado pelo Cloudflare.
Esta é a essência de ser diferente, de pensar fora da caixa, de buscar bypasses e de contornar o senso comum.
Se você fizer o que todos fazem, você terá os mesmos resultados que todos. A não ser que você seja o primeiro, mas a corrida pela velocidade em automação pode te impedir de aprofundar no programa e se tornar um especialista.
Minha metodologia é focar em ser diferente, em ir a fundo nos programas e entender suas nuances.
Esta foi a Parte 1 da nossa série “Como sair dos duplicados em Bug Bounty?”. Abordamos a importância de questionar as ferramentas, entender seus comportamentos e buscar bypasses para defesas comuns. Falamos sobre HTTPX e Nuclei, mas há muito mais por vir!
O grupo VIP teve acesso a isso antes e acesso a um video explicando tudo isso de forma visual!
Nas próximas partes, exploraremos outras fases da etapa de exploração e traremos mais insights para te ajudar a se diferenciar no mundo do Bug Bounty.
Espero que tenham gostado! Qualquer dúvida, pode mandar no grupo aberto ou no VIP. Tamo junto!
E não se esqueça: para aprofundar ainda mais nesse assunto e ter acesso a todo o conteúdo da nossa saga em primeira mão, junte-se ao nosso grupo VIP no Telegram!