Exploitation du Service de Métadonnées Cloud : IMDSv1, la porte ouverte aux identifiants AWS ☁️

Introduction : La porte cachée vers votre royaume cloud

Dans le paysage de la sécurité cloud, peu de vulnérabilités restent aussi exploitées de manière persistante tout en étant fondamentalement évitables que le Service de Métadonnées d’Instance AWS version 1 (IMDSv1). Bien qu’introduit il y a plus de dix ans comme une fonctionnalité pratique pour les instances EC2, IMDSv1 est devenu ce que les chercheurs en sécurité appellent la “clé-squelette” des environnements AWS — un service apparemment inoffensif qui, lorsqu’il est exploité via des attaques de Server-Side Request Forgery (SSRF), donne aux attaquants un accès complet aux identifiants IAM temporaires, aux métadonnées d’instance, et potentiellement à toute votre infrastructure cloud.

Les enjeux sont élevés. La célèbre faille de 2019 chez Capital One, qui a exposé plus de 100 millions de dossiers clients et entraîné une amende de 80 millions de dollars, n’était pas le résultat d’une attaque zero-day sophistiquée ou d’une menace persistante avancée. C’était une attaque SSRF simple ciblant IMDSv1 — une vulnérabilité que Amazon Web Services connaissait depuis au moins 2018. Pourtant, en décembre 2024, seulement 32 % des instances EC2 ont migré vers IMDSv2, plus sécurisé, laissant la majorité de l’infrastructure cloud exposée aux mêmes vecteurs d’attaque qui ont dévasté Capital One.

Ce guide complet explore comment les attaques SSRF exploitent les points d’accès aux métadonnées cloud, pourquoi le service de métadonnées AWS reste une cible critique pour le vol d’identifiants et l’escalade de privilèges, et ce que les organisations doivent faire pour protéger leur infrastructure cloud avant de devenir la prochaine grande actualité.

Comprendre le Service de Métadonnées d’Instance : La commodité face à la vulnérabilité

Qu’est-ce que IMDS et pourquoi existe-t-il ?

Le Service de Métadonnées d’Instance AWS est une API accessible depuis les instances EC2 à l’adresse IP locale spéciale 169.254.169.254. Cette adresse est intentionnellement non routable sur Internet, ce qui signifie que seul un logiciel s’exécutant directement sur une instance EC2 peut y accéder — ou du moins c’est ce que la conception voulait.

IMDS a été créé pour résoudre un défi fondamental de la sécurité cloud : comment les applications s’exécutant sur des instances EC2 peuvent accéder en toute sécurité aux ressources AWS sans coder en dur des identifiants ? Le service offre une solution élégante en rendant disponibles localement des identifiants IAM temporaires, souvent renouvelés, ce qui élimine le besoin d’intégrer des clés d’accès sensibles dans le code ou la configuration.

Au-delà des identifiants, IMDS expose des métadonnées critiques de l’instance, notamment :

• ID de l’instance, ID AMI, type d’instance
• Configuration réseau (adresses IP, groupes de sécurité, sous-réseaux)
• Nom du rôle IAM et identifiants temporaires associés
• Données utilisateur et scripts d’initialisation
• Mappages de dispositifs de stockage et informations de stockage

Ces métadonnées permettent aux applications de se configurer elles-mêmes, de s’authentifier auprès des services AWS, et de s’adapter dynamiquement à leur environnement — une capacité puissante devenue fondamentale dans l’architecture cloud moderne.

La faille fatale : l’architecture requête-réponse de IMDSv1

IMDSv1 fonctionne sur un modèle simple requête-réponse qui ne nécessite que des requêtes HTTP GET. Tout processus capable d’effectuer des appels HTTP vers 169.254.169.254 peut récupérer les métadonnées d’instance sans authentification, gestion de session ou vérification d’autorisation. Cette conception repose sur plusieurs hypothèses de sécurité critiques :

1. Hypothèse de frontière de confiance : le service suppose que toute requête provenant de l’intérieur de l’instance est légitime
2. Aucune authentification : IMDSv1 ne vérifie pas l’origine de la requête
3. Aucune gestion de session : chaque requête est indépendante, sans suivi d’état
4. Aucune validation de requête : le service ne distingue pas entre requêtes légitimes et tentatives d’exploitation

