SSRF Contra o Serviço de Metadados da Nuvem para Ler o Papel IAM

Falsificação de requisição no lado do servidor (SSRF) ocorre quando uma aplicação busca uma URL fornecida pelo usuário, e o atacante consegue fazer com que ela requisite um destino que a aplicação nunca pretendia. Um recurso como um proxy de imagens, um testador de webhook ou um "desenrolador" de links é o veículo clássico: ele recebe uma URL e a busca fielmente a partir do servidor. Como a requisição parte do servidor, ela pode alcançar endereços que o atacante não consegue tocar de fora, serviços internos, painéis administrativos e o endpoint de metadados da nuvem.

Em uma instância de nuvem, o serviço de metadados da instância (IMDS) responde no endereço link-local 169.254.169.254. Ele só é alcançável a partir da própria instância, então qualquer coisa que rode ali, incluindo um proxy vulnerável, pode consultá-lo. O caminho /latest/meta-data/iam/security-credentials/ lista o papel IAM anexado à máquina, e acrescentar esse nome de papel devolve chaves de acesso AWS ativas e de curta duração. Um SSRF que consegue alcançar o IMDS, portanto, se converte diretamente em credenciais de nuvem com as permissões da instância.

A falha não é o serviço de metadados; é o fato de o proxy buscar uma URL arbitrária sem nenhuma restrição sobre o destino. Sem uma lista de permissão, o servidor é um adjunto confuso: ele carrega a intenção do atacante com sua própria posição de rede e privilégios.

• Assumir que o proxy só consegue alcançar CDNs públicas, quando na verdade ele busca qualquer endereço para o qual o próprio servidor consiga rotear, incluindo endereços internos e link-local.
• Mirar primeiro em localhost ou 127.0.0.1 e não perceber que os segredos da nuvem ficam no endereço de metadados link-local separado 169.254.169.254.
• Parar na listagem de diretório de credenciais sem perceber que o nome do papel devolvido é a resposta (e o próximo passo até as chaves ativas).
• Tratar o SSRF como um bug de parsing em vez da falha real: não existe lista de permissão restringindo para onde o servidor pode enviar requisições.

A correção é restringir para onde o servidor pode enviar requisições de saída e reforçar o próprio serviço de metadados. Nunca busque uma URL fornecida pelo usuário sem validar o destino resolvido contra uma lista de permissão.

• Coloque em lista de permissão os hosts/domínios autorizados para o proxy e rejeite todo o resto; resolva o nome do host e bloqueie as faixas privadas, loopback e link-local (incluindo 169.254.0.0/16) depois da resolução para impedir DNS rebinding.
• Exija o IMDSv2 (com token de sessão obrigatório) para que um SSRF simples baseado em GET não consiga mais ler credenciais, e defina o limite de saltos dos metadados como 1.
• Restrinja o papel IAM da instância ao menor privilégio necessário, para que uma credencial vazada seja muito menos útil.
• Registre e alerte sobre buscas de saída para endereços internos ou link-local, para que tentativas de SSRF fiquem visíveis.