mirror of https://github.com/carlospolop/hacktricks synced 2024-12-29 22:43:11 +00:00

Translator f9e7731a87 Translated ['c2/icmpsh.md', 'c2/salseo.md', 'generic-hacking/brute-force

2024-12-16 02:01:34 +00:00

33 KiB

Raw Blame History

80,443 - Metodologia de Pentesting Web

{% hint style="success" %} Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)

Suporte ao HackTricks

Confira os planos de assinatura!
Junte-se ao 💬 grupo do Discord ou ao grupo do telegram ou siga-nos no Twitter 🐦 @hacktricks_live.
Compartilhe truques de hacking enviando PRs para o HackTricks e HackTricks Cloud repositórios do github.

{% endhint %}

Obtenha a perspectiva de um hacker sobre seus aplicativos web, rede e nuvem

Encontre e relate vulnerabilidades críticas e exploráveis com impacto real nos negócios. Use nossas 20+ ferramentas personalizadas para mapear a superfície de ataque, encontrar problemas de segurança que permitem escalar privilégios e usar exploits automatizados para coletar evidências essenciais, transformando seu trabalho árduo em relatórios persuasivos.

{% embed url="https://pentest-tools.com/?utm_term=jul2024&utm_medium=link&utm_source=hacktricks&utm_campaign=spons" %}

Informações Básicas

O serviço web é o mais comum e extenso e muitos tipos diferentes de vulnerabilidades existem.

Porta padrão: 80 (HTTP), 443(HTTPS)

PORT    STATE SERVICE
80/tcp  open  http
443/tcp open  ssl/https

nc -v domain.com 80 # GET / HTTP/1.0
openssl s_client -connect domain.com:443 # GET / HTTP/1.0

Orientação para API Web

{% content-ref url="web-api-pentesting.md" %} web-api-pentesting.md {% endcontent-ref %}

Resumo da Metodologia

Nesta metodologia, vamos supor que você vai atacar um domínio (ou subdomínio) e apenas isso. Portanto, você deve aplicar esta metodologia a cada domínio, subdomínio ou IP descoberto com servidor web indeterminado dentro do escopo.

Comece identificando as tecnologias usadas pelo servidor web. Procure por truques para ter em mente durante o restante do teste se você conseguir identificar a tecnologia com sucesso.
Alguma vulnerabilidade conhecida da versão da tecnologia?
Usando alguma tecnologia bem conhecida? Algum truque útil para extrair mais informações?
Algum scanner especializado para rodar (como wpscan)?
Lance scanners de propósitos gerais. Você nunca sabe se eles vão encontrar algo ou se vão encontrar alguma informação interessante.
Comece com as verificações iniciais: robots, sitemap, erro 404 e varredura SSL/TLS (se HTTPS).
Comece a spiderar a página web: É hora de encontrar todos os possíveis arquivos, pastas e parâmetros sendo usados. Além disso, verifique por descobertas especiais.
Note que sempre que um novo diretório for descoberto durante brute-forcing ou spidering, ele deve ser spiderado.
Brute-Forcing de Diretórios: Tente forçar todos os diretórios descobertos em busca de novos arquivos e diretórios.
Note que sempre que um novo diretório for descoberto durante brute-forcing ou spidering, ele deve ser Brute-Forced.
Verificação de Backups: Teste se você consegue encontrar backups de arquivos descobertos adicionando extensões de backup comuns.
Parâmetros de Brute-Force: Tente encontrar parâmetros ocultos.
Uma vez que você tenha identificado todos os possíveis endpoints aceitando entrada do usuário, verifique todos os tipos de vulnerabilidades relacionadas a isso.
Siga esta lista de verificação

Versão do Servidor (Vulnerável?)

Identificar

Verifique se há vulnerabilidades conhecidas para a versão do servidor que está em execução.
Os cabeçalhos HTTP e cookies da resposta podem ser muito úteis para identificar as tecnologias e/ou versão sendo usadas. A varredura Nmap pode identificar a versão do servidor, mas também podem ser úteis as ferramentas whatweb, webtech ou https://builtwith.com/:

whatweb -a 1 <URL> #Stealthy
whatweb -a 3 <URL> #Aggresive
webtech -u <URL>
webanalyze -host https://google.com -crawl 2

Search for vulnerabilidades da versão da aplicação web

