UNIVERSIDADE FEDERAL DE PERNAMBUCO

GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

CENTRO DE INFORMÁTICA

JOÃO LUCAS GOMES DE MIRANDA

ESTUDO SOBRE OS PROGRAMAS DE CAÇA AOS BUGS E SEUS

BENEFÍCIOS
TRABALHO DE GRADUAÇÃO

RECIFE
2019
 JOÃO LUCAS GOMES DE MIRANDA

ESTUDO SOBRE OS PROGRAMAS DE CAÇA AOS BUGS E SEUS

BENEFÍCIOS
TRABALHO DE GRADUAÇÃO

Trabalho de Graduação apresentado à

graduação em Ciência da Computação do
Centro de Informática da Universidade Federal
de Pernambuco para obtenção do grau de
Bacharel em Ciência da Computação.

Orientador – Prof.º Vinicius Cardoso Garcia

RECIFE
2019
 3

JOÃO LUCAS GOMES DE MIRANDA

ESTUDO SOBRE OS PROGRAMAS DE CAÇA AOS BUGS E SEUS

BENEFÍCIOS
TRABALHO DE GRADUAÇÃO

Trabalho de Graduação apresentado à

graduação em Ciência da Computação do
Centro de Informática da Universidade Federal
de Pernambuco para obtenção do grau de
Bacharel em Ciência da Computação.

Recife, ____ de julho de 2019.

BANCA EXAMINADORA

________________________________________________
Prof.º Vinicius Cardoso Garcia
(Orientador)

________________________________________________
Prof.ª Kiev Santos da Gama
(Avaliador)
 4

AGRADECIMENTOS
Agradeço a minha família pelo incentivo e pelo apoio incondicional. Ao Prof.º
Vinicius Cardoso Garcia pela orientação, paciência e pela ajuda sempre solícita e
rápida durante a elaboração desse projeto. Aos meus amigos do Centro de
Informática com os quais eu pude conversar sobre as dificuldades enfrentadas.
 5

RESUMO

Embora atualmente já tenhamos avanços significativos em Engenharia de Software,

programas Desktop e aplicativos para celular permanecem, de um modo geral,
inseguros. Ao mesmo tempo, a necessidade de tais sistemas apenas cresce com o
tempo, levantando grandes preocupações quanto a aspectos como privacidade e
segurança. Visando amenizar tal problemática, algumas empresas decidiram
terceirizar o esforço de encontrar vulnerabilidades em seus sistemas – surgindo,
assim, os programas de “bug bounty”, ou caça aos bugs. Tais programas possuem o
objetivo de incentivar pesquisadores de segurança (ou “hackers éticos”) a procurar e
documentar vulnerabilidades em sistemas da organização, sob oferta de premiação
e fama baseados em resultados; criando-se, assim, um ambiente de cooperação
entre comunidade e empresa – um ambiente onde ambos os lados saem ganhando.
O presente trabalho visa o estudo da prática, sob perspectiva do pesquisador e
também da organização.
 6

ABSTRACT

Despite significant progress in software development practices, Desktop programs

and mobile applications are, still, insecure. At the same time, the need for these
systems only increases with time, bringing privacy and security concerns to the table.
In response to these challenges, companies decided to crowdsource the effort to find
and document vulnerabilities in their systems – arising from this what is known as
bug bounty programs. The goal of these results-oriented programs is to incentivize
security researchers (also known as ethical hackers or white hat hackers) to find and
report vulnerabilities in organization’s systems, giving money and recognition as a
prize. This paper aims to study the practice, under the perspective of both
researchers and organization.
 7

SUMÁRIO

AGRADECIMENTOS ...............................................................................................................4
RESUMO ..................................................................................................................................5
ABSTRACT ..............................................................................................................................6
SUMÁRIO.................................................................................................................................7
1. INTRODUÇÃO .................................................................................................................8
1.1. CONTEXTUALIZAÇÃO E MOTIVAÇÃO ............................................................................................................... 8
1.2. OBJETIVOS ............................................................................................................................................................ 8
1.3. ESTRUTURA DO DOCUMENTO ........................................................................................................................... 9
2. REFERENCIAL TEÓRICO .............................................................................................10
2.1. A WEB E SUA (IN)SEGURANÇA ...................................................................................................................... 10
2.2. O PROTOCOLO HTTP ..................................................................................................................................... 14
2.3. MAPEANDO APLICAÇÕES ................................................................................................................................ 15
2.4. ATACANDO USUÁRIO(S) ................................................................................................................................. 17
Cross Site Scripting (XSS) ........................................................................................................................................ 18
Phishing ........................................................................................................................................................................... 19
Open Redirect ................................................................................................................................................................ 19
2.5. ATACANDO SERVIDOR(ES) ............................................................................................................................ 20
SQL Injection ................................................................................................................................................................. 20
Remote Code Execution ............................................................................................................................................ 21
2.6. METODOLOGIA HACKER: UM CHECKLIST ..................................................................................................... 22
3. PROGRAMAS DE CAÇA AOS BUGS ..........................................................................24
3.1. DEFINIÇÃO ........................................................................................................................................................ 24
3.2. MANUTENÇÃO DE VULNERABILIDADES ....................................................................................................... 24
3.3. DIVULGAÇÃO DAS VULNERABILIDADES ....................................................................................................... 25
3.4. BENEFÍCIOS ....................................................................................................................................................... 26
3.5. INCENTIVOS ...................................................................................................................................................... 27
4. EXEMPLOS DE PROGRAMAS .....................................................................................29
4.1. HACKER ONE .................................................................................................................................................... 29
4.2. BUG CROWD ...................................................................................................................................................... 29
4.3. FACEBOOK WHITEHAT .................................................................................................................................. 30
4.4. GOOGLE BUG HUNTER PROGRAM ................................................................................................................. 30
5. CONCLUSÃO.................................................................................................................32
5.1. CONTRIBUIÇÕES ............................................................................................................................................... 32
5.2. DIFICULDADES ENCONTRADAS ..................................................................................................................... 32
5.3. TRABALHOS FUTUROS .................................................................................................................................... 32
REFERÊNCIA BIBLIOGRÁFICA...........................................................................................33
 8

