A API de metadados de instância é o cofre silencioso de cada servidor na AWS: é dela que as aplicações buscam as credenciais temporárias do perfil IAM anexado à máquina. O IMDSv2 fecha a rota mais barata para roubar essas chaves ao exigir um token de sessão em toda consulta, e a ação prioritária de qualquer equipe que opera EC2 é exigir a versão com token nas instâncias novas, medir o consumo da versão antiga nas existentes e desligar o IMDSv1 quando a métrica zerar.
Como o IMDSv2 funciona
O IMDSv2 troca o modelo simples de requisição e resposta do IMDSv1 por sessões. Para ler qualquer metadado, o software precisa primeiro abrir a sessão com uma requisição PUT no endereço 169.254.169.254; o serviço devolve um token com tempo de vida de até 21.600 segundos, o equivalente a seis horas, e o token é obrigatório para ler os metadados nas chamadas GET seguintes. Sem token válido, ou com token expirado, a resposta é um erro HTTP 401 quando a instância está configurada para exigir a versão nova.
O desenho tem dois efeitos defensivos diretos. Primeiro, requisições PUT que chegam com cabeçalho X-Forwarded-For são rejeitadas, o que derruba as receitas clássicas de SSRF por proxy reverso, nas quais o atacante induz a aplicação a fazer o pedido em nome dele. Segundo, a resposta do PUT chega com limite de 1 salto por padrão no nível do protocolo IP: um pedido forjado que passe por um contêiner ou por qualquer camada extra de rede não recebe o token de volta. Se a carga de trabalho roda em contêineres dentro da instância, o limite pode ser ampliado com o comando modify-instance-metadata-options — uma decisão que precisa constar na documentação da migração, porque reduz essa barreira.
Na escolha do tempo de vida do token, a regra prática é encurtar o quanto a aplicação tolerar. Tokens longos reduzem o número de PUTs e o risco de throttling; tokens curtos diminuem a janela em que um token capturado na memória do processo continua válido. Documente a escolha junto ao código que consome o metadado, para que a próxima revisão saiba por que o número foi definido assim.
Por que o IMDSv1 ainda expõe
O IMDSv1 aceita qualquer GET sem token, e o endpoint é alcançável por qualquer processo dentro da instância. O MITRE mantém o abuso dessa interface como a sub-técnica T1552.005 do ATT&CK, com duas rotas documentadas: com capacidade de execução já obtida, o invasor pode consultar a API direto do próprio servidor comprometido; sem execução, basta uma falha de Server-Side Request Forgery em uma aplicação web exposta para que a própria vítima faça o pedido ao endereço 169.254.169.254, que virou padrão de fato entre provedores de nuvem.
As ferramentas catalogadas na própria matriz mostram que a consulta não é exotismo: o Peirates consulta endpoints de metadados da AWS e do GCP em busca de segredos, o TruffleHog faz o mesmo para credenciais de instância e serviço, e o grupo TeamTNT já usou o serviço para extrair chaves de contas de nuvem. O resultado prático é escala: uma credencial de perfil IAM capturada abre caminho para enumeração de recursos, exfiltração de dados e movimentação lateral dentro da conta.
Cenário hipotético para treinamento, construído para exercitar a resposta: uma aplicação de relatórios tem uma falha de SSRF no endpoint que gera PDFs a partir de uma URL informada pelo usuário. Com IMDSv1 ativo, o atacante aponta a geração para o caminho de credenciais do perfil e recebe as chaves no próprio documento. Com IMDSv2 exigido, o pedido do atacante chega como GET sem token e recebe 401; para obter o token ele precisaria de um PUT, que o fluxo de SSRF não executa, e ainda esbarraria no limite de saltos da resposta. A falha da aplicação continua existindo — e precisa ser corrigida —, mas a credencial de nuvem não sai pela porta.
O risco também começa fora do servidor: quando a base do ataque é o roubo de credenciais em massa, logs de infostealer viram atalho para o SSO corporativo, e o metadado exposto é só mais uma fonte da mesma commodity.
Migração em cinco passos
A AWS documenta uma transição em cinco etapas, desenhada para migrar sem quebrar aplicações legadas:
| Passo | Ação | Ferramenta ou sinal |
|---|---|---|
| 1. Mapear | Listar instâncias com IMDSv2 opcional | Filtro metadata-options.http-tokens = optional no console ou no describe-instances |
| 2. Auditar | Medir chamadas IMDSv1 por instância e identificar o software que as faz | Métrica MetadataNoToken e IMDS Packet Analyzer |
| 3. Atualizar | Elevar SDKs e CLI às versões mínimas com suporte | Boto3 1.12.6, AWS CLI 1.16.289 ou superiores |
| 4. Exigir | Marcar httpTokens como required instância por instância | modify-instance-metadata-options ou console |
| 5. Travar | Definir IMDSv2 como padrão da conta e impedir o retorno ao IMDSv1 | modify-instance-metadata-defaults, política IAM ou SCP |
A meta operacional é acompanhar o zero da métrica MetadataNoToken em cada instância antes de declarar a migração concluída: enquanto o número não cai, ainda existe software dependendo da versão antiga. Depois do corte, a métrica MetadataNoTokenRejected passa a contar as tentativas rejeitadas de IMDSv1 e revela chamadores esquecidos. No passo 3, vale lembrar que o Amazon Linux 2023 já traz suporte completo ao IMDSv2 e desativa o IMDSv1 por padrão, o que encurta a auditoria em frotas dessa distribuição.
Para fechar a porta com tranco, existe uma camada adicional de imposição: uma condição de política IAM ou SCP com a chave ec2:RoleDelivery valendo 2.0. Com ela, chamadas de API autenticadas com credenciais obtidas pelo IMDSv1 recebem UnauthorizedOperation, bloqueando o uso das credenciais antigas mesmo que alguém reative a versão antiga em uma instância esquecida. No nível de conta, a imposição de IMDSv2 impede o lançamento de instâncias novas com IMDSv1 ativo e bloqueia a reativação nas máquinas que já foram migradas.
Verificação e monitoramento
Migração sem verificação é hipótese. Os sinais mínimos para manter depois do corte:
- P1: alarme sobre MetadataNoTokenRejected por instância, para capturar software legado quebrado e tentativas suspeitas na mesma leitura.
- P1: política IAM ou SCP com ec2:RoleDelivery = 2.0 publicada e testada com uma chamada negada em ambiente de homologação.
- P2: revisão trimestral do filtro de instâncias com token opcional, para capturar máquinas criadas fora do padrão.
- P2: conferência de que imagens novas de AMI carregam ImdsSupport = v2.0, herança que faz a instância nascer com o token exigido.
Uma auditoria periódica de postura transforma esses sinais em rotina; o guia do Prowler na prática mostra como aplicar esse ciclo de checagem contínua à conta como um todo. A decisão de engenharia fica simples quando os critérios estão explícitos: instância nova nasce com IMDSv2 exigido, instância antiga entra na fila de migração pelo inventário, e nenhuma exceção de hop limit sobrevive sem registro e data de revisão.