Verifique se há algum WAF

Truques de tecnologia web

Alguns truques para encontrar vulnerabilidades em diferentes tecnologias bem conhecidas que estão sendo usadas:

Tenha em mente que o mesmo domínio pode estar usando diferentes tecnologias em diferentes portas, pastas e subdomínios.
Se a aplicação web estiver usando alguma tecnologia/plataforma bem conhecida listada acima ou qualquer outra, não se esqueça de pesquisar na Internet novos truques (e me avise!).

Revisão de Código Fonte

Se o código fonte da aplicação estiver disponível no github, além de realizar por sua conta um teste de caixa branca da aplicação, há algumas informações que podem ser úteis para o atual teste de caixa preta:

Existe um arquivo de Change-log ou Readme ou Versão ou qualquer coisa com informações de versão acessíveis via web?
Como e onde são salvas as credenciais? Existe algum (acessível?) arquivo com credenciais (nomes de usuário ou senhas)?
As senhas estão em texto simples, criptografadas ou qual algoritmo de hash é usado?
Está usando alguma chave mestra para criptografar algo? Qual algoritmo é usado?
Você pode acessar algum desses arquivos explorando alguma vulnerabilidade?
Há alguma informação interessante no github (problemas resolvidos e não resolvidos)? Ou no histórico de commits (talvez alguma senha introduzida em um commit antigo)?

{% content-ref url="code-review-tools.md" %} code-review-tools.md {% endcontent-ref %}

Scanners automáticos

Scanners automáticos de propósito geral

nikto -h <URL>
whatweb -a 4 <URL>
wapiti -u <URL>
W3af
zaproxy #You can use an API
nuclei -ut && nuclei -target <URL>

# https://github.com/ignis-sec/puff (client side vulns fuzzer)
node puff.js -w ./wordlist-examples/xss.txt -u "http://www.xssgame.com/f/m4KKGHi2rVUN/?query=FUZZ"

Scanners de CMS

Se um CMS estiver em uso, não se esqueça de executar um scanner, talvez algo interessante seja encontrado:

Clusterd: JBoss, ColdFusion, WebLogic, Tomcat, Railo, Axis2, Glassfish
CMSScan: WordPress, Drupal, Joomla, vBulletin sites para questões de segurança. (GUI)
VulnX: Joomla, Wordpress, Drupal, PrestaShop, Opencart
CMSMap: (W)ordpress, (J)oomla, (D)rupal ou (M)oodle
droopscan: Drupal, Joomla, Moodle, Silverstripe, Wordpress

cmsmap [-f W] -F -d <URL>
wpscan --force update -e --url <URL>
joomscan --ec -u <URL>
joomlavs.rb #https://github.com/rastating/joomlavs

Neste ponto, você já deve ter algumas informações sobre o servidor web utilizado pelo cliente (se algum dado for fornecido) e algumas dicas para ter em mente durante o teste. Se você tiver sorte, pode até ter encontrado um CMS e executado algum scanner.

Descoberta de Aplicações Web Passo a Passo

A partir deste ponto, começaremos a interagir com a aplicação web.

Verificações Iniciais

Páginas padrão com informações interessantes:

/robots.txt
/sitemap.xml
/crossdomain.xml
/clientaccesspolicy.xml
/.well-known/
Verifique também os comentários nas páginas principais e secundárias.

Forçando erros

Servidores web podem comportar-se de maneira inesperada quando dados estranhos são enviados a eles. Isso pode abrir vulnerabilidades ou divulgar informações sensíveis.

Acesse páginas falsas como /whatever_fake.php (.aspx,.html,.etc)
Adicione "[]", "]]" e "[[" nos valores de cookie e valores de parâmetro para criar erros
Gere erro fornecendo entrada como /~randomthing/%s no final da URL
Tente diferentes Verbos HTTP como PATCH, DEBUG ou errados como FAKE

Verifique se você pode fazer upload de arquivos (verbo PUT, WebDav)

Se você descobrir que o WebDav está ativado, mas não tem permissões suficientes para fazer upload de arquivos na pasta raiz, tente:

Forçar Brute Force nas credenciais
Fazer upload de arquivos via WebDav para o resto das pastas encontradas dentro da página web. Você pode ter permissões para fazer upload de arquivos em outras pastas.

Vulnerabilidades SSL/TLS

