Exploitation du Service de Métadonnées AWS : Exposer IMDSv1 et Voler

Comment SSRF et Mauvaises Configurations Exposent IMDSv1, Donnant aux Attaquants l’Accès aux Identifiants IAM et à Tout votre Royaume AWS

La révolution du cloud promettait sécurité, évolutivité et simplicité. Pourtant, au sein de l’infrastructure AWS se cache un service apparemment inoffensif qui est devenu la clé maîtresse de nombreuses brèches cloud : le Service de Métadonnées d’Instance (IMDS). Lorsqu’il est exploité via des attaques de Server-Side Request Forgery (SSRF) et des mauvaises configurations, IMDSv1 peut donner aux attaquants les clés de tout votre royaume AWS — avec des identifiants IAM, des métadonnées d’instance, et un accès sans restriction à des ressources sensibles.

L’exemple le plus célèbre ? La brèche de Capital One en 2019, où plus de 100 millions de dossiers clients ont été exposés, entraînant une amende de 80 millions de dollars et une atteinte à la réputation difficile à mesurer. L’attaque n’était pas sophistiquée — elle exploitait une vulnérabilité bien comprise que de nombreuses organisations continuent de négliger aujourd’hui.

Qu’est-ce que le Service de Métadonnées d’Instance AWS ?

Le Service de Métadonnées d’Instance est un point d’API accessible depuis les instances EC2 AWS à l’adresse IP 169.254.169.254. Il fournit des informations cruciales dont les applications et services tournant sur EC2 ont besoin pour fonctionner correctement, notamment :

Détails de l’instance : nom d’hôte, ID d’instance, configuration réseau
Identifiants de rôle IAM : clés temporaires et jetons de session
Données utilisateur : scripts personnalisés et configurations
Groupes de sécurité : règles d’accès réseau

Ce service est essentiel pour les opérations AWS. Les applications utilisent IMDS pour récupérer des identifiants temporaires liés aux rôles IAM, évitant ainsi de coder en dur des clés d’accès AWS — une amélioration de sécurité significative lorsqu’il est utilisé correctement.

IMDSv1 vs IMDSv2 : Une Division Critique en Sécurité

AWS propose deux versions du Service de Métadonnées d’Instance, et comprendre la différence est crucial :

IMDSv1 (Version Legacy) : - Utilise un protocole simple requête-réponse - Nécessite uniquement des requêtes HTTP GET - Pas d’authentification ni de gestion de session - Vulnérable aux attaques SSRF - Toujours activé par défaut sur de nombreuses instances

IMDSv2 (Version Sécurisée) : - Orienté session avec authentification par jeton - Nécessite une requête PUT initiale pour générer un jeton de session - Le jeton doit être inclus dans un en-tête personnalisé (X-aws-ec2-metadata-token) - Protection basée sur TTL contre les attaques au niveau réseau - Mitige efficacement les vulnérabilités SSRF

Le problème ? Malgré la migration d’AWS pour faire d’IMDSv2 le paramètre par défaut pour les nouvelles instances depuis novembre 2023, des recherches montrent qu’en 2022, environ 93% des instances EC2 n’appliquaient toujours pas IMDSv2. De nombreuses organisations continuent d’utiliser IMDSv1, s’exposant aux mêmes vecteurs d’attaque qui ont permis la brèche de Capital One.

L’Anatomie d’une Attaque d’Exploitation d’IMDS

Pour comprendre pourquoi IMDSv1 est si dangereux, examinons comment les attaquants l’exploitent via des vulnérabilités SSRF.

Étape 1 : Reconnaissance

Les attaquants commencent par scanner les applications vulnérables tournant sur l’infrastructure AWS. Ils recherchent : - Applications web avec champs de saisie utilisateur - Instances exposées avec des services accessibles publiquement - Applications effectuant des requêtes HTTP basées sur des URLs fournies par l’utilisateur - Mauvaises configurations de Web Application Firewalls (WAF)

Étape 2 : Découverte des Vulnérabilités SSRF

Le Server-Side Request Forgery se produit lorsqu’une application peut être trompée pour faire des requêtes HTTP vers des destinations non prévues. Les scénarios vulnérables courants incluent :