Ces hypothèses créent ce que les chercheurs en sécurité appellent une “vulnérabilité de divulgation d’informations non authentifiée” — mais la réalité est bien plus grave car les informations divulguées incluent des identifiants AWS complets.

Passons à IMDSv2 : la sécurité basée sur la session

En novembre 2019, quatre mois après la faille Capital One, AWS a lancé IMDSv2 avec des protections en profondeur conçues spécifiquement pour atténuer les attaques SSRF. IMDSv2 implémente une architecture orientée session nécessitant une authentification en deux étapes :

Étape 1 : Génération du jeton

PUT http://169.254.169.254/latest/api/token
X-aws-ec2-metadata-token-ttl-seconds: 21600

Cette requête PUT génère un jeton de session avec une durée de vie (TTL) spécifiée entre 1 seconde et 6 heures.

Étape 2 : Requêtes authentifiées

GET http://169.254.169.254/latest/meta-data/
X-aws-ec2-metadata-token: AQAAANpaYGqH...

Toutes les requêtes suivantes doivent inclure le jeton dans l’en-tête X-aws-ec2-metadata-token.

Cette architecture bloque efficacement l’exploitation SSRF car :

• Les attaquants doivent contrôler à la fois les méthodes HTTP (GET et PUT)
• Les attaquants doivent injecter des en-têtes HTTP personnalisés
• La méthode basée sur le jeton empêche l’exploitation simple par URL
• La limite de TTL réduit la fenêtre d’opportunité même si les jetons sont compromis

Malgré ces protections robustes et le fait qu’AWS fasse de IMDSv2 le paramètre par défaut pour les nouvelles instances depuis novembre 2023, la transition reste incomplète. Selon le rapport 2024 de Datadog sur la sécurité cloud, 68 % des instances EC2 n’appliquent toujours pas IMDSv2, ce qui représente des millions d’instances potentiellement vulnérables dans l’écosystème AWS.

La requête SSRF : la voie d’exploitation d’IMDS

Anatomie d’une attaque SSRF

Le Server-Side Request Forgery (SSRF) est une vulnérabilité d’application web qui permet à un attaquant de manipuler un serveur pour effectuer des requêtes HTTP non désirées vers des destinations choisies par l’attaquant. Le SSRF figure parmi les 10 principales vulnérabilités OWASP et a été systématiquement utilisé contre les services de métadonnées cloud depuis leur introduction.

Le problème fondamental est que de nombreuses applications web acceptent des URLs fournies par l’utilisateur comme entrée — pour les aperçus d’URL, les webhooks, le traitement de documents, la récupération d’images ou les intégrations API — puis effectuent des requêtes HTTP vers ces URLs sans validation appropriée. Lorsqu’elles s’exécutent sur des instances EC2 avec IMDSv1 activé, elles deviennent des conduits pour l’exploitation du service de métadonnées.

La chaîne d’attaque IMDSv1

La chaîne d’attaque complète se déroule en plusieurs phases distinctes :

Phase 1 : Reconnaissance Les attaquants commencent par identifier les applications web hébergées sur EC2 via diverses techniques : - Analyse des enregistrements DNS et plages d’IP - Identification de l’infrastructure AWS via les en-têtes, messages d’erreur ou temporisation des réponses - Scan d’applications accessibles publiquement - Exploitation d’autres vulnérabilités pour obtenir un premier accès

Phase 2 : Découverte de vulnérabilités SSRF Les attaquants testent la présence de vulnérabilités SSRF en vérifiant les champs d’entrée utilisateur susceptibles de déclencher des requêtes HTTP côté serveur : - Paramètres URL dans les fonctionnalités d’aperçu ou de récupération - Points de configuration de webhooks - Mécanismes de téléchargement de fichiers acceptant des URLs - Points d’injection XXE (entités externes XML) - Vulnérabilités de redirection ouverte - Services de génération PDF

Phase 3 : Accès au service de métadonnées Une fois la vulnérabilité SSRF identifiée, les attaquants créent des requêtes ciblant le service de métadonnées :

https://application-vulnerable.com/preview?url=http://169.254.169.254/latest/meta-data/