Se a aplicação não estiver forçando o uso de HTTPS em nenhuma parte, então está vulnerável a MitM
Se a aplicação está enviando dados sensíveis (senhas) usando HTTP. Então é uma alta vulnerabilidade.

Use testssl.sh para verificar vulnerabilidades (Em programas de Bug Bounty, provavelmente esse tipo de vulnerabilidade não será aceito) e use a2sv para rechecagem das vulnerabilidades:

./testssl.sh [--htmlfile] 10.10.10.10:443
#Use the --htmlfile to save the output inside an htmlfile also

# You can also use other tools, by testssl.sh at this momment is the best one (I think)
sslscan <host:port>
sslyze --regular <ip:port>

Informações sobre vulnerabilidades SSL/TLS:

Spidering

Lance algum tipo de spider dentro da web. O objetivo do spider é encontrar o maior número possível de caminhos a partir da aplicação testada. Portanto, a exploração da web e fontes externas devem ser usadas para encontrar o maior número possível de caminhos válidos.

gospider (go): Spider HTML, LinkFinder em arquivos JS e fontes externas (Archive.org, CommonCrawl.org, VirusTotal.com, AlienVault.com).
hakrawler (go): Spider HML, com LinkFinder para arquivos JS e Archive.org como fonte externa.
dirhunt (python): Spider HTML, também indica "arquivos suculentos".
evine (go): Spider HTML interativo CLI. Também pesquisa no Archive.org.
meg (go): Esta ferramenta não é um spider, mas pode ser útil. Você pode apenas indicar um arquivo com hosts e um arquivo com caminhos e o meg buscará cada caminho em cada host e salvará a resposta.
urlgrab (go): Spider HTML com capacidades de renderização JS. No entanto, parece que não está sendo mantido, a versão pré-compilada é antiga e o código atual não compila.
gau (go): Spider HTML que usa provedores externos (wayback, otx, commoncrawl).
ParamSpider: Este script encontrará URLs com parâmetros e as listará.
galer (go): Spider HTML com capacidades de renderização JS.
LinkFinder (python): Spider HTML, com capacidades de embelezamento JS capaz de buscar novos caminhos em arquivos JS. Também pode valer a pena dar uma olhada no JSScanner, que é um wrapper do LinkFinder.
goLinkFinder (go): Para extrair endpoints tanto no código-fonte HTML quanto em arquivos javascript incorporados. Útil para caçadores de bugs, red teamers, ninjas de infosec.
JSParser (python2.7): Um script python 2.7 usando Tornado e JSBeautifier para analisar URLs relativas de arquivos JavaScript. Útil para descobrir facilmente requisições AJAX. Parece não estar sendo mantido.
relative-url-extractor (ruby): Dado um arquivo (HTML), ele extrairá URLs dele usando expressões regulares inteligentes para encontrar e extrair as URLs relativas de arquivos feios (minificados).
JSFScan (bash, várias ferramentas): Coletar informações interessantes de arquivos JS usando várias ferramentas.
subjs (go): Encontrar arquivos JS.
page-fetch (go): Carregar uma página em um navegador sem cabeça e imprimir todas as URLs carregadas para carregar a página.
Feroxbuster (rust): Ferramenta de descoberta de conteúdo misturando várias opções das ferramentas anteriores.
Javascript Parsing: Uma extensão Burp para encontrar caminhos e parâmetros em arquivos JS.
Sourcemapper: Uma ferramenta que, dado a URL .js.map, obterá o código JS embelezado.
xnLinkFinder: Esta é uma ferramenta usada para descobrir endpoints para um alvo específico.
waymore: Descobrir links da máquina wayback (também baixando as respostas na wayback e procurando mais links).
HTTPLoot (go): Rastear (mesmo preenchendo formulários) e também encontrar informações sensíveis usando regexes específicas.
SpiderSuite: Spider Suite é um avançado Crawler/Spider de segurança web com múltiplas funcionalidades projetado para profissionais de cibersegurança.
jsluice (go): É um pacote Go e ferramenta de linha de comando para extrair URLs, caminhos, segredos e outros dados interessantes do código-fonte JavaScript.
ParaForge: ParaForge é uma simples extensão do Burp Suite para extrair os parâmetros e endpoints da requisição para criar listas de palavras personalizadas para fuzzing e enumeração.
katana (go): Ferramenta incrível para isso.
Crawley (go): Imprimir todos os links que conseguir encontrar.