Paramètres URL : applications qui récupèrent du contenu à partir d’URLs fournies par l’utilisateur
Traitement d’images : services qui téléchargent et traitent des images depuis des sources externes
Webhooks : systèmes qui appellent des endpoints spécifiés par l’utilisateur
Générateurs PDF : outils qui rendent du contenu web en PDF
Téléversement de fichiers : applications traitant des fichiers uploadés contenant des références externes

Étape 3 : Accès au Service de Métadonnées

Une fois la vulnérabilité SSRF identifiée, les attaquants l’exploitent pour accéder à l’endpoint de métadonnées :

# Accès direct à IMDS (fonctionne uniquement depuis une instance EC2)
curl http://169.254.169.254/latest/meta-data/

# Via vulnérabilité SSRF dans une application vulnérable
http://vulnerable-app.com/fetch?url=http://169.254.169.254/latest/meta-data/

Étape 4 : Extraction des Identifiants IAM

Le vrai but est d’obtenir les identifiants du rôle IAM :

# Lister les rôles IAM disponibles
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

# Récupérer les identifiants pour un rôle spécifique
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/[nom-du-rôle]

Cela retourne des données JSON contenant : - AccessKeyId : clé d’accès AWS - SecretAccessKey : clé secrète AWS - Token : jeton de session - Expiration : expiration des identifiants

Étape 5 : Utilisation des Identifiants Volés

Avec ces identifiants, les attaquants peuvent : - Lister et accéder à des buckets S3 contenant des données sensibles - Lancer de nouvelles instances EC2 pour du minage ou d’autres attaques - Modifier des groupes de sécurité et configurations réseau - Accéder à des bases de données et autres services AWS - Exfiltrer des données vers des destinations externes - Établir des mécanismes de persistance

Impact Réel : La Brèche Capital One

La brèche Capital One 2019 illustre le potentiel dévastateur de l’exploitation d’IMDS. Voici ce qui s’est passé :

Chronologie de l’Attaque : - 22-23 mars 2019 : Paige Thompson, ex-employée AWS, a exploité une vulnérabilité SSRF dans le Web Application Firewall de Capital One - Vulnérabilité exploitée : Un composant WAF mal configuré a permis des attaques SSRF vers le service de métadonnées - Identifiants volés : Thompson a obtenu des identifiants temporaires AWS via le rôle IAM de l’instance EC2 - Données accessibles : En utilisant ces identifiants, elle a listé plus de 700 buckets S3 et téléchargé environ 30 Go de données - 19 juillet 2019 : La brèche a été découverte après que Thompson en ait parlé sur GitHub et IRC

Les Dégâts : - 106 millions de dossiers clients exposés (100 millions US, 6 millions canadiens) - 140 000 numéros de sécurité sociale compromis - 80 000 numéros de comptes bancaires divulgués - 1 million de numéros d’assurance sociale canadiens exposés - Informations personnelles incluant noms, adresses, scores de crédit et données de transaction - 80 millions de dollars d’amende par les autorités réglementaires - Plus de 150 millions de dollars de coûts totaux incluant la remédiation et la perte de confiance - Dégâts réputationnels graves et chute du cours en bourse

Les Causes Profondes : 1. Vulnérabilité SSRF dans l’application WAF 2. IMDSv1 en usage au lieu d’IMDSv2 plus sécurisé 3. Rôles IAM trop permissifs avec un accès large à S3 4. Données non chiffrées stockées dans des buckets S3 5. Surveillance insuffisante ayant retardé la détection de quatre mois

L’aspect le plus préoccupant ? Cette attaque n’a pas nécessité de techniques sophistiquées — juste l’exploitation de vulnérabilités bien comprises qui auraient dû être atténuées.

Campagnes d’Exploitation Récentes et Menaces Émergentes

L’exploitation d’IMDS ne se limite pas à l’histoire ancienne. Des campagnes actives continuent de cibler des infrastructures AWS vulnérables :

Campagne de mars 2025

Des chercheurs en sécurité ont détecté une campagne nouvelle ciblant des sites web hébergés sur des instances EC2 via des vulnérabilités SSRF. La campagne a principalement exploité :

CVE-2017-9841 : Exécution de code à distance PHPUnit (15x plus active que la CVE en deuxième position)
CVE-2024-4577 : Tendance à une activité croissante
CVE-2019-9082 : Augmentation régulière des tentatives d’exploitation