L’application récupère cette URL et retourne les métadonnées, révélant les catégories d’informations disponibles.

Phase 4 : Extraction des identifiants IAM Les attaquants énumèrent les rôles IAM et extraient les identifiants :

http://169.254.169.254/latest/meta-data/iam/security-credentials/
→ Retourne : "ec2-production-role"

http://169.254.169.254/latest/meta-data/iam/security-credentials/ec2-production-role
→ Retourne : {
  "AccessKeyId": "ASIA...",
  "SecretAccessKey": "...",
  "Token": "...",
  "Expiration": "2024-12-08T01:23:45Z"
}

Phase 5 : Utilisation malveillante des identifiants Avec des identifiants AWS valides, les attaquants configurent le CLI AWS ou le SDK :

export AWS_ACCESS_KEY_ID=ASIA...
export AWS_SECRET_ACCESS_KEY=...
export AWS_SESSION_TOKEN=...

aws sts get-caller-identity
# Confirme l’identité et le rôle

Phase 6 : Escalade de privilèges et mouvement latéral Selon les permissions du rôle IAM, les attaquants peuvent : - Lister et accéder aux buckets S3 contenant des données sensibles - Énumérer d’autres ressources AWS - Lancer des instances EC2 supplémentaires - Modifier les groupes de sécurité et les contrôles d’accès réseau - Accéder aux bases de données, secrets et configurations - Pivot vers d’autres comptes AWS via l’assuming de rôle

Cas d’exploitation réel : étude de cas Capital One

La faille Capital One 2019 constitue une étude de cas définitive de l’exploitation IMDSv1. Les 22-23 mars 2019, un attaquant (plus tard identifié comme l’ancien employé AWS Paige Thompson) a exploité une mauvaise configuration du pare-feu d’application web (WAF) sur des instances EC2. La méthodologie d’attaque montre comment des défaillances organisationnelles combinées à des vulnérabilités techniques :

Chemin technique d’attaque : 1. Identification d’une configuration ModSecurity WAF permettant l’exécution de commandes 2. Exploitation d’une vulnérabilité SSRF dans l’application derrière le WAF 3. Accès au service de métadonnées à 169.254.169.254 4. Récupération du rôle IAM nommé *****-WAF-Role 5. Extraction des identifiants temporaires via le point de terminaison du rôle 6. Utilisation des identifiants pour lister les buckets S3 via AWS CLI 7. Synchronisation de plus de 700 buckets S3 contenant des données clients (~30 Go) 8. Exfiltration de 106 millions de dossiers clients, incluant : - 140 000 numéros de sécurité sociale - 80 000 numéros de comptes bancaires - 1 million de numéros d’assurance sociale canadiens - Informations personnelles étendues (noms, adresses, scores de crédit, historique de paiement)

Les défaillances cumulatives : - Mauvaise configuration du WAF permettant un accès non autorisé aux applications backend - Vulnérabilité SSRF dans l’application web non détectée - IMDSv1 fournissant un accès non authentifié aux identifiants - Rôle IAM trop permissif accordant un accès étendu à S3 - Absence de surveillance des sorties de données à grande échelle - La détection a pris près de quatre mois (découverte en juillet 2019)

Les conséquences : - Amende civile de 80 millions de dollars - Plus de 50 millions de dollars en amendes et règlements - Dégâts réputationnels inestimables - Actions collectives des clients affectés - Poursuites pénales contre l’attaquant

AWS a lancé IMDSv2 en novembre 2019, quelques mois après que la faille ait été rendue publique. La synchronisation n’était pas fortuite — l’incident Capital One a démontré de manière concluante que l’absence de protections en profondeur d’IMDSv1 créait un risque inacceptable.

Campagnes d’exploitation actives

La menace n’a pas diminué depuis 2019. Les chercheurs en sécurité continuent d’observer des campagnes actives ciblant IMDS :

Campagne mars 2025 : F5 Labs a documenté une campagne coordonnée ciblant des sites web hébergés sur EC2, exploitant spécifiquement des vulnérabilités SSRF pour accéder à IMDSv1. L’infrastructure utilisée provient des ASN français et roumain 34534 (FBW NETWORKS SAS), démontrant une organisation persistante et organisée.

