Como escolher um programa de Bug Bounty?

Existem programas de Bug Bounty públicos e privados. Apesar de menor concorrência, os programas privados não são necessariamente melhores que os públicos. Quero mostrar algumas formas de avaliar rapidamente cada um deles utilizando as informações que estão disponíveis nas plataformas como a HackerOne.

Vou colocar 5 fatores a serem considerados e explicar cada um na sequência:

Interesse pelo assunto

Em primeiro lugar, o mais importante dos aspectos: você precisa ter interesse pelo assunto que irá explorar. Lembro-me de iniciar minha aventura de Bug Bounty por um site médico, onde os profissionais podiam fazer uploads de dados para o sistema e consultar visualizações. O fato é que eu não sou médico e não entendia nem metade das coisas que estavam sendo processadas ou visualizadas. Era como caçar às cegas. Não gostei da experiência, não consegui achar nenhuma falha e pior, este programa quase me fez desistir de continuar. 

Como você vai aprender, o processo de bug hunting é repetitivo e exige muita dedicação. Sem motivação você não vai ter prazer em continuar. Além do mais, problemas acontecerão. Se você não fizer o que gosta, alguns golpes poderão ser muito duros e comprometer a continuidade do trabalho. Mesmo que a recompensa seja interessante, não se atraia por um programa que você não goste, pois não é só o dinheiro que importa. Portanto a dica número 1 é: faça aquilo que gosta, pois você gastará bastante tempo naquilo. 

Adequação técnica

Dito isto, vamos olhar alguns aspectos menos subjetivos para comparar os programas. Cada programa descreve o seu escopo técnico. A sua base em programação não é forte? Então não tem por que você ingressar em um programa de código-fonte, por exemplo. Esteja especialmente atento à lista de exclusões do escopo. Seu forte é SQL injection? XSS? Stack overflow? Então certifique-se de que estes tipos de vulnerabilidade não estão excluídos da lista de bugs aceitos.

Aspectos numéricos

Uma métrica que aparece para cada programa é o tempo de resposta da empresa (ou o percentual de respostas). Algumas são mais rápidas em responder ao relatório enviado e outras demoram mais. Empresas que demoram demais mostram que estão menos comprometidas com o seu trabalho, e você deve evitá-las. Além da métrica, observe como é a comunicação entre o bug hunter e a empresa nos relatórios que estão abertos para visualização. A empresa se comunica bem? O relacionamento com o bug hunter é cordial e fraterno? Uma comunicação muito fria pode intimidar aqueles que estão no começo do caminho e têm medo de errar. 

Ao fazer o exercício de ler sobre os bugs passados, o bug hunter terá o benefício de conhecer quais são os tipos de falha mais comuns naquele programa, o que lhe permitirá avaliar se o escopo vulnerável é compatível com o seu conhecimento técnico.

Outra coisa que eu considero importante de ser avaliado é o número de submissões. Se o programa possui poucas ou nenhuma submissão é um mau sinal. O programa pode ter sido excessivamente testado antes de ser disponibilizado, a superfície de ataque pode ser muito pequena, ou ainda pode requerer um setup muito trabalho. Lembro ainda que no caso do programa médico mencionado, havia a possibilidade de instalar o aplicativo no computador, o que poderia ser feito seguindo um passo a passo que incluía compilação, instalação, configuração. Ou seja, muito trabalho apenas para começar. Hoje em dia, se o trabalho para começar for muito grande, mesmo que seja um cadastro demorado de se fazer, logo pulo para outro programa.

E por último, acho útil analisar a faixa de valor das recompensas. Recompensas baixas podem ser interessantes para o iniciante, que assim poderá encontrar bugs menos concorridos e construir uma reputação. Os programas que pagam mais atraem mais pessoas também. Ao entrar em um programa desse, espere muita competição e demora para conseguir um relatório único, ou seja, não duplicado. No entanto, esta estratégia pode valer a pena se o bug hunter tiver persistência e não tiver pressa em ter resultado.

Outros programas

Mas quem disse que você está limitado aos programas que aparecem nas grandes plataformas de Bug Bounty? Uma estratégia para evitar as multidões é trabalhar em programas mantidos pelas próprias empresas que serão testadas. Infelizmente as informações sobre o programa não serão tão completas quanto aqueles cadastrados nas grandes plataformas, mas por outro lado, você terá a chance de trabalhar com uma empresa que realmente tem interesse. Pense em uma agora. Depois vá ao Google e pesquise:

{nome da empresa} bug bounty

{nome da empresa} responsible disclosure

{nome da empresa} security report

Um programa por vez ou simultâneos?

Talvez o leitor se pergunte: é melhor trabalhar em um programa por vez ou simultaneamente em mais que um? A minha resposta é: faça os dois! Por mais que isto pareça ilógico, permita o leitor que eu me explique. Estou convicto de que para estudar um sistema a ponto de dominá-lo e encontrar falhas é necessário dedicação e focar em apenas um assunto por vez. Neste caso, a resposta seria: faça apenas um. Porém, vou explicar futuramente sobre a estratégia de se construir scripts para automatizar a caça aos bugs. Como o trabalho é automático e você será requisitado apenas para conferir se a falha é explorável, não vejo problema em fazer vários, ou melhor, fazer o máximo de programas ao mesmo tempo.

Recomendação

Em seu canal InsiderPhD do YouTube, a Katie publicou um vídeo “Finding Your First Bug: Choosing Your Target”, onde ela comenta sobre todos estes pontos ilustrando com exemplos e eu acho que o leitor gostará de ouví-la.

Gostou do conteúdo? Acompanhe-nos em nosso grupo do Telegram:

Bug Bounty para Iniciante