ID du bulletin : AWS-2025-021
Étendue : AWS
Type de contenu : important (nécessite une attention particulière)
Date de publication : 08/10/2025, 11 h 15 (heure du Pacifique)

Description :

AWS a connaissance d’un problème potentiel d’usurpation d’identité lié au service de métadonnées d’instance (IMDS) qui pourrait amener les clients à interagir avec des comptes AWS inattendus. Lorsqu’il est exécuté sur une instance EC2, IMDS s’exécute sur une interface réseau de bouclage et transmet les informations d’identification des métadonnées de l’instance, que les clients utilisent pour interagir avec les services AWS. Ces appels réseau ne quittent jamais l’instance EC2, et les clients peuvent être sûrs que l’interface réseau IMDS se situe dans le périmètre de données AWS.

Lorsque vous utilisez des outils AWS (comme AWS CLI/SDK ou l’agent SSM) à partir de nœuds de calcul non EC2, il est possible qu’une instance d’IMDS contrôlée par un tiers envoie des informations d’identification AWS inattendues. Cela nécessite que le nœud de calcul s’exécute sur un réseau où le tiers dispose d’une position privilégiée sur le réseau. AWS recommande aux clients qui utilisent les outils AWS en dehors du périmètre de sécurisation des données d’AWS de suivre les guides d’installation et de configuration (AWS CLI/SDK ou agent SSM) afin de remédier à ce problème. Nous vous recommandons également de surveiller les points de terminaison IMDS susceptibles de s’exécuter dans votre environnement sur site afin de prévenir de manière proactive de tels problèmes d’usurpation d’identité par des tiers.

Versions concernées : IMDSv1 et IMDSv2

Résolution :

AWS recommande aux clients qui utilisent les outils AWS en dehors du périmètre de sécurisation des données d’AWS de suivre les guides d’installation et de configuration (AWS CLI/SDK ou agent SSM) afin de remédier à ce problème.

Surveillance :

Les organisations doivent surveiller le trafic inattendu du service de métadonnées d’instance (IMDS) AWS dans les environnements sur site, car cela indique des erreurs de configuration potentielles, des applications cloud exécutées localement ou des problèmes de sécurité.

Surveillez les connexions à 169.254.169.254 (point de terminaison de métadonnées local de liaison AWS IPv4) et fd00:ec2::254 (point de terminaison de métadonnées AWS IPv6), les requêtes HTTP vers des chemins spécifiques à AWS, comme /latest/meta-data ou /latest/api/token, et la présence d’en-têtes de métadonnées AWS, comme X-aws-ec2-metadata-token. Ces points de terminaison ne devraient jamais apparaître sur des réseaux purement locaux, car ils sont réservés aux instances AWS EC2 pour récupérer les données de configuration, les informations d’identification IAM et les informations d’instance.

Cette présentation des conseils de détection est proposée aux clients dans SIGMA, un format de règles générique qui se traduit en langages de requête SIEM spécifiques, permettant un déploiement universel de la détection. Pour créer cette règle, définissez logsource: category: network pour corréler diverses données de télémétrie réseau, puis créez plusieurs blocs de sélection. ip_aws_dst: dst_ip: 169.254.169.254 capture les connexions directes, tandis que http_url_paths: url|contains: ['/latest/meta-data', '/latest/api/token'] détecte les demandes de métadonnées à l’aide de la syntaxe de liste de SIGMA. Utilisez des variantes de champs comme destination.ip, c-ip, and request_url|contains dans des blocs de sélection distincts pour prendre en charge différents schémas de journalisation entre les différents fournisseurs. Implémentez la logique de condition pour faire correspondre tous les blocs de sélection par leurs préfixes donnés (par exemple, condition: 1 of ip_* or 1 of http_*, où le caractère générique * correspond à tous les blocs de sélection commençant par ces préfixes). La détection peut être affinée en utilisant le modificateur de contenu de SIGMA request_headers|contains: 'X-aws-ec2-metadata-token' pour les demandes de jetons IMDSv2. Après déploiement, SIGMA convertit cette syntaxe universelle dans les langages de requête natifs de votre SIEM (SPL de Splunk, AQL de QRadar, KQL de Sentinel ou KQL d’Elastic) en conservant la même logique de détection tout en s’adaptant aux noms de champs et aux opérateurs spécifiques à la plateforme.

Pour améliorer la fidélité de la règle, les clients peuvent envisager de déclencher l’alerte uniquement pour le trafic réseau local en appliquant une logique de suppression basée sur les sous-réseaux ou VLAN sources.

Veuillez envoyer un e‑mail à l’adresse aws-security@amazon.com pour toute question ou préoccupation en matière de sécurité.