Campagne UNC2903 (2021) : Mandiant a identifié le groupe de menace UNC2903 exploitant CVE-2021-21311 dans l’outil de gestion de base de données Adminer. Les attaquants utilisaient une relayeuse avec des scripts de redirection 301 pour piéger les serveurs victimes dans des redirections et exposer les identifiants AWS via IMDS.

Recherche continue sur les vulnérabilités : Les rapports de bug bounty HackerOne incluent régulièrement des vulnérabilités liées à IMDS, y compris des découvertes critiques affectant des organisations comme le Département de la Défense américain et DuckDuckGo, soulignant que les chaînes d’attaque SSRF vers IMDS restent exploitables et précieuses pour les attaquants.

Pourquoi IMDSv1 reste une cible critique

Le problème de la persistance

Malgré la disponibilité d’IMDSv2 depuis 2019 et son déploiement par défaut pour les nouvelles instances depuis novembre 2023, l’adoption reste alarmante faible. Plusieurs facteurs expliquent cette persistance :

Infrastructure héritée : Les organisations utilisant des instances EC2 anciennes de plusieurs années peuvent ne jamais avoir revu leur configuration de service de métadonnées. Ces instances longues durées continuent d’utiliser IMDSv1 sauf migration manuelle.

Compatibilité logicielle : Les anciennes SDK AWS, bibliothèques tierces et applications personnalisées peuvent ne pas supporter IMDSv2 avec son authentification par jeton, nécessitant des mises à jour de code.

Inertie organisationnelle : La migration nécessite une coordination entre développement, opérations et sécurité. Sans soutien exécutif ou pression réglementaire, ces initiatives sont reléguées en priorité inférieure.

Lacunes de connaissance : Beaucoup d’organisations ignorent les risques. Les équipes de développement, concentrées sur la fonctionnalité, peuvent ne pas comprendre les implications de sécurité au niveau de l’infrastructure.

Complexité perçue : Bien qu’AWS fournisse des outils de migration robustes, le processus demande un inventaire, des tests et un déploiement coordonné — des efforts concurrents avec d’autres priorités.

Le multiplicateur d’escalade de privilèges

Ce qui rend IMDSv1 particulièrement dangereux, c’est son rôle comme mécanisme d’escalade de privilèges. Une vulnérabilité SSRF mineure dans une application web à faible privilège peut instantanément donner aux attaquants tous les droits du rôle IAM de l’instance. Cela crée des scénarios où :

• Une simple fonctionnalité d’aperçu d’URL devient une porte d’accès à des bases de données de production
• Un point de test webhook expose le contenu des buckets S3
• Un service de traitement de fichiers donne accès à des systèmes de gestion de secrets
• Un outil de développement offre un accès administratif AWS

La frontière de sécurité s’effondre car le service de métadonnées ne distingue pas entre le code légitime et les requêtes contrôlées par l’attaquant.

La zone de vol de vol d’identifiants

Du point de vue de l’attaquant, l’exploitation d’IMDSv1 offre des avantages uniques :

Aucune authentification requise : Contrairement à la plupart des techniques de vol d’identifiants, accéder à IMDSv1 ne nécessite ni mot de passe, ni clé API, ni jeton d’authentification.

Temporaire mais suffisant : Bien que les identifiants soient temporaires (généralement valides 6-12 heures), cette fenêtre offre suffisamment de temps pour la reconnaissance, l’exfiltration de données et le mouvement latéral.

Difficulté de détection : L’accès aux identifiants via IMDS apparaît comme un comportement normal de l’instance, rendant difficile leur distinction du trafic légitime sans surveillance spécialisée.

Défis d’audit : IMDSv1 ne fournit pas de journalisation ou d’audit natifs. Les organisations manquent souvent de visibilité sur les processus accédant au service de métadonnées et quand.

Clés de contexte de politique : Les identifiants récupérés via IMDSv1 incluent la clé de contexte ec2:RoleDelivery: "1.0", utilisable dans les politiques IAM pour en limiter l’usage — mais seulement si ces politiques ont été mises en œuvre, ce qui est rarement le cas.

Stratégies de détection et de migration

Identifier l’utilisation d’IMDSv1