1. INTRODUÇÃO
Este capítulo fornecerá uma contextualização dos assuntos abordados neste
projeto e a motivação para o trabalho produzido. Também serão apresentados os
principais objetivos deste Trabalho de Graduação, bem como a estrutura do restante
do documento.

1.1. Contextualização e Motivação

Os programas de bug bounty são programas criados por algumas empresas
de tecnologia – gigantes como Microsoft, Google e Facebook são exemplos – com o
objetivo de incentivar pesquisadores de segurança a realizarem testes de
penetração em seus sistemas, premiando os mesmos com dinheiro e/ou
reconhecimento [1]. Valores dos prêmios normalmente variam de acordo com o
impacto da(s) vulnerabilidade(s) encontrada(s).
Tais programas permitem que os desenvolvedores da(s) aplicação(es)
descubram falhas (algumas potencialmente críticas) antes delas virem a
conhecimento público, evitando exploração da(s) vulnerabilidade(s) e abusos por
outros hackers, crackers e script kiddies. Ao incentivar pesquisadores de segurança
a procurar vulnerabilidades em seus serviços, sob oferta de premiá-los, empresas
acabam tendo uma série de analistas – muitos deles com qualidade técnica nível
elite mundial – realizando testes em seus produtos "gratuitamente".
Não somente empresas, porém, têm usado de programas de bug bounty. O
Pentágono (órgão do governo dos EUA) também implementou o programa e obteve
bons resultados com ele [4]. Enquanto do lado das empresas, na maioria das vezes
o resultado compensa – custos para implementar um programa de bug bounty são
geralmente menores que o de manter exclusivamente uma equipe de segurança –,
para os analistas o sentimento é um pouco diferente. Há certa insatisfação [3] nos
analistas que dedicam a vida a essas tarefas. Há incertezas de se achar falhas
impactantes o suficiente e, em alguns casos, há empresas que dão prêmios de não
muito valor - como camisas e mochilas [5].

1.2. Objetivos
O objetivo deste trabalho é estudar os programas bug bounty: como são
implementados, custos associados, o custo/benefício quando comparado a outras
metodologias (tais como consultoria ou equipe própria de segurança). Além disso, o
 9

trabalho irá estudar e fornecer um background quanto às principais técnicas e

conhecimentos que devem existir no repertório de um analista interessado em
descobrir falhas em busca de prêmios. Finalmente, o trabalho irá discutir sobre
programas existentes em empresas como Google e Facebook, e também as
plataformas que foram criadas apenas com esse fim, como Hacker One e Bug
Crowd.

1.3. Estrutura do Documento

O Restante do documento será organizado da seguinte forma:

• Capítulo 2: Apresenta definições básicas sobre o funcionamento e segurança

da WEB; investiga o protocolo HTTP e explica como são realizados alguns
tipos de ataques a usuários e servidores. Por fim, exibe uma lista de itens que
um hacker ético poderia utilizar como “ponto de partida” ao executar um teste
de penetração em alguma aplicação.
• Capítulo 3: Define e estuda os benefícios dos programas de Bug Bounty –
como são implementados, custos associados, como é realizada a
manutenção e divulgação das vulnerabilidades. Do lado do pesquisador,
investiga os benefícios e incentivos desses programas.
• Capítulo 4: Discute sobre alguns programas existentes, tanto de gigantes da
computação como também os de plataformas que foram criadas unicamente
com essa finalidade.
 10

2. REFERENCIAL TEÓRICO
Nesse capítulo, serão apresentadas definições e conceitos referentes a como
funcionam a WEB, o protocolo HTTP e os mecanismos de segurança presentes nos
mesmos.
A seção 2.1 explica o que é a web e discute o principal fator de (in)segurança
da mesma: o usuário pode inserir dado. A seção 2.2 fala sobre o protocolo HTTP,
protocolo esse mais comumente usado nas aplicações Web (e, assim, o mais
importante de ser estudado por uma analista interessado em programas de caça aos
bugs). Seções 2.3, 2.4 e 2.5 discutem as técnicas mais comuns de ataques a
usuários e servidores. Por fim, a seção 2.6 tenta criar uma lista de itens – uma
espécie de “checklist” inicial – a serem investigados por um analista interessado em
participar de programas de bug bounty.

2.1. A Web e sua (in)segurança

Segurança de aplicações é um tópico novo e a cada vez mais importante [7].
Cada vez mais, empresas aumentam seus lucros em negócios digitais, usuários
confiam em sites e apps com seus dados sensíveis e criminosos que podem ganhar
muito dinheiro roubando informações como dados bancários ou comprometendo
sistemas supostamente seguros. Naturalmente, empresas não querem ver seus
sistemas publicamente vistos como inseguros – visto que reputação é importante -,
surgindo disso uma certa dificuldade sobre o estado de arte da segurança de
aplicações web. [7]
A Web (ou, mais especificamente, a World Wide Web – WWW) é um sistema
da informação onde documentos e outros recursos (como mídia) são identificados
por uma URL (do inglês Uniform Resource Locators), que são acessíveis pela
internet [8]. Enquanto recursos podem ser qualquer tipo de mídia “baixável”, páginas
são, por definição, escritas em HTML (do inglês “HyperText Markup Language”) [9],
línguagem essa que é interpretada pelos navegadores.
No começo da internet, a Web era composta apenas de sites estáticos – isso
é, sites que apenas mostravam documentos estáticos, como textos e imagens.
Como a idéia era apenas mostrar conteúdo, a preocupação sobre a segurança
desses sistemas envolvia apenas os aspectos como a segurança do servidor web
(ex. Versões de apache vulneráveis a exploits), ou segurança da infra-estrutura.
Quando um site assim era hackeado, dificilmente o atacante teria acesso a
 11

informações privadas, tendo em vista que a maioria da informação ali já era pública,
sendo essas o próprio conteúdo do site.
A internet de atualmente é realmente muito diferente do que ela era nos seus
primórdios [7]. Hoje, sites são, em sua maioria, aplicações. Temos registro de
contas, autenticação, transações bancárias, conversas privadas etc. O conteúdo
apresentado a cada usuário é, em sua maioria, particular e individual. Naturalmente,
muita dessa informação é altamente sensível, o que resulta em uma (ou, pelo
menos, deveria resutar em) grande preocupação com segurança.

