Ataque SSRF: roube credenciais de metadados na nuvem

O que é um ataque SSRF?

Um ataque de server-side request forgery (SSRF) engana um servidor para que ele faça requisições HTTP em nome do atacante. Quando uma aplicação busca uma URL fornecida pelo usuário - para montar uma pré-visualização de link, renderizar uma miniatura ou chamar um webhook - um atacante pode apontá-la para endereços que o servidor alcança mas ele não: painéis administrativos internos, bancos de dados e, o mais perigoso na nuvem, o serviço de metadados da instância. Este lab é construído em torno desse padrão exato.

Como este lab funciona

Você está diante do Previewly, um SaaS de pré-visualização de links que transforma qualquer URL em um cartão rico buscando-a no servidor. Essa busca não tem lista de permissões. Trabalhando inteiramente no Terminal de Ataque com curl e jq, você transforma o recurso de pré-visualização em uma primitiva SSRF, alcança o serviço de metadados em 169.254.169.254, lê um segredo vazado no user-data da instância para o flag de usuário e então rouba as credenciais temporárias do papel IAM da instância. Reapresentar esse token de sessão roubado contra o control-plane interno permissivo demais do Previewly entrega o flag de root. Cada passo é prático; nada é simulado por você.

Por que praticar ataques SSRF e de metadados na nuvem?

SSRF contra o serviço de metadados é um dos ataques de nuvem de maior impacto que existem. No vazamento da Capital One em 2019, uma falha de SSRF permitiu que uma atacante lesse credenciais IAM de 169.254.169.254 e exfiltrasse mais de 100 milhões de registros do S3. A correção - IMDSv2, que exige um token de sessão e bloqueia o SSRF ingênuo - já é padrão, mas muitas instâncias ainda permitem o IMDSv1. Praticar a cadeia completa no HackerDNA desenvolve o instinto de identificar um recurso de busca de URL vulnerável, reconhecer o endpoint de metadados e entender por que papéis IAM com menos privilégios importam.