Quando um alcança o serviço de metadados da instância na nuvem, o impacto salta de "acesso interno" para "roubo de credenciais". Este é o endpoint que os atacantes buscam primeiro.

O endereço fixo

, Google Cloud e Azure expõem um Instance Metadata Service () no endereço link-local 169.254.169.254. Ele retorna informações sobre a instância em execução e, na AWS, pode retornar credenciais de segurança temporárias do papel (Gerenciamento de Identidade e Acesso, do inglês Identity and Access Management) associado à instância. Como o endereço é fixo e, por padrão, sem autenticação, qualquer código que consiga fazer o servidor buscar uma URL pode potencialmente lê-lo.

Os endpoints a conhecer

O endereço IPv4 169.254.169.254 é compartilhado entre provedores. O Google Cloud também responde pelo hostname metadata.google.internal, que resolve para esse endereço. A AWS oferece um endpoint de metadados IPv6 em fd00:ec2::254. A Alibaba Cloud usa 100.100.100.200. Um classificador deve reconhecer todos esses, já que cada um é uma rota direta aos segredos da instância.

Por que é tão danoso

Credenciais de papel roubadas permitem ao atacante agir como a instância contra a API do provedor de nuvem, dentro das permissões que o papel tem. A partir de um único SSRF (falsificação de requisição do lado do servidor, do inglês server-side request forgery), isso pode escalar para ler buckets de armazenamento, lançar recursos ou mover-se lateralmente, sem nunca invadir o sistema operacional do host.

A defesa: IMDSv2 e regras de rede

O IMDSv2 da AWS exige um token de sessão obtido com uma requisição PUT e define um limite baixo de saltos IP, o que bloqueia o GET ingênuo de um único disparo que a maioria dos exploits de SSRF usa e impede que a resposta seja roteada para fora da instância. Aplicar o IMDSv2, restringir os papéis das instâncias ao mínimo necessário e bloquear requisições de saída ao endereço de metadados a partir do código da aplicação são as defesas em camadas. Classificar um destino como endpoint de metadados, antes de qualquer requisição, é o primeiro ponto de controle.

Por que a correção é um token, não uma regra de firewall

O instinto é bloquear 169.254.169.254 na camada de rede. É link-local, o que significa que a regra precisa existir em toda instância, para sempre, e uma imagem construída sem ela está a um roubo de credencial de distância do resto.

A correção durável moveu a defesa para dentro do protocolo. O IMDSv2 exige um PUT para obter um token de vida curta antes de qualquer leitura de metadados, e um SSRF comum — que costuma forçar um GET que o atacante não molda — não consegue fazer esse handshake. O endpoint deixa de ser alcançável por acidente em vez de ficar escondido.

O formato geral vale levar: um controle que depende de toda implantação lembrar dele vai, em algum momento, encontrar uma implantação que não lembrou. Tornar a coisa errada estruturalmente impossível dura mais que torná-la administrativamente proibida.