Figura 1 - Exemplo de Web Site atual

Websites e aplicativos são usados para fins diversos. Alguns exemplos:

• Compras (Aliexpress, Amazon, MercadoLivre)
• Redes Sociais (Instagram, Facebook)
• Mensagens Instantâneas (Whatsapp, Messenger, Telegram)
• Bancos (Nubank, Itau)
• E-mail (gmail)
• Conhecimento (Wikipedia)
• Notícias (G1, Estadão, BBC)
 12

Embora organizações proclamem seus sistemas como seguros, Stuttard et al

[7], após testarem centenas e centenas de aplicações web, dizem que, na
verdade, a grande maioria dessas aplicações são inseguras. A seguir algumas
estatísticas sobre as vulnerabilidades mais comuns que eles encontraram, com
suas respectivas percentagem de ocorrência:
• Falhas na autenticação (62%): Categoria que enquadra falhas como no
mecanismo de autenticação, que consegue permitir um atacante de
descobrir senhas inseguras, lançar ataques de força bruta e até passar
por cima do login;
• SQL Injection (32%): Vulnerabilidade que permite um atacante de inserir
inputs modificados causando interferência na comunicação entre o back-
end da aplicação e o banco de dados.
• XSS (Cross-Site Scripting) (94%): Vulnerabilidade que permite um
atacante de inserir scripts no site, potencialmente malígnos, de modo
permanente ou não, fazendo tais scripts serem interpretados e executados
pelos navegadores dos usuários-álvos.

Esses tópicos serão discutidos mais profundamente nas próximas seções.

Figura 2 - Distribuição das vulnerabilidades encontradas por Stuttard et al [7]

A partir desse contexto, pode-se prosseguir com o principal fator de

insegurança da Web: o usuário pode enviar dados arbitrários às aplicações.
 13

Já que a forma como o usuário irá usar do serviço é fora do controle da

organização, as aplicações devem assumir que todo dado enviado pelos seus
usuários é, potencialmente, malicioso. Disso, a aplicação deve dispor de
mecanismos que não permitem a criação e envio de entradas modificadas que
interferem com o funcionamento da aplicação.
O principal fator de insegurança da Web pode, naturalmente, se manifestar de
maneiras diferentes. A seguir, alguns exemplos:
• Usuários podem interceptar tudo que é enviado ao servidor da
aplicação, podendo, inclusive, modificar os dados como bem quiser;
• Usuários podem enviar requisições em intervalos de tempo que eles
próprios determinam;
• Usuários não necessariamente irão interagir com a aplicação usando
um navegador popular.

Alguns exemplos de potenciais ataques podem ser:

• Quando se modifica a legenda de uma foto em uma rede social, a
requisição HTTP contém a ID da foto. Se se é modificado, na
requisição, a ID da foto pra a de outra foto, de outro usuário, pode-se
mudar a legenda da foto que possui essa ID desse outro usuário;
• Quando um texto é inserido em um campo de texto (ex. Um comentário
em uma foto) de uma rede social, se são inseridos trechos de código
JavaScript, o navegador pode não reconhecer o trecho como um texto
mas sim como um script do próprio site;
• Pegar a requisição enviada ao servidor quando se é enviada uma
mensagem numa plataforma de mensagens instantânea, criar um
programa que envia a mesma requisição 1 milhão de vezes;
• Na requisição HTTP, mudar os preços dos produtos que são
comprados num site de e-commerce se é feito o checkout, podendo
comprar, assim, produtos com preços menores;
• Alterar alguma parte da entrada que será usada na comunicação com
um banco de dados (ex. Uma busca, onde a string buscada será parte
de uma query).
 14

Os exemplos acima são comuns e, de um modo geral, resolvidos pela maioria

dos frameworks web – isso é, ferramentas de criação de aplicações web. Por outro
lado, muitos dos desenvolvedores sequer consideram esses problemas quando
estão criando suas aplicações.
Evidência sobre o estado de arte atual de segurança de aplicações web indica
que, enquanto alguns aspectos de segurança foram realmente melhorados, novos
problemas surgiram mudando completamente o cenário. De um modo geral, ataques
contra aplicações web continuam a apresentar um problema grave tanto para as
organizações que criam tais sistemas, quanto a seus usuários.

2.2. O Protocolo HTTP

O protocolo HTTP (do inglês “HyperText Transfer Protocol”) é um protocolo de
aplicação. É o principal protocolo usado para comunicação na internet. Foi criado
inicialmente para transferência de arquivos estáticos HTML, porém foi desenvolvido
de tal modo a suportar uma gama de aplicações mais complexas – inclusive as da
Web moderna. [10]
O HTTP usa uma forma de modelo baseado em mensagens, onde um cliente
envia uma mensagem (request) e o servidor responde com outra mensagem
(response). A seguir, um exemplo de request HTTP:

GET /~jlgm/hello.html HTTP/1.1

User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.cin.ufpe.br
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

Cada uma dessas linhas representam algum significado, e descrever cada um

dos verbos e demais linhas fogem do escopo desse trabalho. A primeira linha,
porém, é importante, e portanto ela será descrita:
• O GET indica o método HTTP que está sendo usado. De modo geral, GET
indica que o request tem objetivo de obter dados. Outros métodos são
POST (inserir dado), PUT (atualiza), DELETE (remove), porém verbos
usados dessa forma são apenas boa prática, não obrigatórios.
• A URL a ser obtida. O caminho onde o arquivo que se deseja obter está.
 15

• A versão do HTTP sendo usada. Hoje em dia, a maioria dos browsers usa
versão 1.1 [7]
A outra linha importante é o Host. O Host é o endereço do domínio do servidor
que possui o arquivo que se deseja obter.
Como descrito acima, a comunicação envolve um request e uma response.
Descevemos o primeiro, agora iremos ilustrar como é segundo:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
Content-Length: 88
Content-Type: text/html
Connection: Closed
<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