Les organisations doivent d’abord comprendre leur exposition actuelle à IMDSv1 avant de mettre en œuvre des protections. AWS fournit plusieurs mécanismes de détection :

Visibilité dans la console AWS : La console EC2 affiche une colonne “IMDSv2” indiquant la configuration de chaque instance. Les instances affichant “Optionnel” ont IMDSv1 activé, tandis que “Requis” indique une opération IMDSv2 uniquement.

Règles AWS Config : La règle gérée ec2-imdsv2-check surveille en continu la configuration du métadonnées et signale les instances non conformes.

AWS Security Hub : La règle EC2.8 (“Les instances Amazon EC2 doivent utiliser la version 2 du Service de Métadonnées d’Instance”) offre une visibilité centralisée, avec agrégation cross-région et consolidation organisationnelle.

Métriques CloudWatch : La métrique MetadataNoToken suit la fréquence des appels IMDSv1 par instance, aidant à identifier celles qui utilisent encore le service legacy.

Analyseur de paquets IMDS : Cet outil open-source AWS utilise la capture de paquets réseau pour identifier et enregistrer tous les appels IMDSv1 d’une instance, ciblant précisément les logiciels à mettre à jour.

Datadog Cloud Workload Security : Des solutions tierces comme Datadog CWS implémentent des règles de détection réseau qui identifient en temps réel les appels IMDSv1, dépassant les limitations des outils natifs AWS.

La feuille de route de migration

Une migration réussie vers IMDSv2 nécessite une planification et une exécution systématiques en trois phases :

Phase 1 : Évaluation et planification (Semaine 1-2)

1. Inventaire de l’état actuel : Utiliser AWS Config et Security Hub pour identifier toutes les instances IMDSv1 activées dans tous les comptes et régions.

2. Analyse des dépendances applicatives : Déployer l’analyseur de paquets IMDS sur des instances représentatives pour identifier les applications et bibliothèques accédant aux métadonnées.

3. Prioriser les charges critiques : Commencer par les déploiements neufs et les environnements non-production, puis progresser vers la production selon l’évaluation des risques.

4. Mettre à jour la pile logicielle : S’assurer que les SDK AWS, CLI et frameworks supportent IMDSv2 :

   • AWS CLI v2.x supporte nativement IMDSv2
   • SDK AWS post-2020 supportent IMDSv2
   • Mettre à jour les agents de gestion (SSM, CloudWatch)
   • Tester les applications personnalisées avec authentification par jeton

Phase 2 : Application progressive (Semaine 3-8)

1. Activer le support IMDSv2 : Configurer les instances pour supporter les deux versions tout en surveillant les problèmes :

   aws ec2 modify-instance-metadata-options \
   --instance-id i-1234567890abcdef0 \
   --http-tokens optional \
   --http-endpoint enabled
   

   1. Surveiller la transition : Surveiller les métriques CloudWatch MetadataNoToken pour repérer les appels IMDSv1 restants.
   2. Appliquer IMDSv2 : Une fois la utilisation d’IMDSv1 réduite à zéro, forcer IMDSv2 uniquement : bash aws ec2 modify-instance-metadata-options \ --instance-id i-1234567890abcdef0 \ --http-tokens required

2. Mettre à jour les modèles de lancement : Modifier les modèles de lancement EC2 et les configurations d’Auto Scaling pour exiger IMDSv2 pour les nouvelles instances :

   {
   "MetadataOptions": {
   "HttpTokens": "required",
   "HttpPutResponseHopLimit": 1,
   "HttpEndpoint": "enabled"
   }
   }
   

   Phase 3 : Application et prévention (en continu) 1. Mettre en œuvre des SCP : Empêcher l’utilisation IMDSv1 à l’échelle de l’organisation via AWS Organizations :

   {
   "Version": "2012-10-17",
   "Statement": [{
   "Sid": "RequireIMDSv2",
   "Effect": "Deny",
   "Action": "ec2:RunInstances",
   "Resource": "arn:aws:ec2:*:*:instance/*",
   "Condition": {
     "StringNotEquals": {
       "ec2:MetadataHttpTokens": "required"
     }
   }
   }]
   }
   

