Os programas de recompensas de bug teve um crescimento enorme durante os ultimos anos, aonde muitas organizações estão pagando para que pesquisadores de segurança achem vulnerabilidades em suas aplicações. E hoje os programas de bug bounty já ocasionaram em mais 100 milhões de dolares em recompensa para pesquisadores do mundo inteiro. Tornando alguns até mesmo milionários dessa forma.
Mas o que é necessário conhecer para entrar nesses programas?
O principal fator para um Bug Hunter é ser um pesquisador e conhecer de técnicas de exploração em aplicações web, além disso, entender como uma aplicação trabalha e principalmente conhecer de desenvolvimento. Afinal, entendo como uma aplicação trabalha, o seu comportamento e como é o desenvolvimento, você abre os horizontes na hora de procurar uma brecha de segurança, tanto de maneira estática como dinâmica.
Quais vulnerabilidades são bem comuns em programas de recompensa
Geralmente muitos programas se enquadram no OWASP-TOP 10 sobre vulnerabilidades web, porém alguns programas também elegem vulnerabilidades que não fazem parte ou não é bem detalhado no TOP-10. Além disso, as empresas analisam o impacto daquela vulnerabilidade até para ser elegivel para uma recompensa gorda.
Algumas vulnerabilidades mais comuns são:
- Cross Site Scripting (XSS)
- Cross Site Request Forgery (CSRF)
- SQL Injection
- Remote Command Execution (RCE)
- CRLF Injection
- Request Smuggling
- Privilege Escalation
- Open Redirect
- Broken Authentication – OAuth
- Server Side Request Forgery (SSRF)
- Insecure Direct Object Reference (IDOR)
- Domain Takeover
- User Account Takeover
- XML External Entity Injection (XXE)
- Clickjacking
- Path Transversal
- APIs inseguras
Essas são algumas das vulnerabilidades mais recorrentes, geralmente tem vulnerabilidades que abrem brechas para outras, como CSRF to XSS, XSS to SQLi, SQLi to RCE, LFI to XSS e etc, etc…
Em programas de Bug Bounty, pensar fora da caixa é a chave para conseguir encontrar uma vulnerabilidade, principalmente quando você conhece de desenvolvimento web e como funciona os mecanismos de proteção de uma aplicação web.
Como por exemplo:
- Filtros anti-xss
- Validadores de entrada de dados, White lists e “higienizadores”
- Caracteres de escape
- Web Application Firewall/IDS/IPS
- Desenvolvimento Seguro de aplicações web
- Monitoramento de Deserialização
- Métodos de encriptação de dados
- Multi-fator de autenticação
- Controles de acesso
- Tokens anti CSRF/XSFR
- Tokens e Cookies de sessão
- Politicas de segurança de conteúdos (CSP)
Entre outros métodos de prevenção.
Conhecer como os métodos de prevenção funcionam é uma das melhores formas para bypassa-los depois, principalmente quando você conhece de desenvolvimento seguro e entende como uma determinada aplicação web se comporta.
Quando falamos de alguns desses ataques, muitos deles são bem conhecidos como SQL Injection, assim muitos dúvidando que ainda exista alguma aplicação vulnerável. Mas infelizmente esse pensamento está errado e você pode encontrar muitos sites vulneráveis, por simplesmente a cultura de desenvolvimento seguro não ser algo maduro em muitas empresas. Principalmente quando falamos dos testes, aonde muitos ignoram quando um projeto está atrasado ou por não achar necessário porque a utilização é privada para poucas ou por acreditar que não será atacado.
Demonstração de ataques
E para colocar um pouco de prática no artigo, vou demonstrar alguns ataques usando o laboratório Metasploitable, aonde você pode baixar e brincar tanto atacando como prevenindo.
Download: https://sourceforge.net/projects/metasploitable/
Particularmente gosto do metasploitable tanto para brincar com ataques voltadas a aplicação e servidor, mas também para mitigar os riscos e tentar deixar a máquina mais segura o possível. Já fez esse teste? Quem sabe não role um artigo…
Enfim, para inicio vou demonstrar uns ataques de XSS, mas antes precisamos saber algumas definições. Vou tentar resumi-las.
O que é XSS?
Uma vulnerabilidade de XSS é a injeção de scripts maliciosos em campos de entradas de dados sem nenhuma validação ou forma de escape ou filtragem. Assim executandos scripts no navegador da vítima e permitindo tanto o roubo de dados, redirecionamentos maliciosos, sequestro de sessão e defacement.
Tipos de XSS
Vou tentar explicar de uma maneira bem simples…
Refletido: É quando não á uma validação de um dado transmitido (payload) inserido em um campo de entrada de dados e ai ocorre uma injeção de script. E com isso o servidor retorna para você aquele dado sem nenhum tipo de tratamento, ocasionando em um XSS. É necessário que a vítima interaja com o link malicioso.
Armazenado: É quando não á uma validação de um dado transmitido (payload), inserido em um campo de entrada e a aplicação acaba armazenando no servidor. Sendo diferente do refletido, aonde a aplicação apenas reflete na tela aquele dado inserido. No caso do armazenado, o servidor ele armazena e caso não seja validado da forma correta, ocasiona em um XSS persistente e não é necessário interação da vítima para que os impactos sejam ocasionados.
DOM: Ele já faz a modificação da estrutura da página, não explorando a resposta do servidor, mas sim o ambiente DOM da página e fazendo alterações maliciosas nela. Entender como um XSS DOM trabalha é chato no inicio, mas recomendo esses artigos:
https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A7-Cross-Site_Scripting_(XSS)
https://www.acunetix.com/blog/articles/dom-xss-explained/
https://tableless.com.br/entendendo-o-dom-document-object-model/
Exemplo Refletido:
Eu inserir um “ola” no campo de entrada que pede meu nome, assim me retornando via GET o resultado que pode ser observado na URL. Agora se esse campo de entrada não possuir uma validação correta? Isso pode ocasionar em um XSS, para esse teste eu vou inserir um payload (um dado) que executa um alert(document.cookie), assim retornando o cookie de navegação dessa página ou documento.
Payload:
<IMG src=1 onerror=alert(document.cookie)>
E veja o resultado que eu tenho na tela
Bingo! Eu conseguir executar um alert(document.cookie), pois o servidor não válidou corretamente a entrada desse dado e não jogou em nenhum escape para que não seja considerado um código e sim uma string comum.
Exemplo Armazenado:
Agora vamos para o XSS armazenado, mas no caso, será em cima de um campo de formulário de contato.
Eu inserir meu nome e uma mensagem e perceba que ele já armazenou isso no servidor. Agora basicamente, vou inserir um payload para ocasionar em um XSS.
Payload:
element[attribute='<img src=x onerror=alert('XSS');>
E vamos ver o resultado
Bingo! O servidor armazenou, porém ele não conseguiu validar de forma correta o trecho do payload <img src=x onerror=alert(‘XSS’);>
Vamos ver agora a vulnerabilidade SQL Injection
O que é SQL Injection?
O Ataque de Injeção de SQL, consiste em injetar comandos do banco de dados SQL para apagar, coletar ou modificar dados de um banco de dados, ocorrendo quando os dados fornecidos pelo usuário não é validado de forma correta e interpretado como uma forma de injeção de comandos SQL.
SQL Injection em banda: A injeção de SQL em banda ocorre quando um invasor pode usar o mesmo canal de comunicação para iniciar o ataque e coletar resultados. Então pelo mesmo parâmetro você pode efetuar o ataque e a coleta dos dados.
SQL Injection baseado em erros: O SQLi baseado em erro é uma técnica de injeção de SQL em banda que se baseia em mensagens de erro lançadas pelo servidor de banco de dados para obter informações sobre a estrutura do banco de dados. Em alguns casos, apenas a injeção de SQL baseada em erro é suficiente para um invasor enumerar um banco de dados inteiro.
Blind SQL Injection: Pode levar mais tempo para um invasor explorar, no entanto, é tão perigoso quanto qualquer outra forma de injeção de SQL. Em um ataque inferencial do SQLi, nenhum dado é realmente transferido pelo aplicativo Web e o invasor não seria capaz de ver o resultado de um ataque dentro da banda (e é por isso que esses ataques são geralmente chamados de ” ataques cegos de injeção de SQL “) . Em vez disso, um invasor é capaz de reconstruir a estrutura do banco de dados enviando cargas, observando a resposta do aplicativo Web e o comportamento resultante do servidor de banco de dados.
Caso queira saber mais sobre SQL Injection (https://www.acunetix.com/websitesecurity/sql-injection2/)
Exemplo:
Vamos utilizar a técnica classica de SQL Injection que é o SQL em banda
Para resumir, vou utilizar o seguinte passo a passo.
1) Vou adicionar uma aspas simples (‘) para verificar o comportamento da aplicação
Bingo! Retornou um erro de sintaxe no banco de dados, agora vamos brincar. Você pode utilizar o SQLMap ou fazer na mão, no caso vou na demonstrar uma consulta simples na mão e ai vocês podem brincar com SQLMap, deixarei os comandos abaixo.
2) Depois de testar ID por ID, digitando 1, 2, 3, vou tentar retornar todo banco de dados na tela inserindo o seguinte payload.
1' or '1' = '1
Em um resumo a grosso modo, eu disse para minha aplicação que 1 ou 1 é igual a 1, sendo assim, se isso for verdadeiro, ele me retorne o banco de dados inteiro na consulta, estranho, mas isso é um erro de desenvolvimento por falta de higienização.
3) Utilizando SQLMap
sqlmap -u "http://ipdoseumetasploitable/dvwa/vulnerabilities/sqli/?id='" sqlmap -u "http://ipdoseumetasploitable/dvwa/vulnerabilities/sqli/?id='" --dbs sqlmap -u "http://ipdoseumetasploitable/dvwa/vulnerabilities/sqli/?id='" -D dvwa --tables sqlmap -u "http://ipdoseumetasploitable/dvwa/vulnerabilities/sqli/?id='" -D dvwa -T users --columns sqlmap -u "http://ipdoseumetasploitable/dvwa/vulnerabilities/sqli/?id='" -D dvwa -T users -C user,password --dump
Primeiro passo eu testei se a aplicação é vulnerável, se não tem algum WAF ou IPS para barrar
No segundo passo eu listo todos os bancos de dados que a aplicação tem
O terceiro passo eu seleciono um banco de dados e verifico as tabelas existentes
Ai no quarto passo eu já seleciono o banco de dados e a tabela que eu quero verificar suas colunas
E no último passo eu já seleciono banco de dados, a tabela que eu quero verificar e a coluna para qual eu quero que ele retorne os dados dentro dela.
OBS: O SQLMap faz mais barulhos que furadeira as 06:00 da manhã, então não saia utilizando ela para fins maliciosos, pois se possuir um WAF bem configurado, você toma um bloqueio. Obviamente que você pode utilizar sintaxes para diminuir o barulho, mas é sempre legal fazer as coisas na mão.
E por último, vamos ver um ataque de CSRF
O que é CSRF?
A falsificação de solicitação entre sites (CSRF) é um ataque que força um usuário final a executar ações indesejadas em um aplicativo Web no qual eles estão atualmente autenticados. Os ataques CSRF visam especificamente solicitações de alteração de estado de alguma aplicação, seja a troca de alguma senha ou a mudança de configuração, mas não o roubo de dados, pois o invasor não tem como ver a resposta da solicitação forjada. Mas com uma pequena ajuda da engenharia social (como o envio de um link por email ou bate-papo), um invasor pode induzir os usuários de um aplicativo da Web a executar ações de sua escolha.
Exemplo:
Vou criar um formulário que faz a alteração de senha de uma aplicação, por intermédio de um outro servidor web.
Antes disso, eu preciso coletar os parâmetros da aplicação vulnerável, sendo pela analise do código fonte e pegando os elementos HTML do formulário.
Como teste, eu mudei a senha para “1” afim de verificar o comportamento da aplicação, notando que ele trabalha via método GET, assim eu montei um relatório visualizando “inspecionar o elemento” e confirmando se esta tudo correto pela resposta. Eu geralmente utilizo ferramentas para gerar automaticamente POCs de CSRF, basta eu coletar a requisição utilizando o Burp Suite e inserir a solicitação no gerador que ele me traz já o formulário pronto.
OBS: Mude o name=”Change”
<form action="http://ipdoseumetasploitable/dvwa/vulnerabilities/csrf/?password_new=&password_conf=&Change=Change" method="GET"> <input type="text" name="password_new"> <input type="text" name="password_conf"> <input type="submit" value="Change" name="Change"> </form>
Agora basta jogar isso em um servidor web, seja o Apache2 do seu Kali ou um XAMMP ou WAMP do Windows e realizar a requisição da nova senha.
Digitei a senha que eu quero, agora vou realizar a mudança clicando no botão “change”
Bingo! A senha de acesso do DVWA foi trocada, agora basta deslogar e logar com a nova senha.
Conclusão
Essa foi algumas demonstrações de ataques simples, usando um laboratório simples também, eu resolvir fazer um artigo prático para ser diferentes dos outros que costumo a escrever, pois é raro eu postar algo prático aqui no LinkedIn.
Enfim, caso você queira aprender ataques web, eu recomendo que você aprenda a desenvolver, principalmente para aprender a atacar e a construir seus laboratórios. Estude técnicas e métodos de exploração, veja writeups de pesquisadores e profissionais de Bug Bounty e pratique bastante. E claro, eu recomendo que você aprenda a utilizar a ferramenta de desenvolvedor dos navegadores, isso ajuda demais, não ache que só ferramentas vão trazer resultados consideráveis, mas se você se aprofundar mais em técnicas de invasão web, pode ter certeza que seu navegador se torna um aliado excepcional.
Algumas ferramentas bacanas que eu utilizo:
- Burp Suite
- cURL
- CSRF Poc Generator (https://github.com/merttasci/csrf-poc-generator)
- SubOver (https://github.com/Ice3man543/SubOver)
- Knock SubDomain (https://github.com/guelfoweb/knock)
- XSS Payloads (https://gist.github.com/rvrsh3ll/09a8b933291f9f98e8ec)
- SQL Injection Payloads (https://github.com/payloadbox/sql-injection-payload-list)
- Uma Trick de Recon bacana (https://www.linkedin.com/pulse/tricks-de-recon-ataide-junior/?trackingId=lo%2FwG4h%2FSemwGplcWrHIhA%3D%3D)
- Um servidor web para testes locais
- Uma lista de Writeups para abrir a mente um pouquinho (https://pentester.land/list-of-bug-bounty-writeups.html)
Alguns canais que podem ajudar:
https://www.youtube.com/channel/UCQN2DsjnYH60SFBIA6IkNwg (Stok)
https://www.youtube.com/channel/UCsgzmECky2Q9lQMWzDwMhYw (HackerOne)
https://www.youtube.com/channel/UCo1NHk_bgbAbDBc4JinrXww (BugCrowd)
https://www.youtube.com/channel/UCNRM4GH-SD85WCSqeSb4xUA (Bug Bounty Disclosure)
Autor
Views: 868
