Roubando Credenciais de Role de Instância pelo Serviço de Metadados

Instâncias em nuvem costumam rodar com uma role anexada para que a aplicação possa chamar serviços de nuvem sem que ninguém precise fixar chaves de longa duração no código. A plataforma entrega as credenciais temporárias dessa role através de um endereço link-local especial, 169.254.169.254, acessível apenas a partir da própria instância. O código que precisa de uma credencial consulta esse serviço de metadados na inicialização e em cada atualização. É conveniente e dispensa chaves fixas, o que é exatamente o motivo de ser um alvo de primeira linha.

Qualquer processo na instância, incluindo um shell no qual um atacante acabou de cair, pode alcançar o mesmo endereço. Percorrer o caminho é mecânico: iam/security-credentials/ lista o nome da role, aqui s3-backup-role, e requisitar iam/security-credentials/s3-backup-role retorna um documento JSON contendo um AccessKeyId, uma SecretAccessKey e um Token de curta duração. Quem lê esse JSON passa a ter as mesmas permissões que foram confiadas à instância.

O passo final transforma essas credenciais em saque. As notas da instância mencionam um backup para um bucket de segredos via o endpoint de armazenamento interno em 10.0.0.40. Enviar o Token roubado como cabeçalho X-Instance-Token para http://10.0.0.40/s3/acme-secrets/flag.txt autentica a requisição e retorna a flag. A cadeia - shell, token de metadados, leitura autenticada de armazenamento - é um dos caminhos de escalada em nuvem mais comuns, e funciona porque um ponto de apoio no host herda a role do host.

• Acessar o endpoint de armazenamento sem token. 10.0.0.40 retorna 403 missing or invalid x-instance-token até que você forneça o token de metadados como cabeçalho.
• Tentar adivinhar o nome da role. A role não é arbitrária, ela é listada em iam/security-credentials/ como s3-backup-role; você precisa lê-la, não inventá-la.
• Pegar o campo errado. O endpoint quer o valor de Token, não o AccessKeyId ou o SecretAccessKey.
• Tentar o IP de metadados fora da máquina. 169.254.169.254 é link-local e só responde a partir da própria instância, por isso um shell no host é o que destrava o acesso.

O serviço de metadados é um recurso, não uma falha, mas precisa ser endurecido para que um ponto de apoio não vire automaticamente acesso à nuvem:

• Aplicar IMDSv2 (token de sessão obrigatório, hop limit definido como 1) para que um simples server-side request forgery ou um curl básico não consiga alcançar o endpoint de metadados.
• Aplicar privilégio mínimo à role da instância, uma máquina de backup não deveria ter uma role capaz de ler todos os segredos da conta.
• Limitar o escopo e reduzir o tempo de vida das credenciais, e alertar quando credenciais de role forem usadas a partir de um IP que não é o da instância.
• Exigir autenticação forte e por identidade em endpoints internos como o serviço de armazenamento, em vez de aceitar qualquer token que a instância apresente.

Se houver suspeita de que as credenciais da instância foram roubadas, revogue a sessão, rotacione a confiança da role e revise o que essa role podia acessar, credenciais temporárias continuam perigosas até expirarem.