3. Bloquer l’utilisation des identifiants IMDSv1 : Utiliser des politiques IAM pour empêcher l’accès aux ressources sensibles avec des identifiants obtenus via IMDSv1 :

   {
   "Version": "2012-10-17",
   "Statement": [{
   "Sid": "RequireIMDSv2Credentials",
   "Effect": "Deny",
   "Action": "*",
   "Resource": "*",
   "Condition": {
     "NumericLessThan": {
       "ec2:RoleDelivery": "2.0"
     }
   }
   }]
   }
   

   1. Remédiation automatisée : Déployer des documents d’automatisation AWS Systems Manager comme EnforceEC2InstanceIMDSv2 pour configurer automatiquement les instances non conformes.

   2. Surveillance continue : Maintenir les règles Security Hub et les alarmes CloudWatch pour détecter toute régression vers la configuration IMDSv1.

      Défense en profondeur : Au-delà d’IMDSv2

      Alors qu’IMDSv2 répond aux attaques SSRF, une sécurité cloud complète nécessite des défenses en couches : Sécurité des applications :

   • Mettre en œuvre une validation robuste des entrées sur toutes les URLs utilisateur

   • Utiliser des listes blanches pour les domaines autorisés plutôt que des listes noires

   • Déployer des Web Application Firewalls avec des règles de détection SSRF

   • Effectuer des tests de sécurité réguliers, y compris des évaluations de vulnérabilités SSRF Principe du moindre privilège IAM :

   • Accorder aux rôles EC2 uniquement les permissions minimales nécessaires

   • Éviter les permissions génériques (s3:*, *:*)

   • Utiliser des permissions au niveau des ressources pour limiter la portée

   • Auditer et supprimer régulièrement les permissions inutilisées Segmentation réseau :

   • Mettre en œuvre des groupes de sécurité limitant le trafic sortant

   • Utiliser des points de terminaison VPC pour l’accès aux services AWS plutôt que le routage Internet

   • Déployer une surveillance réseau pour détecter des comportements de sortie inhabituels

   • Envisager de bloquer 169.254.169.254 au niveau Layer 3 si pertinent Surveillance et alerte :

   • Activer AWS CloudTrail pour tous les logs d’activité API

   • Configurer AWS GuardDuty pour la détection de menaces

   • Mettre en œuvre une gestion des événements et des informations de sécurité (SIEM)

   • Créer des alertes pour des modèles d’accès au service de métadonnées inhabituels

   • Surveiller les transferts de données importants vers des destinations externes Gestion des secrets :

   • Éviter de stocker des données sensibles dans S3 sans chiffrement

   • Utiliser AWS Secrets Manager ou Parameter Store pour les secrets

   • Mettre en œuvre des politiques de bucket S3 limitant l’accès

   • Activer la journalisation et la surveillance des buckets S3

     Leçons industrielles et perspectives d’avenir

     La réalité de la responsabilité partagée

     La faille Capital One a suscité un débat intense sur la responsabilité du fournisseur cloud versus celle du client. AWS maintient que la faille résulte de mauvaises configurations client — vulnérabilité SSRF, rôles IAM trop permissifs, configuration du pare-feu. Les critiques soutiennent qu’AWS connaissait les risques SSRF liés à IMDSv1 depuis 2018 mais n’a pas mis en place de mitigations avant une grande faille. La réalité est nuancée : la sécurité cloud est réellement partagée. AWS fournit les outils et des configurations sécurisées par défaut (comme IMDSv2), mais les clients doivent effectivement les utiliser. Comme l’a souligné Evan Johnson, ancien responsable de la sécurité produit chez Cloudflare : “Il y a beaucoup de connaissances spécialisées nécessaires pour exploiter un service dans AWS, et pour quelqu’un sans cette expertise, [les attaques SSRF] ne seraient pas visibles dans un guide de configuration critique.” Les organisations doivent reconnaître que l’adoption du cloud nécessite une expertise en sécurité qui dépasse l’infrastructure traditionnelle. Supposer que suivre la documentation AWS garantit la sécurité est faux — il faut comprendre le paysage des menaces, repérer les vulnérabilités architecturales, et mettre en œuvre une défense en profondeur.

     La timeline vers l’universalité d’IMDSv2

     AWS renforce progressivement les exigences IMDSv2 :

   • Novembre 2019 : IMDSv2 lancé

   • Novembre 2023 : La console Quick Start par défaut IMDSv2

   • Mi-2024 : Les nouveaux types d’instances EC2 utilisent IMDSv2 par défaut

   • En continu : AWS encourage la migration via documentation, outils, et contrôles au niveau du compte Cependant, la transition reste volontaire pour les instances existantes. AWS n’a pas annoncé de plans pour forcer la migration des instances legacy vers IMDSv2, probablement pour éviter de casser des charges de travail clients. Cela signifie que les organisations doivent prendre en charge leur propre migration.

     Apprendre d’autres failles

     L’exploitation d’IMDSv1 n’est pas spécifique à Capital One. Plusieurs organisations ont subi des failles similaires, même si beaucoup restent non divulguées en raison d’accords de règlement ou de divulgations incomplètes :

   • Les institutions financières ont corrigé discrètement des vulnérabilités SSRF vers IMDS

   • Les agences gouvernementales ont renforcé leur infrastructure cloud après des tests de pénétration réussis

   • Les entreprises technologiques ont découvert des vols d’identifiants via IMDS lors d’enquêtes d’incidents Le motif est cohérent : les vulnérabilités SSRF sont courantes, IMDSv1 est encore largement déployé, et la combinaison crée un risque critique.

     Conclusion : L’action est impérative

     Six ans après la faille Capital One, IMDSv1 reste une vulnérabilité critique affectant la majorité de l’infrastructure AWS. Malgré la disponibilité d’IMDSv2 et ses protections, l’adoption est lente, laissant les organisations exposées à des vecteurs d’attaque bien compris et activement exploités. L’impératif de sécurité est clair : chaque organisation utilisant EC2 doit migrer vers IMDSv2 et désactiver IMDSv1 complètement. Ce n’est pas une amélioration optionnelle — c’est une exigence fondamentale pour une hygiène de sécurité cloud, équivalente à appliquer des correctifs critiques ou à mettre en œuvre une authentification à plusieurs facteurs. Le processus de migration demande des efforts, une coordination, et des tests, mais l’alternative est d’accepter le risque de devenir la prochaine victime. Les outils, la documentation, et l’automatisation existent pour rendre cette transition gérable. Le seul ingrédient manquant, c’est l’engagement organisationnel.

     Votre plan d’action dès maintenant

     Cette semaine :

   • Exécuter la règle AWS Config ec2-imdsv2-check pour inventorier votre état actuel

   • Activer le contrôle AWS Security Hub EC2.8 pour une surveillance continue

   • Identifier et prioriser les charges critiques pour la migration Ce mois-ci :

   • Déployer l’analyseur de paquets IMDS sur des instances représentatives

   • Mettre à jour SDK, CLI, et dépendances AWS vers des versions compatibles IMDSv2

   • Commencer à appliquer IMDSv2 sur les environnements non-production Ce trimestre :

   • Finaliser la migration IMDSv2 pour toutes les instances en production

   • Mettre en œuvre des SCP empêchant la création de nouvelles instances IMDSv1

   • Déployer des politiques IAM bloquant l’utilisation des identifiants IMDSv1

   • Effectuer des tests de sécurité pour vérifier la protection SSRF La révolution cloud promet sécurité, évolutivité et simplicité. Le service de métadonnées AWS a tenu cette promesse — mais seulement si les organisations l’utilisent en toute sécurité. IMDSv1 était une conception acceptable en 2012. En 2024 et au-delà, c’est un risque inacceptable. La faille Capital One a coûté plus de 150 millions de dollars et exposé 106 millions de dossiers. La faille de votre organisation coûtera différemment, mais elle coûtera.

     Le choix vous appartient : migrer proactivement vers IMDSv2 selon votre calendrier, ou réagir après une faille. L’histoire montre quelle voie est la moins douloureuse.

     À propos de l’auteur : cette analyse est basée sur les dernières recherches en sécurité, la documentation AWS, et des rapports d’incidents réels en décembre 2024. Les organisations doivent consulter des professionnels en sécurité cloud qualifiés lors de la mise en œuvre de ces recommandations. Références : Blog sécurité AWS, Datadog Security Labs, Mandiant Threat Intelligence, OWASP Foundation, ACM Transactions on Privacy and Security