Novamente, descrever cada uma dessas linhas foge do escopo desse trabalho.
Devemos apenas nos atentar a primeira linha (que diz a versão do HTTP usada e o
status da comunicação, no exemplo acima indicando que a comunicação foi bem
sucedida). A linha que começa com <html> é o começo do arquivo HTML em si, o
que, como já foi dito em seções anteriores, pode ser interpretado pelo navegador do
usuário.
Todo teste de penetração em aplicações Web envolve analisar a fundo essa
comunicação – a troca de requests e responses. Como modificações nos requests
mudam as respostas dos servidores, o que o servidor se permite receber e
interpretar etc. O apêndice A desse trabalho irá demonstrar o uso de ferramentas
que auxiliam nesse esforço. Como se pode perceber, entender o protocolo HTTP é
extremamente importante para um pesquisador interessado em programas de Bug
Bounty.

2.3. Mapeando Aplicações

A partir dessa seção, iniciar-se-á o estudo de técnicas comuns utilizadas por
analistas participantes de programas de bug bounty e analistas de segurança de
aplicações web.
 16

O ponto inicial de qualquer atacante – seja malígno ou caçador de

recompensas – é analisar a aplicação em busca de obter o máximo de informação
que seja possível no tempo que se deseja investir. O “mapeamento” da aplicação
envolve estudar suas funcionalidades, seus arquivos, seus protocolos, suas
tecnologias, seus pontos-de-acesso etc. [7]
Obter todos os pontos de uma aplicação pode ser uma tarefa complicada e
repetitiva. Por isso, o uso de ferramentas auxiliares se é fundamental. Por exemplo,
uma ferramenta que consegue fazer uma busca em largura nos links que encontra
dentro do domínio-alvo consegue criar uma lista significativa de pontos a serem
investigados. Ferramentas podem ser ainda mais complexas e utilizar até de
Inteligência Artificial para procurar por vulnerabilidades em pontos diversos, de modo
automatizado. [11]
A imagem a seguir ilustra um mapeamento da página https://www.cin.ufpe.br/,
feito de modo completamente automático com o uso a ferramenta Burp.

Figura 3 - Mapeamento do site do CIn UFPE

 17

Apenas a partir dessa imagem, já podemos, rapidamente, observar algumas

coisas:
• O site é supostamente feito em PHP;
• O arquivo busca.php supostamente recebe uma string, usa essa
string em alguma query e retorna os resultados da query na response;
• Há um diretório chamado /uploads, que supostamente mantém
arquivos que são enviados.

Exemplos de potencial problemas a serem encontrados apenas mapeando a

aplicação podem ser:
• Acesso a versões antigas de partes do projeto (ex. Pagina de
autenticação sem mecanismos de proteção contra força bruta
(captcha));
• Arquivos esquecidos, com potencial informação perigosa;
• Acesso a arquivos de testes, como uma página de upload ou versões
muito iniciais do projeto;
• Arquivos mortos gerados pelo framework utilizado, com zero
gerenciamento da equipe de desenvolvimento
• Arquivos de configuração com acesso negligenciado.

Ainda no processo de mapear a aplicação, é possível se procurar por

parâmetros omitidos do conhecimento público, mas que são utilizados comumente
por desenvolvedores. Como exemplo, muitos frameworks web possuem um
parâmetro debug=false como default, que, ao ser modificado, pode passar a
exibir informações privilegiadas e potencialmente sensíveis.
Há diversas e diversas técnicas de se mapear uma aplicação – e tudo é muito
dependente do que é a aplicação, de como e pra que ela é usada, de quais
tecnologias ela faz uso etc. O trabalho requer, portanto, muita criatividade.

2.4. Atacando Usuário(s)

Uma das principais formas de comprometer a segurança de uma aplicação é
quando esta permite ataques direcionados aos seus usuários. Nessa seção,
estudaremos algumas das vulnerabilidades que permitem tais práticas.
 18

Cross Site Scripting (XSS)

Como visto na seção 2.1, XSS é uma das vulnerabilidades mais comuns
existentes. Nos testes de Stuttard et al [7], 94% dos sites eram vulneráveis. Um
estudo da Symantec determinou que 84% das falhas reportadas em 2007 eram XSS
[12]. XSS ainda é muito popular nos dias de hoje [13].
A falha permite que atacantes injetem scripts (em geral, mas não limitado a,
JavaScript) nas páginas que serão vistas por outros usuários. Se o sistema é
vulnerável, o script, potencialmente malicioso, é executado pelo navegador do
usuário, muitas vezes sem o sequer conhecimento do mesmo.
Um exemplo comum é o XSS refletido. A URL de exemplo a seguir pode ilustrar
do que se trata:

http://sitequalquer.com/error.php?msg=”um%20erro%20aconteceu”

Aqui, para fins de ilustração, assume-se, i) o site é vulnerável a XSS e ii) que a
página acima irá renderizar a página com o texto “um erro aconteceu”.

Ao notar que a página encontra-se vulnerável, um atacante poderia criar a

seguinte URL:

http://sitequalquer.com/error.php?msg=”<script>alert(1)</script>”

Por a página ser vulnerável a XSS, um usuário, ao abrir a página acima, irá ser
surpreendido com a seguinte tela:

Figura 4 - Exemplo de XSS

O XSS persistido funciona de modo similar, mas ao invés de o ponto

vulnerável ser um parâmetro da URL, o ponto está em campo(s) de texto das
aplicações. Um exemplo seria um script similar ao acima sendo colocado como
 19

comentário numa foto em uma rede social vulnerável. O script seria executado por
todos que fossem visualizar a foto em questão.
Naturalmente, um ataque real envolveria a confecção de scripts mais
complexos, potencialmente acarretando alguma prática danosa – como envio de
informações privilegiadas (cookies de sessão, mensagens particulares etc.), ações
no site sem autorização e controle dos usuários (follow nas contas de redes sociais
do(s) atacante(s), envio de mensagens), mineração de criptomoedas e até worms –
programas que executam uma série de ações e depois replicam-se, enviando si
próprio a outros usuários.

Phishing

Phishing é a criação de páginas falsas, idênticas as originais, mas com os

campos de autenticação modificados de modo que os dados são enviados ao
atacante. O estudo do ataque é fora do escopo desse trabalho pois não se trata de
uma vulnerabilidade baseada em aplicações (é um ataque direto a vítima e se
baseia na falta de conhecimento da mesma), sendo portanto não reportável em
programas de bug bounty, porém é bastante relacionado com a prática descrita
acima (XSS), já que um ponto vulnerável pode permitir a confecção de scripts que
modificam completamente a página. Também é muito relacionado ao próximo tópico:
Open Redirect.

