Metadados e SSRF

Toda VM na nuvem pode consultar um endpoint interno especial para obter informações sobre si mesma: o Instance Metadata Service (IMDS). O que é especialmente importante é que ele também pode fornecer as credenciais temporárias da função associada à instância.

• AWS / GCP / Azure expõem metadados em 169.254.169.254
• Ele só pode ser acessado de dentro da instância
• Não exige autenticação dos processos locais

Essa conveniência se torna uma arma quando combinada com SSRF.

No legado IMDSv1, uma única solicitação GET retorna metadados, incluindo as credenciais da função. Nenhum token é necessário.

É exatamente isso que torna o IMDSv1 perigoso quando um app tem SSRF.

Server-Side Request Forgery (SSRF) é uma vulnerabilidade na qual um invasor engana um servidor para que ele faça solicitações HTTP em seu nome. O servidor se torna um proxy para locais que o invasor não consegue alcançar diretamente.

• Um parâmetro de URL que o servidor busca
• Um webhook, gerador de PDF ou recurso de redimensionamento de imagens
• Qualquer recurso que aceite uma URL fornecida pelo usuário

O alvo clássico de SSRF na nuvem é o endpoint de metadados.

A combinação perigosa é esta: um app com SSRF permite que o invasor aponte o servidor para 169.254.169.254. O servidor busca as credenciais IAM da instância e as devolve.

Agora o invasor possui credenciais da nuvem, muitas vezes o início do controle total da conta.

A resposta dos metadados contém uma chave de acesso, uma chave secreta e um token de sessão. O invasor as exporta e passa imediatamente a agir como a função da instância.

A partir daí, ele enumera as permissões e procura caminhos para escalada.

AWS introduziu o IMDSv2 para reduzir o impacto de SSRF. Ele exige primeiro um token de sessão obtido por meio de uma solicitação HTTP PUT, algo que a maioria dos mecanismos de SSRF não consegue realizar (eles fazem apenas GET).

Exigir IMDSv2 e definir um limite baixo de saltos reduz drasticamente o roubo de metadados por meio de SSRF.

Os outros provedores também expõem metadados, com suas próprias particularidades. Ambos exigem um cabeçalho especial, o que por si só já é uma pequena mitigação contra SSRF.

• Azure exige Metadata: true
• GCP exige Metadata-Flavor: Google

Os defensores costumam bloquear 169.254.169.254. Os invasores contornam filtros ingênuos usando codificações alternativas de IP e redirecionamentos.

• IP decimal: 2852039166
• Codificações octais/hexadecimais do mesmo endereço
• Rebinding de DNS para um nome que resolve para o IP dos metadados
• Redirecionamentos abertos que encaminham a solicitação para a URL de metadados

Defesas robustas devem validar o IP resolvido, não a cadeia de caracteres bruta.

Os metadados são o alvo principal, mas SSRF alcança mais recursos internos:

• Painéis e consoles administrativos internos vinculados ao localhost
• Bancos de dados e caches internos (Redis, Elasticsearch)
• Servidor de API do Kubernetes e endpoints do kubelet
• Outros microsserviços não expostos externamente

SSRF efetivamente perfura o perímetro da rede a partir de um ponto de observação confiável.

Romper a cadeia de SSRF até os metadados exige uma defesa em camadas:

• Exija IMDSv2 e defina o limite de saltos dos metadados como 1
• Valide as URLs de saída e mantenha uma lista de permissões nos recursos de busca
• Bloqueie solicitações para intervalos de IP locais ao enlace e privados após a resolução de DNS
• Aplique o princípio do menor privilégio às funções das instâncias, para limitar as credenciais roubadas

Funções com o menor privilégio garantem que até mesmo um roubo bem-sucedido cause pouco impacto.

Os testes de SSRF podem alcançar sistemas internos sensíveis por natureza. Seja disciplinado:

• Confirme se o host-alvo e a conta da nuvem estão dentro do escopo
• Não avance para sistemas fora do escopo do trabalho
• Pare e comunique o resultado assim que comprovar o acesso às credenciais

Alcançar os metadados tem alto impacto; demonstre isso com cuidado e não faça uso indiscriminado das chaves roubadas.

Você aprendeu a cadeia de ataque específica da nuvem com maior impacto.

• O serviço de metadados em 169.254.169.254 fornece as credenciais da função da instância
• SSRF permite que um invasor faça o servidor buscar esse endpoint
• Credenciais temporárias roubadas permitem assumir o controle da conta
• IMDSv2 bloqueia a maioria dos ataques de SSRF ao exigir um token baseado em PUT
• Defenda-se usando listas de permissões de URLs, validação de IP e funções com o menor privilégio

Isso conclui o Pentest de Nuvem. Próximo curso: Caça a Recompensas por Bugs.