Endpoints de metadados na nuvem: a superfície de ataque oculta

Todo grande provedor de nuvem expõe um serviço de metadados de instância às máquinas virtuais que rodam em sua plataforma, geralmente acessível pelo endereço link-local 169.254.169.254. De dentro da instância, uma simples requisição HTTP a esse endereço pode retornar a configuração da instância, detalhes de rede e, em muitas configurações padrão, credenciais de segurança temporárias da função ou identidade atribuída a ela.

Por que ele é perigoso, especialmente combinado com SSRF

O endpoint de metadados só deveria ser acessível a partir da própria instância e não é exposto à internet pública. Mas, se um processo no servidor puder ser induzido a fazer uma requisição HTTP para um endereço escolhido pelo atacante (o SSRF clássico) e esse endereço for justamente o endpoint de metadados, o atacante faz o servidor buscar as próprias credenciais de nuvem e devolvê-las na resposta. Não é preciso ter acesso direto de rede ao endpoint de metadados a partir de fora: o servidor vulnerável faz a busca em nome do atacante.

• 169.254.169.254 faz parte da faixa link-local mais ampla 169.254.0.0/16, que nunca deve ser tratada como um destino legítimo de resolução DNS pública.
• Alguns provedores adotaram uma versão do serviço de metadados protegida por token justamente para dificultar SSRFs simples, mas bloquear o endereço por completo na camada da aplicação continua sendo a defesa mais robusta.
• É exatamente por isso que os endereços link-local devem estar na mesma lista de bloqueio das faixas privadas e de loopback em qualquer ferramenta que resolva domínios informados pelo usuário: não se trata de uma categoria de risco separada nem menor.

A lição prática

Qualquer sistema que resolva e requisite uma URL em nome de um usuário precisa tratar 169.254.169.254, e toda a faixa link-local à qual ele pertence, como terminantemente proibido, com a verificação feita no momento da requisição real, sempre, independentemente de como o endereço foi obtido (digitado diretamente ou alcançado por meio de um registro DNS que aponta direto para ele).

Não é exclusivo de um único provedor de nuvem

O endereço 169.254.169.254 é a convenção da AWS, do Google Cloud e do Azure, mas o padrão por trás dele, um endereço link-local que expõe a identidade e as credenciais da instância apenas a ela mesma, aparece de alguma forma em praticamente toda grande plataforma de nuvem e de contêineres, às vezes no mesmo endereço, às vezes em um específico do provedor. Clusters Kubernetes costumam ter seus próprios endpoints internos, semelhantes a metadados, acessíveis de dentro de um pod. Vale memorizar o endereço dos provedores de nuvem mais comuns, mas o que realmente se generaliza é o princípio: trate todo endpoint no estilo de metadados como proibido para qualquer coisa que resolva e busque uma URL informada pelo usuário, seja qual for a plataforma em que ela esteja rodando.

IMDSv2: uma mitigação real, não apenas um filtro

A resposta da AWS a anos de exploração exatamente desse padrão foi uma segunda versão do serviço de metadados, o IMDSv2, que exige um token de sessão obtido por meio de uma requisição PUT especial antes que qualquer metadado possa ser lido. E, o que é decisivo, essa requisição PUT não pode ser replicada pela simples requisição GET disparada por SSRF que a maioria dos caminhos de código vulneráveis realmente faz.

É uma melhoria significativa, mas em muitas contas é opcional por compatibilidade com versões anteriores e protege apenas o endpoint de metadados, sem fazer nada pelos demais endereços privados e internos que um SSRF ainda poderia alcançar. A filtragem dos endereços resolvidos na camada da aplicação continua necessária, qualquer que seja a versão do serviço de metadados em uso.