Forçar diretórios e arquivos

Comece a forçar a partir da pasta raiz e tenha certeza de forçar todos os diretórios encontrados usando este método e todos os diretórios descobertos pelo Spidering (você pode fazer essa força recursivamente e adicionando no início da lista de palavras usada os nomes dos diretórios encontrados).
Ferramentas:

Dirb / Dirbuster - Incluído no Kali, antigo (e lento) mas funcional. Permite certificados auto-assinados e busca recursiva. Muito lento em comparação com as outras opções.
Dirsearch (python): Não permite certificados auto-assinados, mas permite busca recursiva.
Gobuster (go): Permite certificados auto-assinados, não possui busca recursiva.
Feroxbuster - Rápido, suporta busca recursiva.
wfuzz wfuzz -w /usr/share/seclists/Discovery/Web-Content/raft-medium-directories.txt https://domain.com/api/FUZZ
ffuf - Rápido: ffuf -c -w /usr/share/wordlists/dirb/big.txt -u http://10.10.10.10/FUZZ
uro (python): Esta não é uma spider, mas uma ferramenta que, dada a lista de URLs encontradas, irá deletar URLs "duplicadas".
Scavenger: Extensão Burp para criar uma lista de diretórios a partir do histórico do burp de diferentes páginas.
TrashCompactor: Remove URLs com funcionalidades duplicadas (baseado em imports js).
Chamaleon: Usa wapalyzer para detectar tecnologias usadas e selecionar as listas de palavras a serem usadas.

Dicionários recomendados:

https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/bf_directories.txt
Dicionário incluído do Dirsearch
http://gist.github.com/jhaddix/b80ea67d85c13206125806f0828f4d10
Listas de palavras Assetnote
https://github.com/danielmiessler/SecLists/tree/master/Discovery/Web-Content
raft-large-directories-lowercase.txt
directory-list-2.3-medium.txt
RobotsDisallowed/top10000.txt
https://github.com/random-robbie/bruteforce-lists
https://github.com/google/fuzzing/tree/master/dictionaries
https://github.com/six2dez/OneListForAll
https://github.com/random-robbie/bruteforce-lists
https://github.com/ayoubfathi/leaky-paths
/usr/share/wordlists/dirb/common.txt
/usr/share/wordlists/dirb/big.txt
/usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

Observe que sempre que um novo diretório for descoberto durante a força bruta ou spidering, ele deve ser forçado.

O que verificar em cada arquivo encontrado

Broken link checker: Encontrar links quebrados dentro de HTMLs que podem estar propensos a tomadas de controle.
Backups de Arquivos: Uma vez que você tenha encontrado todos os arquivos, procure por backups de todos os arquivos executáveis (".php", ".aspx"...). Variações comuns para nomear um backup são: file.ext~, #file.ext#, ~file.ext, file.ext.bak, file.ext.tmp, file.ext.old, file.bak, file.tmp e file.old. Você também pode usar a ferramenta bfac ou backup-gen.
Descobrir novos parâmetros: Você pode usar ferramentas como Arjun, parameth, x8 e Param Miner para descobrir parâmetros ocultos. Se puder, você pode tentar buscar parâmetros ocultos em cada arquivo web executável.
Arjun todas as listas de palavras padrão: https://github.com/s0md3v/Arjun/tree/master/arjun/db
Param-miner “params” : https://github.com/PortSwigger/param-miner/blob/master/resources/params
Assetnote “parameters_top_1m”: https://wordlists.assetnote.io/
nullenc0de “params.txt”: https://gist.github.com/nullenc0de/9cb36260207924f8e1787279a05eb773
Comentários: Verifique os comentários de todos os arquivos, você pode encontrar credenciais ou funcionalidade oculta.
Se você estiver jogando CTF, um truque "comum" é esconder informações dentro de comentários à direita da página (usando centenas de espaços para que você não veja os dados se abrir o código-fonte com o navegador). Outra possibilidade é usar várias novas linhas e esconder informações em um comentário na parte inferior da página web.
Chaves de API: Se você encontrar alguma chave de API, há um guia que indica como usar chaves de API de diferentes plataformas: keyhacks, zile, truffleHog, SecretFinder, RegHex, DumpsterDive, EarlyBird.
Chaves de API do Google: Se você encontrar alguma chave de API parecida com AIzaSyA-qLheq6xjDiEIRisP_ujUseYLQCHUjik, você pode usar o projeto gmapapiscanner para verificar quais APIs a chave pode acessar.
Buckets S3: Enquanto faz spidering, veja se algum subdomínio ou algum link está relacionado a algum bucket S3. Nesse caso, verifique as permissões do bucket.

