hunt-ssrf

⚠️ USO AUTORIZADO APENAS Esta habilidade é apenas para fins educacionais ou avaliações de segurança autorizadas. Você deve ter permissão explícita e por escrito do proprietário do sistema antes de usar esta ferramenta. O uso indevido desta ferramenta é ilegal e estritamente proibido.

Porta de confirmação obrigatória Antes de executar qualquer comando que sonde, explore, altere, persista em, extraia dados de ou tente acesso a credenciais contra um alvo:

1. Peça ao usuário para declarar o URL exato, IP, conta ou recurso alvo.
2. Peça ao usuário para confirmar a autorização por escrito e o escopo permitido.
3. Mostre o(s) comando(s) exato(s) e explique seu efeito esperado.
4. Aguarde a confirmação explícita na conversa atual.

Sem essa confirmação, permaneça apenas em modo de leitura e forneça orientação defensiva. Prefira um sandbox, VM descartável ou laboratório controlado.

Alvos Principais (Crown Jewel Targets)

SSRF tem o maior valor quando o alvo é executado em infraestrutura de nuvem (AWS, GCP, Azure), onde serviços de metadados expõem credenciais, ou quando o servidor está dentro de uma rede interna complexa (clusters Kubernetes, malhas de microsserviços, APIs internas). Alvos prioritários:

• Produtos SaaS hospedados em nuvem (metadados GCP em 169.254.169.254 ou metadata.google.internal, AWS IMDSv1)
• Plataformas Kubernetes/orquestração — servidores de API agregados, metrics-server, endpoints kubelet expõem operações privilegiadas do cluster
• Ferramentas internas de desenvolvimento — CI/CD, orquestração de fluxo de trabalho (Flyte, Argo), painéis administrativos não expostos externamente
• Recursos de visualização de links / busca de URLs — APIs de pré-visualização estilo Reddit, unfurling estilo Slack, processadores de mídia
• Pipelines de importação de conjuntos de dados/arquivos — qualquer coisa que busque URLs remotos em nome de um usuário
• Software auto-hospedado empresarial (GitHub Enterprise, GitLab) — SSRF frequentemente se conecta a RCE através de serviços internos

Os retornos são maiores quando SSRF atinge: credenciais de nuvem → tomada de conta, APIs administrativas internas → exfiltração de dados, ou se conecta a RCE.

Porta OOB-Ou-Não-Aconteceu (Leia Primeiro)

Alegações de SSRF cego exigem confirmação out-of-band (OOB). Sempre. Sem exceções.

OOB significa: um domínio Burp Collaborator, um listener interactsh-client, um canarytoken, ou qualquer receptor DNS+HTTP que você controle e que confirme que o servidor realmente fez uma conexão de rede de saída em seu nome.

O que NÃO é confirmação de SSRF

• O servidor ecoando seu URL de volta em uma mensagem de erro. Exemplo: "The Web application at http://evil.example.com/x could not be found" — isso é o servidor formatando sua entrada em uma string de erro, NÃO fazendo uma requisição HTTP de saída. O erro veio da formatação da string, não de falha de rede.
• O servidor retornando um código de status diferente para um URL externo versus localhost. Diferentes respostas de erro podem vir de validadores de esquema de URL, não de busca real.
• Uma resposta atrasada quando o URL é enviado. O atraso pode vir de tentativas de resolução DNS dentro do parser, não de buscas HTTP completas.

O que É confirmação de SSRF

• Uma consulta DNS para seu subdomínio Collaborator exclusivo aparece no listener OOB.
• Uma requisição HTTP para seu endpoint HTTP Collaborator com o IP de origem e User-Agent do servidor.
• Para SSRF em contextos de execução JavaScript (renderizadores de PDF, navegadores headless), uma busca do servidor para sua URL de callback.

Fluxo de trabalho padrão

1. Plante o payload do Collaborator primeiro. Sub-tagging (dlsrcurl.<collab>, import.<collab>) só funciona se seu listener realmente reportar o subdomínio consultado de volta para você — verifique isso antes de confiar nele. O Burp get_collaborator_interactions chaveia resultados por ID do payload, não por subdomínio, então várias sub-tags geradas a partir de um payload são indistinguíveis na saída. Quando for esse o caso, gere um payload novo por parâmetro candidato e envie exatamente uma requisição por payload.
2. Envie a requisição para o endpoint alvo.
3. Aguarde 30–120 segundos, então consulte o listener OOB.
4. Somente após um callback confirmado você alega SSRF.
5. Se zero callbacks em todos os sinks com sub-tags: as alegações de SSRF devem ser retratadas, mesmo que mensagens de erro ecoem URLs.

…