Open Redirect

Open redirect é uma falha simples, muitas vezes colocada propositalmente

nas aplicações web, mas que pode ser perigosa. Um exemplo de URL vulnerável a
open redirect seria:

http://sitequalquer.com/redir.php?msg=”http://google.com”

Se o site for vulnerável, a URL a seguir irá redirecionar ao site google.com.

Porém, e levando em conta o que foi dito acima sobre Phishing, um possível redirect
pode ser:

http://sitequalquer.com/redir.php?msg=”http://pagina-falsa.com”

Se a página é exatamente idêntica a página-alvo, pode ser difícil para um usuário

mediano perceber que está sendo vítima de um ataque.
 20

No geral, programas de bug bounty consideram open redirect uma falha de não
muito impacto.

2.5. Atacando Servidor(es)

Ataques a Servidores são, muitas vezes, os ataques mais perigosos que
podem acontecer. [7] De fato, ao atacar usuários, o dano causado é limitado àqueles
usuários que foram atacados. Atacando o servidor, por outro lado, significa um
ataque a todos os usuários, e a própria aplicação em si. Aqui serão discutidas
algumas das vulnerabilidades comuns que permitem um atacante de modificar o
funcionamento da aplicação e, por vezes, até obter total acesso aos servidores
dessas aplicações.

SQL Injection

SQL Injection, como o próprio nome sugere, é um ataque que tenta injetar
comandos SQL no banco de dados do servidor da aplicação. Para que isso seja
possível, um atacante precisa, via mapeamento da aplicação (seção 2.2), identificar
o tipo de banco de dados que é usado na aplicação, para, depois, inserir dados
confeccionados especificamente para tentar identificar a vulnerabilidade.
Imaginemos nosso site fictício sendo vulnerável a SQL Injection. Ele é feito em PHP
e usa PostgreSQL como banco de dados.
Agora pensemos em como é feita a autenticação nesse site. O usuário entra no
site e encontra a página de login. O usuário preenche os campos de autenticação,
estes que são enviados ao servidor no corpo do request HTTP. O servidor recebe as
credenciais e verifica no banco de dados se a senha informada é a que foi
cadastrada para esse usuário. Para fins de simplicidade, vamos assumir que nosso
site fictício armazena as senhas em plain text (o que, diga-se, é uma
vulnerabilidade).
Uma possível query SQL para validar essa autenticação seria:

SELECT * FROM users WHERE username = ‘$USER’ AND password = ‘$PASSWORD’

Se o retorno dessa query não é vazio, significa que o usuário passou as

credenciais corretas, portanto ele pode se autenticar. Se é vazio, alguma coisa está
errado, portanto um erro é retornado. Assumimos aqui que $USER e $PASSWORD
 21

são exatamente as credenciais informadas pelo usuário – nota: em um sistema não

vulnerável, essas entradas são validadas antes de serem passadas ao banco de
dados. O que acontece se no campo $USER a seguinte string for enviada: admin’--’
? A query será criada da seguinte forma:

SELECT * FROM users WHERE username = ‘admin’--’ AND password = ‘123’;

Em SQL e outros banco de dados, -- significa o início de um comentário. A query

acima apenas verifica se há um usuário ‘admin’ e comenta o resto da query. Se o
sistema funciona como descrito aqui, a query acima irá eliminar a necessidade de
um password válido e o atacante irá logar como administrador.
A prática acima é o funcionamento básico de um SQL Injection. Naturalmente, o
poder de um atacante a essa altura é imensurável. Uma query modificada pode até
conter comandos como drop database, que deletaria todo o banco,
comprometendo todo o funcionamento da aplicação.

Figura 5 - Exploits of a mom (fonte: XKCD)

Remote Code Execution

Finalizando a seção de ataques ao servidor, será discutido brevemente a

falha de possivelmente maior impacto para qualquer aplicação web: a execução de
código remoto (ou “RCE”, do inglês “Remote Code Execution”). De um modo geral, a
falha permite a execução de comandos de sistema no servidor da aplicação.
Diversas linguagens de back-end – exemplos são PHP, Java, C++, Python,
ASP, Go - permitem a execução de scripts de sistema [12].
Descrever-se-á aqui um cenário possível que ajudará a entender tanto como a
falha é explorada quanto o impacto que esta pode trazer para uma aplicação. O
 22

sistema fictício em questão, um site institucional, feito em ASP, possui uma página
de Relatar Um Problema:

/relatar_problema.asp

Nessa pagina, o usuário pode enviar uma mensagem à equipe de suporte do

nosso site, com informações sobre o problema, incluindo uma foto.
Supõe-se que, no processo de mapeamento da aplicação, um atacante
descobriu um diretório chamado /uploads. Realizando experimentos, o atacante
descobriu que a imagem que foi enviada no formulário de Relatar um Problema
encontrava-se nesse diretório, e que ele conseguia acessar a imagem que ele
próprio enviou.
Curioso, o atacante decide enviar uma página ASP no formulário onde
supostamente ele enviaria uma imagem. Para sua surpresa, o arquivo .asp também
vai para o diretório de /uploads e, pior, ao abrir o arquivo, o site executa os
comandos ASP do arquivo criado. O atacante acaba de descobrir um RCE.
Em [12], temos exemplos de web shells em ASP. O atacante pode pegar uma
dessas ou criar sua própria shell, enviar a partir desse formulário e abrir o arquivo
pelo navegador. Ele terá um acesso a shell do servidor da aplicação (com o mesmo
acesso do usuário www), o que irá permitir acesso total a a aplicação – de visualizar
arquivos de configuração com informações de conexão com o banco de dados a
desligar a máquina onde o servidor está hospedado.
Falhas do tipo RCE, se encontradas via programas de bug bounty, são
premiadas com os valores mais altos, chegando a mais de $40000 dólares [13].
Também é comum falhas assim serem vendidas no “mercado negro” por preços
extremamente altos.

2.6. Metodologia hacker: um checklist

A seguir, uma lista de itens que podem ser investigados por um pesquisador
de segurança praticando um teste para uma organização que implementa
programas de bug bounty. O Checklist é baseado nos trabalhos de [7] e também
na lista de boas práticas da OWASP [24]:

1. Mapear a aplicação
 23

a. Explorar conteúdo visível

b. Descobrir conteúdo escondido
c. Testar parâmetros de debug
2. Analisar aplicação
a. Identificar funcionalidades
b. Identificar pontos de inserção de dados
c. Identificar as tecnologias usadas
3. Testar controles do front-end
a. Verificar como dados são validados (ex. Validação de CPF feita
no cliente ou no servidor?)
b. Verificar como aplicação se comporta em diferentes
navegadores
4. Testar autenticação
a. Testar se aplicação permite senhas fracas
b. Testar se é possível enumerar nomes de usuários (ex. Usuários
existentes o erro é “senha errada” e usuários não existentes o
erro é “usuário não encontrado”)
c. Testar as funções de recuperação de senha
d. Estudar a funcionalidade “lembrar de mim”
e. Testar se o sistema exige um captcha após tentativas falha de
autenticação
5. Testar os mecanismos de gerenciamento de sessão
a. Estudar a geração de tokens
b. Estudar o término de sessão
c. Estudar se sessões são únicas
d. Estudar o escopo do cookie de sessão
6. Testar vulnerabilidades baseadas em input
a. Testar SQL Injection
b. Testar XSS
c. Testar injeção de comandos do sistema
d. Testar File Inclusion
7. Testar por falhas na lógica da aplicação
8. Testar vulnerabilidades no servidor
a. Estudar versão de servidor web
 24

b. Estudar versão de outros servidores

9. Pensar fora da caixa e ser criativo

3. PROGRAMAS DE CAÇA AOS BUGS

3.1. Definição
Programas de caça aos bugs (ou programas de recompensas de bugs) são
programas que incentivam pesquisadores de segurança a procurar por falhas de
segurança em sistemas, onde as organizações responsáveis os recompensam
com prêmios e reconhecimento. [16] A partir de tais programas, organizações
conseguem resolver problemas relacionados a segurança antes desses se
tornarem conhecimento público.
Em 2013, um estudante chamado Khalil [17] encontrou uma vulnerabilidade
no Facebook que permitia a um usuário postar no mural de qualquer outro
usuário. Ao reportar a vulnerabilidade e ver esta ignorada, o estudante decidiu
explorar a falha e postou no mural do próprio criador do site, Mark Zuckerberg,
atraindo bastante atenção pra si e para a problemática. A partir daí, o facebook
melhorou bastante seu programa de bug bounty [18]. Mais detalhes sobre esse
programa serão discutidos no capítulo 4.
Desde então, os programas de bug bounty passaram de novidade para ser
usado pela maioria das organizações voltadas para web. O número de empresas
usando programas de bug bounty cresceu de modo a se tornar uma tendência,
ganhando momento nos anos recentes. [16].

3.2. Manutenção de Vulnerabilidades

Manutenção de vulnerabilidades é um aspecto bastante importante no papel
de encontrar vulnerabilidades em um ambiente, ao priorizar o risco, impacto, e
melhorando a postura geral dos times em relação a tais problemas [16].
Por definição, vulnerabilidade é “uma fraqueza no software ou hardware que
permite o uso de um produto ir além de seu design e potencialmente trazer efeito
negativo no software, sistema ou dados [15]. Uma vulnerabilidade explorada com
fins maliciosos pode resultar na não disponibilidade do sistema a seus usuários,
 25

o que é crítico para corporações, especialmente àquelas que possuem grande

parte de seus recursos associados a negócios online.
Vulnerabilidade, portanto, um fator de risco. Pubal [16] menciona uma fórmula
que relaciona a chance de um agente de risco explorar uma vulnerabilidade e
seu consequente impacto na aplicação:

Figura 6 - fórmula relacionando risco e vulnerabilidade

Manutenção de vulnerabilidades seria, nesse cenário, a prática cíclica de

identificar, classificar, remediar e mitigar vulnerabilidades [16]. Tipicamente, uma
organização dispõe de atividades como:
• Análise de infraestrutura
• Revisão de código
• Testes de Penetração

Os dois primeiros itens são, normalmente, feitos internamente na

organização, enquanto o terceiro item é o mais comumente terceirizado via
programas de bug bounty.

3.3. Divulgação das Vulnerabilidades

Divulgações de vulnerabilidades ocorrem diariamente [16]. Existem
plataformas especificamente para isso – exemplo: www.cvedetails.com, site que
organiza vulnerabilidades por impacto, produtos, vendors etc. O simples fato de
uma aplicação utilizar de produtos listados nesse site como vulneráveis já é
perigoso o suficiente, uma vez que isso ilustra negligenciamento por parte dos
desenvolvedores, tendo em vista que a falha em questão já é conhecimento
público. Sites como www.metasploit.com oferecem ferramentas que ajudam no
compartilhamento de informações a respeito de vulnerabilidades.
Empresas têm cada vez mais percebido que um sistema para divulgação de
vulnerabilidades é essencial [14]. Sem ser claramente definido um mecanismo
para tal prática, pesquisadores podem, muitas vezes, ficarem incertos do que
 26

deve ser feito no momento que eles encontram uma vulnerabilidade. Mandar por
e-mail pode ser sub-ótimo, uma vez que um funcionário de suporte ao usuário
pode, muitas vezes, não compreender o e-mail e simplesmente ignorá-lo. Quanto
ao que um pesquisador poderá fazer quando encontra uma falha, depende
totalmente de suas motivações – e um programa de bug bounty surge
exatamente para dar motivações.
A imagem a seguir ilustra uma possível interação entre manutenção de
vulnerabildiades e divulgação:

Figura 7 - Interação entre manutenção e divulgação de vulnerabilidades. Fonte: “IOS/IEC 29147:2014.”

3.4. Benefícios
A tabela a seguir irá comparar o programa de bug bounty com as práticas
comuns adotadas antes da prática se popularizar, como ter um time externo
(ou interno) para realizar testes de penetração.
 27

Teste de Penetração Bug Bounty