La campagne provenait d’adresses IP appartenant à l’ASN 34534 (FBW NETWORKS SAS), avec une infrastructure d’attaque basée en France et en Roumanie. Les attaquants ont utilisé des techniques SSRF simples pour interroger les endpoints IMDSv1 et extraire des identifiants.

Exploitation de CVE-2025-51591 dans Pandoc

En septembre 2025, la société de sécurité Wiz a découvert des attaquants exploitant une vulnérabilité dans Pandoc (convertisseur de documents populaire) pour cibler IMDS. La vulnérabilité permettait d’inclure des éléments iframe avec des attributs src pointant vers le service de métadonnées.

L’attaque a finalement échoué grâce à l’application d’IMDSv2, démontrant l’importance cruciale de passer à la version plus récente. Cependant, ces efforts continus montrent que les attaquants cherchent activement de nouveaux vecteurs SSRF pour exploiter IMDS.

Acteur de menace UNC2903

En juin 2021, le groupe de menace UNC2903 a exploité une vulnérabilité dans l’outil de gestion de base de données Adminer en utilisant une technique de redirection astucieuse. Ils ont mis en place des relais avec des scripts de redirection 301 pour tromper les serveurs victimes en suivant des redirections qui renvoyaient des erreurs contenant des identifiants API AWS. Les identifiants récoltés donnaient accès aux comptes AWS des victimes.

Pourquoi IMDSv1 Reste un Risque Critique

Malgré la disponibilité d’IMDSv2 depuis 2019, IMDSv1 continue de poser des risques importants :

Vulnérabilités Techniques

Aucune Authentification Requise : IMDSv1 utilise des requêtes GET non authentifiées, ce qui le rend trivial à exploiter dès qu’une vulnérabilité SSRF est trouvée.

Protocole Request-Response : Le schéma simple requête-réponse en fait une cible parfaite pour les attaques SSRF, car les attaquants n’ont qu’à forcer le serveur à faire des requêtes HTTP GET.

Pas d’En-têtes Spécifiques : Contrairement à IMDSv2, aucun en-tête personnalisé n’est nécessaire, rendant l’exploitation possible même avec des vulnérabilités SSRF basiques.

Défis Organisationnels

Systèmes Hérités : Des instances de longue durée peuvent avoir des applications ne supportant que IMDSv1, compliquant la migration.

Manque de Conscience : Beaucoup d’organisations ne comprennent pas les implications de sécurité entre IMDSv1 et IMDSv2.

Paramètres par Défaut : Bien qu’AWS ait modifié les paramètres par défaut pour les nouvelles instances, l’infrastructure existante conserve souvent la compatibilité IMDSv1.

Environnements Complexes : Les déploiements AWS à grande échelle peuvent compter des milliers d’instances, rendant la migration exhaustive difficile.

Détection et Identification

Avant de pouvoir corriger le problème, il faut identifier où IMDSv1 est encore utilisé :

Via la Console AWS

Accédez au tableau de bord EC2 et vérifiez la colonne “IMDSv2” pour chaque instance. Les instances affichant “Optionnel” ont IMDSv1 activé.

Règles AWS Config

Déployez la règle AWS Config ec2-imdsv2-check, qui marque comme NON_CONFORME si HttpTokens est réglé sur “optionnel” (signifiant IMDSv1 activé).

Métriques CloudWatch

Surveillez la métrique MetadataNoToken dans CloudWatch, qui suit les appels IMDSv1. Des valeurs nulles indiquent que l’instance est prête à exiger IMDSv2 exclusivement.

AWS Security Hub

Configurez Security Hub avec une agrégation inter-régions et inter-comptes pour identifier les instances IMDSv1 dans toute votre organisation AWS.

Analyseur de Paquets IMDS

Utilisez l’outil d’analyse de paquets IMDS d’AWS pour identifier précisément quels composants logiciels font des appels IMDSv1, afin de prioriser les mises à jour.

Stratégies Complètes de Mitigation

Protéger contre l’exploitation d’IMDS nécessite une approche multi-couches :

1. Imposer IMDSv2 Immédiatement

Pour les Nouvelles Instances :

# Lancer une instance avec IMDSv2 requis
aws ec2 run-instances \
  --image-id ami-xxxxx \
  --instance-type t3.micro \
  --metadata-options HttpTokens=required,HttpPutResponseHopLimit=1

Pour les Instances Existantes :

# Exiger IMDSv2 sur une instance existante
aws ec2 modify-instance-metadata-options \
  --instance-id i-xxxxx \
  --http-tokens required \
  --http-put-response-hop-limit 1

