Introdução
O Server-Side Request Forgery (SSRF) é uma vulnerabilidade de segurança web que permite a um atacante induzir a aplicação do lado do servidor a realizar requisições HTTP para um domínio arbitrário à escolha do atacante.
O ponto crucial é que o servidor realiza a requisição, e não o atacante diretamente. Isso significa que a requisição herda a posição de rede do servidor, suas relações de confiança e o acesso a destinos internos.
Em um ataque SSRF típico, o atacante pode fazer com que o servidor estabeleça uma conexão com serviços internos dentro da infraestrutura da organização. Em outros casos, eles podem forçar o servidor a se conectar a sistemas externos arbitrários, potencialmente vazando dados sensíveis, como credenciais de autorização.
Neste laboratório, você interagirá com uma aplicação web vulnerável simulada. Você aprenderá a identificar a vulnerabilidade SSRF, observar como filtros de segurança básicos tentam bloquear requisições maliciosas, contornar esses filtros e, finalmente, extrair dados internos sensíveis e metadados de nuvem simulados. Para manter o exercício compatível com ambientes de laboratório compartilhados, o serviço de metadados simulado utiliza uma porta alta não privilegiada em vez da porta 80.
Identificar Parâmetros de URL
Nesta etapa, você aprenderá a identificar potenciais vulnerabilidades SSRF procurando por funcionalidades da aplicação que buscam dados de URLs externas.
Muitas aplicações web precisam buscar recursos de outros servidores. Por exemplo, uma aplicação pode buscar uma foto de perfil de um site de rede social ou recuperar dados de uma API de terceiros. Se a aplicação aceita uma URL como entrada do usuário e a busca sem a devida validação, ela pode estar vulnerável a SSRF.
É por isso que o SSRF frequentemente aparece em funcionalidades legítimas de "busca de URL". O comportamento perigoso fica escondido dentro de um fluxo de trabalho que parece normal sob a perspectiva do produto.
Uma aplicação web vulnerável foi iniciada para você na porta 8080. Esta aplicação possui um endpoint /check que aceita um parâmetro url. Ele foi projetado para verificar o status de sites externos.
Você pode testar essa funcionalidade pedindo à aplicação para buscar um site externo benigno, como http://example.com. Use o comando curl no seu terminal para enviar uma requisição HTTP GET para a aplicação vulnerável. Se o curl for novo para você, pense nele como um navegador web simples de linha de comando que envia requisições e imprime a resposta do servidor no terminal.
curl "http://localhost:8080/check?url=http://example.com"
Ao executar este comando, a aplicação vulnerável rodando na porta 8080 recebe sua requisição, extrai o parâmetro url e faz sua própria requisição HTTP para http://example.com. Em seguida, ela retorna a resposta HTML para você.
<!doctype html>
<html>
<head>
<title>Example Domain</title>
...
Ao observar que o servidor buscou e retornou com sucesso o conteúdo da URL solicitada, você confirmou que o parâmetro url está sendo processado ativamente e usado para realizar requisições do lado do servidor. Este é o primeiro indicador de uma vulnerabilidade SSRF.
Testar SSRF contra Localhost (127.0.0.1)
Nesta etapa, você tentará explorar a vulnerabilidade SSRF para acessar um serviço interno rodando no servidor.
O perigo principal do SSRF é que o servidor que realiza a requisição geralmente possui uma posição privilegiada na rede. Ele pode acessar serviços internos que não estão expostos à internet pública. Em nosso cenário, existe um painel administrativo interno rodando na porta 5000. Este painel administrativo está vinculado ao 127.0.0.1 (localhost), o que significa que ele só pode ser acessado a partir do próprio servidor, não de outra máquina. Você pode pensar no 127.0.0.1 como o computador falando consigo mesmo.
Como atacante, você pode usar a vulnerabilidade SSRF na porta 8080 para enganar o servidor e fazê-lo acessar o painel administrativo na porta 5000 em seu nome.
Tente acessar o painel administrativo interno passando sua URL local para o endpoint vulnerável /check.
curl "http://localhost:8080/check?url=http://127.0.0.1:5000/admin"
Ao executar este comando, você notará que a requisição não é bem-sucedida. Em vez disso, você recebe uma mensagem de erro.
Error: Localhost access is blocked by WAF!
Os desenvolvedores frequentemente implementam Web Application Firewalls (WAF) ou filtros de entrada para prevenir ataques SSRF. Neste caso, a aplicação verifica se a URL fornecida contém a string 127.0.0.1 ou localhost. Como sua entrada correspondeu a este filtro, a aplicação bloqueou a requisição.
Filtros de string simples são frágeis porque os destinos de rede possuem múltiplas representações equivalentes. Os defensores precisam de uma validação que entenda o significado de rede canônico, não apenas o texto literal.
Entender como a aplicação filtra a entrada é um passo crucial na exploração de SSRF, pois indica quais restrições você precisa contornar.
Contornar Filtros de Entrada
Nesta etapa, você aprenderá como contornar o filtro de entrada básico que encontrou na etapa anterior.
As técnicas de bypass funcionam aqui porque a análise de URL, a resolução de hostname e a filtragem de entrada nem sempre usam as mesmas regras de interpretação.
Filtros de entrada que dependem de correspondência de string simples (como bloquear 127.0.0.1) são frequentemente falhos porque endereços IP podem ser representados de várias maneiras. A pilha de rede do sistema operacional ainda resolverá essas representações alternativas para o mesmo destino, mas o filtro de texto da aplicação pode não reconhecê-las.
Aqui estão algumas maneiras comuns de representar o endereço IP de localhost (127.0.0.1) que podem contornar um filtro mal implementado. Você pode usar um IP encurtado como 127.1, um IP decimal como 2130706433, um IP octal como 0177.000.000.001 ou um IP hexadecimal como 0x7f000001.
Como a aplicação bloqueia apenas as strings exatas 127.0.0.1 e localhost, você pode usar a representação de IP encurtada 127.1 para contornar o filtro e acessar o painel administrativo interno.
Execute o seguinte comando para testar a técnica de bypass:
curl "http://localhost:8080/check?url=http://127.1:5000/admin"
Como 127.1 não corresponde às strings bloqueadas, a aplicação permite que a requisição prossiga. A pilha de rede do servidor resolve 127.1 para 127.0.0.1 e busca com sucesso a página administrativa interna.
Welcome to the Internal Admin Panel. Secret Key: SSRF_ADMIN_SUCCESS
Você contornou com sucesso o filtro de entrada e explorou a vulnerabilidade SSRF para acessar um serviço interno restrito.
Acessar Metadados Internos
Nesta etapa, você usará a vulnerabilidade SSRF para acessar metadados de nuvem sensíveis.
Quando as aplicações são hospedadas em ambientes de nuvem (como AWS, Google Cloud ou Azure), elas frequentemente têm acesso a um endereço IP especial e não roteável: 169.254.169.254. Este endereço hospeda o Instance Metadata Service (IMDS), que fornece informações sobre a instância de nuvem em execução, incluindo credenciais temporárias altamente sensíveis de IAM (Identity and Access Management). "Não roteável" significa que o endereço é destinado à infraestrutura de nuvem local, em vez de acesso público geral à internet.
Se um atacante encontra uma vulnerabilidade SSRF em uma aplicação hospedada na nuvem, consultar este endpoint de metadados é frequentemente seu objetivo principal, pois pode levar ao comprometimento total do ambiente de nuvem.
Neste ambiente de laboratório, um serviço de metadados de nuvem simulado está rodando em 169.254.169.254:8000. O serviço de metadados de nuvem real geralmente usa a porta 80, mas este laboratório usa intencionalmente a porta 8000 para que o serviço possa iniciar sem privilégios especiais e sem conflitar com outros softwares. Primeiro, use a vulnerabilidade SSRF para listar os diretórios de metadados disponíveis.
curl "http://localhost:8080/check?url=http://169.254.169.254:8000/latest/meta-data/"
O servidor buscará a listagem do diretório de metadados e a retornará para você.
iam/security-credentials/admin-role
A saída revela uma função IAM chamada admin-role. Agora você pode anexar este caminho ao seu payload SSRF para extrair as credenciais de segurança reais associadas a esta função.
Execute o seguinte comando para recuperar as credenciais sensíveis:
curl "http://localhost:8080/check?url=http://169.254.169.254:8000/latest/meta-data/iam/security-credentials/admin-role"
O serviço de metadados simulado retornará as credenciais formatadas em JSON.
{"AccessKeyId":"AKIAIOSFODNN7EXAMPLE","SecretAccessKey":"wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"}
Se esta requisição não retornar dados em seu ambiente, verifique brevemente o arquivo /tmp/meta.log e confirme se um serviço está escutando em 169.254.169.254:8000.
Ao extrair com sucesso essas credenciais, você demonstrou o impacto severo de uma vulnerabilidade SSRF em um ambiente de nuvem.
Resumo
Neste laboratório, você explorou e explorou com sucesso uma vulnerabilidade de Server-Side Request Forgery (SSRF). Você aprendeu a identificar parâmetros de URL vulneráveis observando o comportamento de busca do lado do servidor. Em seguida, encontrou um filtro de entrada básico projetado para bloquear o acesso local e o contornou com sucesso usando representações alternativas de endereço IP. Finalmente, você demonstrou o impacto crítico do SSRF ao extrair credenciais sensíveis de metadados de nuvem simulados. Compreender essas técnicas é essencial tanto para identificar vulnerabilidades durante avaliações de segurança quanto para implementar defesas robustas em aplicações web.