Tempo Em geral, duas semanas Não tem tempo definido. Um
pesquisador pode demorar o
tempo que precisar.
Pessoal Dependendo do escopo, 1 ou Não há pessoal contratado.
2 pessoas. Pode-se ter várias ou
nenhuma pessoa trabalhando
em um dado momento.
Custo Dependendo da empresa, Pesquisadores são pagos
mas estimado em $20k apenas se encontram alguma
dólares coisa, e os valores são
definidos pela própria
organização

Um estudo do HackerOne [20] descreve como empresas enconomizaram um

total de US$ 1.6mi ao adotar práticas de bug bounty ao invés de times de teste
de penetração.
Uma empresa realmente preocupada com segurança (exemplo: um sistema
bancário) pode, porém, usar ambos os lados e dispor de tanto um time de
segurança próprio como também promover um sistema de bug bounty. Acredita-
se que essa prática seja a que traz melhores resultados [16].

3.5. Incentivos
Os incentivos (ou motivações) para os pesquisadores são, de forma geral:
• Monetário: pesquisadores podem ganhar grandes quantias de dinheiro
por achar vulnerabilidades (quanto mais grave, mais alto o valor
recebido)
• Prêmios: itens físicos que trazem grande reconhecimento e realização
para os pesquisadores. Pode ser camisas, bonés, cartões
personalizados etc.
• Reconhecimento: programas de bug bounty no geral dispõem uma lista
de agradecimentos aos pesquisadores que até o momento
contribuiram com a melhoria da segurança do site. Exemplo:
facebook.com/whitehat/thanks
 28

Figura 8 - Exemplo de cartão personalizado a caçadores de

bugs do Facebook
 29

4. EXEMPLOS DE PROGRAMAS
A seção irá mostrar alguns programas populares de bug bounty – algumas
plataformas específicas, como HackerOne e BugCrowd, e também programas
implementados em gigantes como Google e Facebook.

4.1. Hacker One

Hackerone é uma plataforma de vulnerabilidades e bug bounty que conecta
negócios com uma comunidade de pesquisadores de segurança. Foi, juntamente
com BugCrowd (seção 4.2), uma das primeiras empresas a utilizar e implementar
serviços terceirizados de programas de segurança. Atualmente, é a maior empresa
com esse tipo de negócio.
Um estudo da própria companhia [20] descreve como companhias já salvaram
milhões de dólares ao utilizar de seus serviços de caça aos bugs em oposição aos
tradicionais times de testes de penetração.
Até o fim de 2018, a plataforma já possuia mais de 290,000 pesquisadores, já
resolveu, com a ajuda desses, mais de 88,000 vulnerabilidades em mais de 1,200
programas diferentes. A plataforma também já pagou mais de $40mi em
recompensas. [20]

4.2. Bug Crowd

BugCrowd se define como a #1 plataforma de terceirização de programas de
segurança. A idéia é um pouco diferente do HackerOne, no sentido de que lá se
é, normalmente, criado todo um time para analisar as aplicações. Como o próprio
fundador da empresa, Casey Ellis, descreve: “Segurança cibernética não é um
problema de tecnologia - mas sim um problema humano -, e para competir com
um exército de adversários, nós precisamos de um exército de aliados.”
Com isso em mente, a empresa dispõe de três soluções principais, a saber:
• Divulgação de vulnerabilidades: Feedback sobre questões de
segurança;
• Bug Bounty: Cria competição entre pesquisadores. Quanto maior o
impacto das vulnerabilidades, maiores as recompensas;
• Bug Bash: Colocar seu time pessoal de segurança pra trabalhar junto
com o grupo de pesquisadores do Bug Crowd.
 30

4.3. Facebook WhiteHat

Programa de Bug Bounty do Facebook, cujo escopo vai para praticamente
todos os principais produtos da companhia – exemplos são Facebook, Instagram,
Oculus, Whatsapp, Internet.org etc. O programa foi lançado em Julho de 2011 e
tem sido melhorado constantemente desde então.
A página www.facebook.com/whitehat/info possui toda a documentação com
regras, escopos e sugestões de abordagem para o sucesso no programa.

4.4. Google Bug Hunter Program

Programa de Bug Bounty do Google. De acordo com [23], em 2018 o Google
pagou cerca de $1.7mi a pesquisadores de segurança que encontraram falhas
no Android e no Chrome. O programa foi iniciado em 2010 e as recompensas já
dadas variam de $100 a $200,000 (dólares). No total, de acordo com [23], o
Google já pagou cerca de $15mi desde que o programa foi criado.
A imagem a seguir mostra um Hall of Fame, ou rank, dos pesquisadores que
mais contribuiram com a plataforma:

Figura 9 - Hall of fame do programa de bug bounty do Google

 31

4.5. Resumo comparativo entre as plataformas

Hacker One Bug Crowd Facebook Google

Proposta Ser a maior Conectar Descobrir Descobrir

plataforma de pesquisadores falhas em falhas nos
bug bounty do de segurança e sistemas do sistemas do
mundo empresas Facebook Google
interessadas (Instagram,
em testes de WhatsApp etc.)
penetração
Total já $11mi [20] (informação $7.5mi [25] $15mi [23]
premiado não
encontrada)
Falhas 88000 [20] (informação 17800 (em (informação
reportadas não 2018) [25] não
encontrada) encontrada)
 32

5. CONCLUSÃO
O presente trabalho discutiu, de modo breve, porém conciso e abrangente, como
funcionam os programas de Bug Bounty. O trabalho cobriu uma série de conceitos
básicos relacionados ao que um pesquisador de segurança deve ter conhecimento e
onde há as falhas mais comuns e mais graves.
O trabalho também analisou aspectos como custos, benefícios, incentivos e
comparou como programas de caça aos bugs se comportam em relação aos
tradicionais times dedicados a testes de penetração.
Por fim, o trabalho falou sobre algumas plataformas conhecidas e com boa
reputação da comunidade de pesquisadores de segurança.

5.1. Contribuições
A principal contribuição desse trabalho está no estudo e análise dos bug bounties
– seus benefícios, custos, como são implementados. Adicionalmente, o trabalho traz
um background de vulnerabilidades comuns porém, muitas vezes, negligenciadas,
podendo ser, assim, utilizado como referência para o desenvolvedor de aplicações
que procura criar sistemas mais seguros.

5.2. Dificuldades Encontradas