Avec Terraform :

resource "aws_instance" "exemple" {
  ami           = "ami-xxxxx"
  instance_type = "t3.micro"
  
  metadata_options {
    http_tokens                 = "required"
    http_put_response_hop_limit = 1
    http_endpoint               = "enabled"
  }
}

2. Appliquer le Principe du Moindre Privilège aux Rôles IAM

Ne jamais attribuer des rôles IAM avec des permissions larges. Suivez ces principes :

N’accorder que les permissions minimales nécessaires à la fonction de l’instance
Utiliser des ARNs de ressources spécifiques plutôt que des jokers
Mettre en œuvre des clés de condition IAM pour restreindre l’utilisation des identifiants
Auditer régulièrement et limiter les permissions via l’Access Advisor

Utiliser les Clés de Condition IAM :

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::sensitive-bucket/*",
    "Condition": {
      "StringEquals": {
        "ec2:RoleDelivery": "2.0"
      }
    }
  }]
}

Cette politique garantit que seuls les identifiants récupérés via IMDSv2 peuvent accéder au bucket S3.

3. Désactiver IMDS si non nécessaire

Pour les instances n’ayant pas besoin d’accès IMDS :

aws ec2 modify-instance-metadata-options \
  --instance-id i-xxxxx \
  --http-endpoint disabled

4. Mettre en œuvre des Protections au Niveau Réseau

Configuration WAF : - Déployer AWS WAF avec des règles pour détecter et bloquer les tentatives SSRF - Mettre en œuvre une validation stricte des entrées - Surveiller les modèles suspects ciblant les endpoints de métadonnées

Sécurité VPC : - Utiliser des groupes de sécurité pour restreindre le trafic sortant - Mettre en œuvre une segmentation réseau - Déployer des endpoints VPC pour les services AWS afin d’éviter le routage Internet

5. Sécuriser le Code Applicatif

Validation des Entrées : - Ne jamais faire confiance aux entrées utilisateur pour les requêtes HTTP - Mettre en œuvre des listes blanches pour les domaines autorisés - Rejeter les requêtes vers des plages IP privées (y compris 169.254.x.x) - Valider et nettoyer tous les paramètres URL

Analyseur d’URL :

from urllib.parse import urlparse

def url_sûre(url):
    parsed = urlparse(url)
    
    # Bloquer IP privées et service de métadonnées
    ips_bloquées = ['169.254.169.254', '127.0.0.1', 'localhost']
    if parsed.hostname in ips_bloquées:
        return False
    
    # Autoriser uniquement certains domaines
    domaines_autorisé = ['trusted-domain.com']
    if parsed.hostname not in domaines_autorisé:
        return False
    
    return True

6. Activer une Surveillance Complète

AWS GuardDuty : Activer GuardDuty pour détecter des usages inhabituels de credentials et des tentatives de vol de credentials IMDS.

CloudTrail : Surveiller pour : - Appels API inhabituels depuis des instances EC2 - Utilisation de credentials depuis des emplacements inattendus - Transferts de données importants vers des destinations externes - Modifications des rôles et politiques IAM

AWS Security Hub : Agrégateur de résultats à travers comptes et régions pour maintenir une visibilité sur la posture de sécurité.

7. Mettre en œuvre des Politiques de Contrôle de Service

Pour AWS Organizations, appliquer IMDSv2 au niveau organisationnel :

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

Cette SCP empêche le lancement d’instances sans application d’IMDSv2 dans toute votre organisation.

La Voie à Suivre : Bonnes Pratiques de Migration

Passer d’IMDSv1 à IMDSv2 nécessite une planification minutieuse :

Phase 1 : Évaluation (Semaines 1-2)

Inventorier toutes les instances EC2 par région et compte
Identifier celles utilisant IMDSv1
Documenter les applications et services sur chaque instance
Évaluer la compatibilité logicielle avec IMDSv2

Phase 2 : Tests (Semaines 3-4)

Mettre à jour les SDK AWS, CLI, et outils pour supporter IMDSv2
Tester les applications en environnement non-production avec IMDSv2 activé
Surveiller les métriques MetadataNoToken pendant les tests
Identifier et mettre à jour les scripts personnalisés utilisant IMDSv1

Phase 3 : Migration Progressive (Semaines 5-8)

Commencer par des charges de travail non critiques
Activer IMDSv2 tout en laissant IMDSv1 optionnel
Surveiller les problèmes sur plusieurs jours
Passer aux charges de travail en production une fois la compatibilité confirmée

Phase 4 : Application (Semaine 9 et suivantes)

Exiger IMDSv2 sur toutes les instances migrées
Mettre en œuvre des SCP empêchant IMDSv1
Instaurer une surveillance continue
Documenter les leçons apprises et mettre à jour les runbooks

Compatibilité Logicielle

Les outils AWS modernes supportent IMDSv2 : - SDK AWS (tous les principaux langages) - AWS CLI v2 - Agent AWS Systems Manager - Agent Amazon ECS - Amazon Linux 2023 (par défaut IMDSv2 uniquement)

Pour les applications legacy, envisagez la containerisation ou la mise à jour vers des versions compatibles avant d’appliquer IMDSv2.

Au-Delà d’AWS : Perspective Multi-Cloud

Bien que cet article se concentre sur AWS, des services de métadonnées similaires existent chez d’autres fournisseurs cloud :

Google Cloud Platform : - Service de métadonnées à 169.254.169.254 - Nécessite l’en-tête Metadata-Flavor: Google - L’exigence de cet en-tête offre une protection SSRF similaire à IMDSv2

Microsoft Azure : - Service de métadonnées à 169.254.169.254 - Nécessite l’en-tête Metadata: true - La version API doit être spécifiée dans l’URL

Oracle Cloud Infrastructure : - Service de métadonnées avec authentification renforcée - Contrôles d’accès multi-couches

Ces fournisseurs ont implémenté des protections basées sur les en-têtes plus tôt qu’AWS, soulignant l’importance d’une approche de défense en profondeur.

Conclusion : Il est Temps d’Agir

Le Service de Métadonnées d’Instance AWS reste une surface d’attaque critique que les organisations ne peuvent pas se permettre d’ignorer. Bien qu’IMDSv1 ait posé les bases pour des opérations cloud sécurisées lors de son lancement en 2012, l’évolution du paysage des menaces l’a rendu obsolète et dangereux.

La brèche Capital One a montré que des vulnérabilités SSRF combinées à IMDSv1 créent une tempête parfaite pour les attaquants — une qui a coûté plus de 150 millions de dollars et exposé 106 millions de dossiers clients. Les campagnes récentes montrent que les attaquants continuent de rechercher activement de nouvelles vulnérabilités SSRF pour exploiter IMDS, avec de nouveaux vecteurs d’attaque qui émergent régulièrement.

La bonne nouvelle : AWS fournit des outils de mitigation robustes via IMDSv2, et des contrôles de sécurité complets sont disponibles pour protéger votre infrastructure cloud.

La mauvaise nouvelle : La majorité des organisations n’ont pas encore mis en œuvre ces protections, s’exposant aux mêmes attaques qui ont dévasté d’autres.

L’impératif : Chaque jour où vous utilisez IMDSv1 est un jour où vous donnez aux attaquants potentiels une clé skeleton pour votre royaume cloud. La brèche Capital One a eu lieu en 2019 — six ans plus tard, il n’y a aucune excuse pour ne pas avoir migré vers IMDSv2.

Actions Immédiates à Entreprendre

Cette semaine : Inventorier toutes les instances EC2 et identifier celles utilisant IMDSv1
Ce mois : Déployer des règles AWS Config et Security Hub pour une surveillance continue
Ce trimestre : Finaliser la migration vers IMDSv2 pour toutes les instances
En continu : Imposer IMDSv2 pour toutes les nouvelles instances via SCPs
Surveillance continue : Auditer, surveiller et améliorer les permissions des rôles IAM

La clé skeleton de votre royaume AWS est en pleine vue. Allez-vous la sécuriser avant que les attaquants ne la découvrent, ou votre organisation deviendra-t-elle la prochaine histoire à ne pas suivre ?

Ressources Supplémentaires

Mots-clés : AWS IMDS, IMDSv1, IMDSv2, attaques SSRF, sécurité EC2, service de métadonnées AWS, brèche Capital One, sécurité cloud, identifiants IAM, service de métadonnées d’instance, bonnes pratiques de sécurité AWS, server-side request forgery, exploitation cloud, vulnérabilité AWS, vol d’identifiants EC2