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 ............................................................................................................... 4RESUMO .................................................................................................................................. 5ABSTRACT .............................................................................................................................. 6SUMÁRIO ................................................................................................................................. 71. INTRODUÇÃO ................................................................................................................. 81.1. CONTEXTUALIZAÇÃOEMOTIVAÇÃO...............................................................................................................81.2. OBJETIVOS............................................................................................................................................................81.3. ESTRUTURADODOCUMENTO...........................................................................................................................9

2. REFERENCIAL TEÓRICO ............................................................................................. 102.1. AWEBESUA(IN)SEGURANÇA......................................................................................................................102.2. OPROTOCOLOHTTP.....................................................................................................................................142.3. MAPEANDOAPLICAÇÕES................................................................................................................................152.4. ATACANDOUSUÁRIO(S).................................................................................................................................17CrossSiteScripting(XSS)........................................................................................................................................18Phishing...........................................................................................................................................................................19OpenRedirect................................................................................................................................................................19

2.5. ATACANDOSERVIDOR(ES)............................................................................................................................20SQLInjection.................................................................................................................................................................20RemoteCodeExecution............................................................................................................................................21

2.6. METODOLOGIAHACKER:UMCHECKLIST.....................................................................................................22

3. PROGRAMAS DE CAÇA AOS BUGS .......................................................................... 243.1. DEFINIÇÃO........................................................................................................................................................243.2. MANUTENÇÃODEVULNERABILIDADES.......................................................................................................243.3. DIVULGAÇÃODASVULNERABILIDADES.......................................................................................................253.4. BENEFÍCIOS.......................................................................................................................................................263.5. INCENTIVOS......................................................................................................................................................27

4. EXEMPLOS DE PROGRAMAS ..................................................................................... 294.1. HACKERONE....................................................................................................................................................294.2. BUGCROWD......................................................................................................................................................294.3. FACEBOOKWHITEHAT..................................................................................................................................304.4. GOOGLEBUGHUNTERPROGRAM.................................................................................................................30

5. CONCLUSÃO ................................................................................................................. 325.1. CONTRIBUIÇÕES...............................................................................................................................................325.2. DIFICULDADESENCONTRADAS.....................................................................................................................325.3. TRABALHOSFUTUROS....................................................................................................................................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:

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

Figura 4 - Exemplo de XSS

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 2 pessoas.

Não há pessoal contratado. Pode-se ter várias ou nenhuma pessoa trabalhando em um dado momento.

Custo Dependendo da empresa, mas estimado em $20k dólares

Pesquisadores são pagos apenas se encontram alguma 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 plataforma de bug bounty do

mundo

Conectar pesquisadores de segurança e

empresas interessadas em testes de penetração

Descobrir falhas em

sistemas do Facebook

(Instagram, WhatsApp etc.)

Descobrir falhas nos

sistemas do Google

Total já premiado

$11mi [20] (informação não

encontrada)

$7.5mi [25] $15mi [23]

Falhas reportadas

88000 [20] (informação não

encontrada)

17800 (em 2018) [25]

(informação não

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