Descobertas especiais

Enquanto realiza o spidering e força bruta, você pode encontrar coisas interessantes que deve notar.

Arquivos interessantes

Procure por links para outros arquivos dentro dos arquivos CSS.
Se você encontrar um arquivo .git, algumas informações podem ser extraídas.
Se você encontrar um .env, informações como chaves de API, senhas de bancos de dados e outras informações podem ser encontradas.
Se você encontrar endpoints de API, você também deve testá-los. Estes não são arquivos, mas provavelmente "parecerão" com eles.
Arquivos JS: Na seção de spidering, várias ferramentas que podem extrair caminhos de arquivos JS foram mencionadas. Além disso, seria interessante monitorar cada arquivo JS encontrado, pois em algumas ocasiões, uma mudança pode indicar que uma vulnerabilidade potencial foi introduzida no código. Você poderia usar, por exemplo, JSMon.
Você também deve verificar os arquivos JS descobertos com RetireJS ou JSHole para descobrir se são vulneráveis.
Deobfuscador e Desempacotador de Javascript: https://lelinhtinh.github.io/de4js/, https://www.dcode.fr/javascript-unobfuscator.
Embelezador de Javascript: http://jsbeautifier.org/, http://jsnice.org/.
Desofuscação JsFuck (javascript com caracteres:"[]!+" https://enkhee-osiris.github.io/Decoder-JSFuck/).
TrainFuck: +72.+29.+7..+3.-67.-12.+55.+24.+3.-6.-8.-67.-23.
Em várias ocasiões, você precisará entender as expressões regulares usadas. Isso será útil: https://regex101.com/ ou https://pythonium.net/regex.
Você também pode monitorar os arquivos onde os formulários foram detectados, pois uma mudança no parâmetro ou o aparecimento de um novo formulário pode indicar uma nova funcionalidade vulnerável potencial.

403 Forbidden/Basic Authentication/401 Unauthorized (bypass)

{% content-ref url="403-and-401-bypasses.md" %} 403-and-401-bypasses.md {% endcontent-ref %}

502 Proxy Error

Se alguma página responder com esse código, provavelmente é um proxy mal configurado. Se você enviar uma requisição HTTP como: GET https://google.com HTTP/1.1 (com o cabeçalho host e outros cabeçalhos comuns), o proxy tentará acessar google.com e você terá encontrado um SSRF.

Autenticação NTLM - Divulgação de informações

Se o servidor em execução que pede autenticação é Windows ou você encontra um login pedindo suas credenciais (e pedindo o nome do domínio), você pode provocar uma divulgação de informações.
Envie o cabeçalho: “Authorization: NTLM TlRMTVNTUAABAAAAB4IIAAAAAAAAAAAAAAAAAAAAAAA=” e devido a como a autenticação NTLM funciona, o servidor responderá com informações internas (versão do IIS, versão do Windows...) dentro do cabeçalho "WWW-Authenticate".
Você pode automatizar isso usando o plugin nmap "http-ntlm-info.nse".

Redirecionamento HTTP (CTF)

É possível colocar conteúdo dentro de um Redirecionamento. Este conteúdo não será mostrado ao usuário (já que o navegador executará o redirecionamento), mas algo pode estar escondido lá.

Verificação de Vulnerabilidades Web

Agora que uma enumeração abrangente da aplicação web foi realizada, é hora de verificar muitas possíveis vulnerabilidades. Você pode encontrar a lista de verificação aqui:

{% content-ref url="../../pentesting-web/web-vulnerabilities-methodology.md" %} web-vulnerabilities-methodology.md {% endcontent-ref %}

Encontre mais informações sobre vulnerabilidades web em:

Monitorar Páginas para mudanças

Você pode usar ferramentas como https://github.com/dgtlmoon/changedetection.io para monitorar páginas para modificações que possam inserir vulnerabilidades.