cyber / pentest-red-team
Sécurité offensive du cloud : misconfigurations courantes
Explication
Ce que vous allez apprendre
- Identifier un bucket de stockage cloud mal configuré en accès public
- Comprendre le risque des métadonnées d'instance EC2 et la protection apportée par IMDSv2
- Reconnaître une politique IAM permettant une auto-élévation de privilèges
- Utiliser des scanners de configuration cloud déclaratifs, sans risque pour les données
- Appliquer le principe du moindre privilège à un environnement cloud complet
Dans quel contexte ?
Une entreprise migre progressivement son infrastructure vers AWS et découvre, lors d'un audit de sécurité sur un compte de lab dédié, qu'un bucket S3 contenant des sauvegardes de base de données est accessible en lecture publique depuis Internet, sans aucune authentification requise. Ce type d'incident illustre un changement fondamental : dans le cloud, la surface d'attaque se déplace largement du code applicatif vers la configuration de l'infrastructure elle-même.
D'abord, l'erreur de configuration la plus visible : le stockage public
Un bucket S3, GCS ou Azure Blob mal configuré peut être listé et lu par n'importe qui, sans identifiants (--no-sign-request avec l'AWS CLI). C'est souvent une erreur de configuration involontaire plutôt qu'un choix délibéré — mais l'impact est identique à une fuite de données volontaire une fois découvert par un tiers malveillant.
Prérequis
Cette leçon suppose une connaissance de base du SSRF, vue dans une leçon précédente de ce parcours, car elle est directement liée au vol de métadonnées d'instance présenté ici.
| Mauvaise configuration cloud | Risque principal |
|---|---|
| Bucket de stockage public | Fuite de données, parfois des sauvegardes complètes |
| IMDSv1 activé | Vol de credentials IAM temporaires via SSRF |
| Policy IAM trop permissive | Auto-élévation de privilèges par un rôle applicatif |
| Secrets committés dans un repo Git | Accès direct à l'infrastructure via le pipeline CI/CD |
Une fois ce risque identifié, un autre est souvent plus critique encore : les métadonnées d'instance
Chaque instance EC2 expose un service de métadonnées interne (169.254.169.254) qui distribue notamment des identifiants IAM temporaires. Si une application souffre d'une vulnérabilité SSRF, un attaquant peut forcer le serveur à interroger lui-même cette adresse et récupérer ces identifiants — une chaîne d'attaque particulièrement efficace car elle combine deux vulnérabilités de nature différente.
Piège courant
Beaucoup de comptes cloud plus anciens utilisent encore IMDSv1, qui ne requiert aucun jeton pour interroger les métadonnées. IMDSv2 corrige structurellement cette faille en exigeant un jeton obtenu via une requête PUT préalable, ce qu'un SSRF classique ne peut généralement pas reproduire facilement. Vérifier ce paramètre est un des premiers réflexes d'un audit cloud.
Il reste un dernier vecteur à comprendre : l'escalade de privilèges via IAM
Un rôle applicatif capable de créer ses propres clés d'accès (iam:CreateAccessKey) ou de modifier ses propres policies peut s'auto-élever en droits administrateur complet, même s'il n'a initialement qu'un accès très limité en apparence. Ce type de chemin d'escalade est souvent invisible sans un outil dédié qui simule les permissions effectives (aws iam simulate-principal-policy).
Bonne pratique
Utilise des outils déclaratifs comme Prowler ou ScoutSuite, qui auditent la configuration exposée via l'API cloud sans jamais toucher aux données réelles. Combinés à IMDSv2 obligatoire et à un scan automatisé de secrets à chaque push Git, ces contrôles réduisent structurellement la surface d'attaque cloud, indépendamment de la qualité du code applicatif.
Après avoir couvert l'ensemble des dimensions techniques de ce parcours red team — du poste utilisateur jusqu'au cloud — la dernière leçon aborde le livrable qui donne toute sa valeur à ce travail auprès d'un client : la rédaction d'un rapport de pentest professionnel.
Commandes & code
Sécurité offensive du cloud : misconfigurations courantes
Les environnements cloud (AWS, Azure, GCP) déplacent la surface d'attaque vers la configuration plutôt que vers le code, testé ici sur des comptes de lab dédiés (ex: environnements sandbox AWS).
# S3 bucket mal configuré : lecture/écriture publique
aws s3 ls s3://bucket-cible-lab --no-sign-request
aws s3 cp s3://bucket-cible-lab/backup.sql . --no-sign-request
# --no-sign-request : aucune credential nécessaire si le bucket autorise l'accès anonyme# Métadonnées d'instance EC2 : source classique de vol de credentials IAM temporaires (via SSRF, ex. leçon 6)
curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/
curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/nom-du-role
# IMDSv2 (avec token obligatoire) corrige structurellement cette classe d'attaque, IMDSv1 reste vulnérable# IAM trop permissif : un rôle avec des policies larges permet une escalade de privilèges cloud
aws iam list-attached-role-policies --role-name app-role
aws iam simulate-principal-policy --policy-source-arn arn:aws:iam::123456789012:role/app-role --action-names iam:CreateAccessKey
# Un rôle applicatif capable de créer ses propres clés d'accès peut s'auto-élever en droits admin# Table : erreurs de configuration cloud les plus fréquentes en audit
- Buckets de stockage publics par erreur (S3, GCS, Azure Blob)
- IMDSv1 activé au lieu d'IMDSv2 (vol de credentials IAM via SSRF)
- Rôles IAM avec des policies "*:*" bien trop larges pour le besoin réel
- Secrets/API keys committés en clair dans un repo Git relié au pipeline CI/CD
- Security Groups/NSG ouverts à 0.0.0.0/0 sur des ports sensibles (22, 3389, bases de données)# Scanner de configuration cloud (principe : audit déclaratif, pas d'exploitation active)
# ScoutSuite / Prowler analysent la configuration exposée via l'API cloud, sans toucher aux données
prowler aws --check s3_bucket_public_access,iam_policy_allows_privilege_escalation# Principe du moindre privilège appliqué au cloud (mitigation structurelle)
- Chaque rôle IAM ne doit avoir que les actions strictement nécessaires à sa fonction
- IMDSv2 obligatoire + hop limit réduit sur les instances EC2
- Chiffrement par défaut + blocage de l'accès public au niveau du compte (S3 Block Public Access)
- Scan automatisé de secrets sur chaque push (git-secrets, trufflehog) intégré au pipeline CI/CDRésumé
- Le cloud déplace le risque du code vers la configuration : IAM, réseau et stockage en priorité.
- SSRF + IMDSv1 reste une des chaînes d'attaque les plus critiques en environnement cloud non durci.
- Des outils déclaratifs (Prowler, ScoutSuite) auditent la configuration sans risque pour les données.
- Le moindre privilège appliqué à chaque rôle IAM limite structurellement l'impact d'une compromission.
Exercices pratiques
Mission : auditer le compte AWS de lab NordShield
Objectif : Identifier une chaîne d'attaque combinant SSRF et métadonnées d'instance, et évaluer un risque d'escalade IAM.
Contexte
NordShield migre vers AWS. Un audit sur un compte sandbox dédié révèle un bucket S3 potentiellement mal configuré et une application vulnérable à la SSRF (vue dans une mission précédente).