O estudo de implementação de programas de bug bounty pode ser difícil. Muitas
das informações não são públicas, pois o assunto é de tema delicado, e muitas
empresas ainda acreditam que incentivar pessoas a hackearem seus sistemas pode
ser uma “faca de dois gumes”. Por isso, muitas preferem se manter tradicionais e
apenas ter um time dedicado de analistas de segurança.
Adicionalmente, estudar os custos e economia pós implementação de programas
bug bounty requer informação que muitas empresas não tornam pública, o que
dificulta a comparação.

5.3. Trabalhos Futuros

Uma possível continuação desse trabalho poderia ser uma real implementação
de um programa bug bounty em nossos sistemas internos. Uma pesquisa mais
aprofundada nos custos comparativos de manter analistas vs utilizar de apenas
programas de caça aos bugs também agregaria ao que aqui foi discutido.
 33

REFERÊNCIA BIBLIOGRÁFICA

[1] "The Hacker-Powered Security Report - Who are Hackers and Why Do They
Hack p. 23" (PDF). HackerOne. 2017. Acessado em Março de 2019.

[2] "Facebook Bug Bounty 2017 Highlights: $880,000 Paid to Researchers".

Facebook. 11 January 2018. Acessado em Março de 2019.

[3] Erin Winick. "Life as a bug bounty hunter: a struggle every day, just to get paid".
www.technologyreview.com/s/611896/life-as-a-bug-bounty-hunter. Acessado em
Março de 2019.

[4] "The Pentagon Opened up to Hackers - And Fixed Thousands of Bugs". Wired.
10 November 2017. Acessado em Março de 2019.

[5] Julia R. Livingston. "Are Bug Bounty Programs Worth It?". www.pbwt.com/data-
security-law-blog/are-bug-bounty-programs-worth-it. Acessado em Março de 2019.

[6] "Facebook Bug Bounty 2017 Highlights: $880,000 Paid to Researchers".

Facebook. www.facebook.com/notes/facebook-bug-bounty/2017-highlights-880000-
paid-to-researc hers/1918340204846863. 11 de Janeiro de 2018. Acessado em
Março de 2019.

[7] Dafydd Stuttard; Marcus Pinto. “The Web Application Hackers’ Handbook”. 2nd
Edition. Wiley Publishing, Inc. p. 37. ISBN: 978-1-118-02647-2.

[8] "What is the difference between the Web and the Internet?". W3C Help and FAQ.
W3C. 2009. Archived from the original on 9 July 2015. Acessado em Junho de 2019.

[9] Joseph Adamski; Kathy Finnegan (2007). New Perspectives on Microsoft Office
Access 2007, Comprehensive. Cengage Learning. p. 390. ISBN 978-1-4239-0589-9.

[10] Fielding, Roy T.; Gettys, James; Mogul, Jeffrey C.; Nielsen, Henrik Frystyk;
Masinter, Larry; Leach, Paul J.; Berners-Lee, Tim (June 1999). “Hypertext Transfer
Protocol – HTTP/1.1.” IETF. doi:10.17487/RFC2616. RFC 2616.

[11] Steve Kommrusch. “Artificial Intelligence Techniques for Security Vulnerability

Prevention”. http://www.cs.colostate.edu/~steveko/wp/projects/VulnAI.pdf. Colorado
State University, 2018

[12] “Various WebShells”. BlackArch. https://github.com/BlackArch/webshells. Acessado

em Junho de 2019.

[13] “FACEBOOK’S IMAGETRAGICK STORY”. ANDREY LEONOV.

https://4lemon.ru/2017-01-17_facebook_imagetragick_remote_code_execution.html.
Acessado em Junho de 2019.
 34

[14] Matthew Finifter, Devdatta Akhawe, and David Wagner. “An Empirical Study of
Vulnerability Rewards Programs”.
https://www.usenix.org/system/files/conference/usenixsecurity13/sec13-
paper_finifter.pdf. Acessado em Junho de 2019.

[15] Aron Laszka, Mingyi Zhao, Akash Malbari, Jens Grossklags . “The Rules of
Engagement for Bug Bounty Programs”. https://fc18.ifca.ai/preproceedings/105.pdf.
Acessado em Junho de 2019.

[16] Jason Pubal. “Bug Bounty Programs: Enterprise Implementation”.

https://www.sans.org/reading-room/whitepapers/application/paper/38250. Acessado
em Junho de 2019.

[17] Joshua Gardner. “Computer expert hacks into Mark Zuckerberg's Facebook
page to expose the site's vulnerability after his security warnings were dismissed”.
https://www.dailymail.co.uk/news/article-2396628/Mark-Zuckerbergs-Facebook-
page-hacked-Khalil-Shreateh-expose-site-vulnerability.html. Acessado em Junho de
2019.

[18] “Facebook White Hat program”. https://www.facebook.com/whitehat. Acessado

em Junho de 2019.

[19] “Given enough eyeballs, all bugs are shallow? Revisiting Eric Raymond with bug
bounty programs”. https://arxiv.org/abs/1608.03445. Acessado em Junho de 2019.

[20] “The Total Economic Impact™ Of HackerOne Challenge”.

https://www.hackerone.com/resources/forrester-total-economic-impact-study-
hackerone. Acessado em Julho de 2019.

[21] “HackerOne: PRESS KIT & FAQ”.

https://www.hackerone.com/sites/default/files/2018-03/HackerOne_Press_Kit.pdf.
Acessado em Maio de 2019

[22] David Chou. “BugCrowd: Inside the Mind of a Hacker”. 2019.

https://www.bugcrowd.com/resources/guides/inside-the-mind-of-a-hacker-2019/.
Acessado em Julho de 2019.

[23] Steve Ranger. “Android and Chrome bug bounty: Google reveals how much it
paid out in 2018”. https://www.zdnet.com/article/android-and-chrome-bug-bounty-
google-reveals-how-much-it-paid-out-in-2018/. Acessado em Junho de 2019

[24] “OWASP Secure Coding Practices Checklist”.

https://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_Checklist.
Acessado em: Julho de 2019.

[25] “A Look Back at our Bug Bounty Program in 2018”.

https://www.facebook.com/notes/facebook-bug-bounty/a-look-back-at-our-bug-
bounty-program-in-2018/2373713379309541/. Acessado em: Julho de 2019.
35