ID do boletim: AWS-2025-021
Escopo: AWS
Tipo de conteúdo: Importante (requer atenção)
Data de publicação: 8/10/2025 11:15 PDT

Descrição:

A AWS está ciente de um possível problema de falsificação de identidade do Serviço de metadados de instância (IMDS) que pode levar os clientes a interagir com contas da AWS inesperadas. O IMDS, quando executado em uma instância do EC2, funciona em uma interface de rede de loopback e fornece credenciais de metadados de instância, que os clientes utilizam para interagir com os serviços da AWS. Essas chamadas de rede nunca saem da instância do EC2, e os clientes podem confiar que a interface de rede IMDS está dentro do perímetro de dados da AWS.

Ao usar ferramentas da AWS (como a AWS CLI, o SDK ou o SSM Agent) em nós de computação que não sejam do EC2, existe a possibilidade de um IMDS controlado por terceiros fornecer credenciais inesperadas da AWS. Para isso, é necessário que o nó de computação esteja em execução em uma rede na qual o terceiro tenha uma posição privilegiada. A AWS recomenda que, ao usarem as ferramentas da AWS fora do perímetro de dados da AWS, os clientes sigam os guias de instalação e configuração (AWS CLI/SDK ou SSM Agent) para garantir que esse problema seja atenuado. Também recomendamos que você monitore os endpoints do IMDS que possam estar em execução no seu ambiente on-premises, a fim de prevenir proativamente esses problemas de falsificação de identidade por parte de terceiros.

Versões afetadas: IMDSv1 e IMDSv2

Resolução:

A AWS recomenda que, ao usarem as ferramentas da AWS fora do perímetro de dados da AWS, os clientes sigam os guias de instalação e configuração (AWS CLI/SDK ou SSM Agent) para garantir que esse problema seja atenuado.

Monitoramento:

As organizações devem monitorar o tráfego inesperado do serviço de metadados de instância (IMDS) da AWS em ambientes on-premises, pois isso indica possíveis configurações incorretas, aplicações de nuvem em execução localmente ou problemas de segurança.

Monitore as conexões para 169.254.169.254 (endpoint de metadados link-local IPv4 da AWS) e fd00:ec2::254 (endpoint de metadados IPv6 da AWS), solicitações HTTP para caminhos específicos da AWS, como /latest/meta-data ou /latest/api/token, e a presença de cabeçalhos de metadados da AWS, como X-aws-ec2-metadata-token. Esses endpoints nunca devem aparecer em redes puramente on-premises, pois são reservados para instâncias do AWS EC2 recuperarem dados de configuração, credenciais do IAM e informações de instâncias.

Os clientes estão recebendo esta visão geral das orientações de detecção no SIGMA, um formato de regra genérico que se traduz em linguagens de consulta SIEM específicas, possibilitando a implantação universal da detecção. Para criar essa regra, defina logsource: category: network para correlacionar diversas telemetrias de rede e, em seguida, crie vários blocos de seleção. ip_aws_dst: dst_ip: 169.254.169.254 captura conexões diretas, enquanto http_url_paths: url|contains: [‘/latest/meta-data’, ‘/latest/api/token’] detecta solicitações de metadados usando a sintaxe de lista do SIGMA. Use variantes de campo como destination.ip, c-ip e request_url|contains em blocos de seleção separados para acomodar diferentes esquemas de log entre fornecedores. Implemente a lógica da condição para corresponder a todos os blocos de seleção pelos seus prefixos fornecidos (por exemplo, condição: 1 de ip_* ou 1 de http_*, em que o curinga * corresponde a todos os blocos de seleção que começam com esses prefixos). A detecção pode ficar mais precisa usando o modificador “contains” do SIGMA: request_headers|contains: ‘X-aws-ec2-metadata-token’ para solicitações de token IMDSv2. Após a implantação, o SIGMA converte essa sintaxe universal nas linguagens de consulta nativas do seu SIEM (SPL do Splunk, AQL do QRadar, KQL do Sentinel ou KQL do Elastic), mantendo a mesma lógica de detecção e adaptando-se aos nomes de campos e operadores específicos da plataforma.

Para aumentar a precisão da regra, os clientes podem considerar utilizar o gatilho do alerta apenas para o tráfego de rede on-premises, aplicando uma lógica de supressão com base em sub-redes de origem ou VLANs.

Envie um e-mail para aws-security@amazon.com em caso de qualquer dúvida ou preocupação sobre segurança.