AWS est une cible de choix pour les attaquants. Sa popularité grandissante et son rôle stratégique en font un service attractif.
Pour limiter les risques, il est crucial de mettre en place des mesures de sécurité robustes. Comprendre les types d’attaques et évaluer leur impact est tout aussi essentiel.
Plusieurs méthodes permettent d’évaluer la sécurité d’une infrastructure AWS. Dans cet article, nous présentons l’approche offensive : les tests d’intrusion AWS (pentest AWS). Nous expliquons les principes et les objectifs ainsi que la méthodologie d’un audit AWS à travers un exemple concret.
Guide complet sur le pentest AWS
- En quoi consiste un pentest AWS ?
- Périmètre d’un pentest AWS
- Méthodologie et déroulement d’un pentest AWS
- Audit en boite blanche d’un pipeline CI/CD sur AWS
- Réaliser un pentest AWS avec Vaadata, entreprise spécialisée en sécurité offensive
En quoi consiste un pentest AWS ?
Un pentest AWS vise à évaluer la sécurité des services et des ressources hébergés sur un environnement cloud Amazon Web Services (AWS).
Ce type d’audit simule des cyberattaques pour identifier les vulnérabilités exploitables dans l’infrastructure et les configurations des ressources AWS, telles que les instances EC2, les bases de données, les applications déployées, et les conteneurs.
L’objectif est de détecter les failles de sécurité potentielles, d’évaluer leurs impacts, et de fournir des recommandations pour renforcer la sécurité de l’environnement cible.
Périmètre d’un pentest AWS
Le périmètre d’un pentest AWS est adaptable en fonction des besoins spécifiques de l’organisation. Il est possible de tester l’ensemble des services et configurations de votre infrastructure AWS ou de se concentrer sur les éléments les plus critiques.
Ainsi, les tests couvrent (liste non exhaustive) :
- Instances EC2 : identification de services mal sécurisés, de logiciels obsolètes ou de mauvaises configurations.
- Bases de données : accès non autorisés, gestion incorrecte des permissions, fuites de données potentielles, etc.
- Services de stockage S3 : expositions de données sensibles, mauvaise gestion des accès, configurations de partage inappropriées, etc.
- IAM (Identity and Access Management) : analyse des rôles et des permissions, contrôle d’accès défaillant, etc.
- Applications web et APIs hébergées : recherche de vulnérabilités spécifiques aux applications comme les injections (SQL, XSS, etc.), les exécutions de code à distance (RCE), etc.
- Conteneurs et services serverless (ECS, EKS, Lambda) : vérification des configurations, isolation des conteneurs, accès aux environnements et fuites de données.
Pour plus d’informations, vous pouvez consulter notre article qui explore les vulnérabilités courantes des infrastructures cloud.
Méthodologie et déroulement d’un pentest AWS
Pour présenter la méthodologie d’un pentest AWS, mettons-nous dans la peau d’un attaquant cherchant à compromettre la société « Elicorp ».
Et notre objectif est de compromettre la base de données de l’infrastructure AWS. Voyons cela étape par étape.
Reconnaissance et découverte de l’infrastructure AWS
Dans cette phase initiale, l’attaquant se concentre sur la collecte d’informations sur EliCorp, en particulier les services AWS potentiellement exposés.
L’objectif est d’identifier des éléments exploitables sans interagir directement avec les systèmes de manière intrusive.
Recherche de sous-domaines et découverte de services exposés
L’attaquant commence par collecter des informations sur les sous-domaines d’EliCorp. Ceux-ci peuvent révéler des points d’entrée potentiels dans l’infrastructure.
En utilisant des outils comme amass et subfinder, il est possible de recenser les sous-domaines publics, notamment ceux qui pourraient être hébergés sur AWS.
# Utilisation de amass pour la recherche de sous-domaines
amass enum -d elicorp.com -o sous-domaines.txtAnalyse des services ouverts
En scannant les sous-domaines trouvés avec nmap, l’attaquant cherche à identifier les ports ouverts et services exposés, comme des instances EC2 ou des API sur AWS Gateway, qui pourraient fournir des informations sur la configuration ou être vulnérables à des attaques spécifiques.
# Scan des sous-domaines avec Nmap pour les ports ouverts
nmap -iL sous-domaines.txt -p- -T4 -oN scan_ouvert.txtRecherches spécifiques aux services AWS
En complément, des outils comme CloudMapper sont utilisés pour découvrir des erreurs de configuration publique sur AWS, comme des buckets S3 mal sécurisés ou des failles dans les groupes de sécurité EC2.
Ces éléments pourraient être accessibles en utilisant des politiques publiques.
Exploitation des faiblesses de configuration et collecte d’informations
Cette phase consiste à exploiter des erreurs de configuration pour accéder à des ressources sensibles et obtenir des informations essentielles pour progresser vers l’objectif final ; à savoir compromettre la base de données.
Accès aux buckets S3 publics
Les buckets S3 mal configurés peuvent contenir des données sensibles comme des fichiers de configuration, des journaux ou même des clés API.
L’attaquant utilise awscli pour identifier les permissions sur chaque bucket trouvé et voir si des objets sont accessibles publiquement.
# Vérification des permissions d'accès public sur chaque bucket
for bucket in $(cat buckets_elicorp.txt); do
aws s3api get-bucket-acl --bucket $bucket
aws s3 ls s3://$bucket --recursive
doneLors de l’inspection des fichiers S3, l’attaquant découvre un fichier de configuration contenant une clé d’API AWS qui semble correspondre à un utilisateur IAM ayant certaines permissions.
Exploitation de la clé d’API compromise
En exportant la clé d’API trouvée, l’attaquant teste ses permissions pour voir si cette clé donne accès à des services sensibles comme les bases de données RDS ou l’IAM.
Cette phase vise à comprendre jusqu’où cette clé d’API peut être utilisée pour escalader les privilèges.
export AWS_ACCESS_KEY_ID=AKIXXXXXXXXXXXXXXX
export AWS_SECRET_ACCESS_KEY=XXXXXXXXXXXXXXXXXXXX# Tester des permissions de base pour découvrir des privilèges IAM
aws iam get-user
aws iam list-attached-user-policies --user-name compromised_userLa clé d’API dispose de permissions restreintes, mais autorise des actions sur les services IAM et RDS, un point d’entrée possible pour des étapes de compromission plus avancées.
# Tester les permissions avec l'API IAM
aws iam get-userElevation de privilèges
L’objectif de cette phase est d’augmenter l’accès de l’attaquant dans l’infrastructure AWS en exploitant des faiblesses dans les permissions IAM.
Enumération des permissions et rôles IAM
En utilisant les permissions limitées de la clé API, l’attaquant énumère les rôles et politiques IAM pour identifier des permissions plus permissives. Il cible particulièrement les rôles ayant accès aux instances RDS (bases de données).
# Récupérer la liste des rôles pour identifier les cibles potentielles
aws iam list-roles
aws iam list-role-policies --role-name <role_name>Après énumération, l’attaquant découvre un rôle ayant la permission rds:DescribeDBInstances, lui permettant d’obtenir des informations critiques sur les bases de données de l’entreprise.
Usurpation de rôle IAM
Si l’attaquant trouve un rôle IAM vulnérable, il peut utiliser la technique d’usurpation de rôle pour obtenir davantage de permissions.
# Assumer un rôle (si autorisé) pour escalader les permissions
aws sts assume-role --role-arn arn:aws:iam::123456789012:role/VulnerableRole --role-session-name pentestSessionCompromission de la base de données
Ayant obtenu des informations d’identification et des permissions d’accès aux services RDS, l’attaquant passe à l’attaque directe sur les bases de données.
Avec rds:DescribeDBInstances, l’attaquant obtient des informations sur l’endpoint de l’instance de base de données, le type de moteur (MySQL, PostgreSQL, etc.) et les configurations de sécurité, y compris le type de pare-feu et les règles de groupe de sécurité.
aws rds describe-db-instances –query 'DBInstances[*].[Endpoint.Address,DBInstanceStatus]'En utilisant des identifiants découverts dans le fichier de configuration précédemment obtenu, l’attaquant se connecte directement à l’instance RDS pour extraire des données sensibles.
# Connexion à la base de données avec MySQL
mysql -h <db_instance_endpoint> -u <db_user> -p<db_password>Une fois connecté, l’attaquant peut exécuter des requêtes pour lister les tables et obtenir des données sensibles, comme les informations clients ou les transactions financières.
SHOW TABLES;
SELECT * FROM clients WHERE sensitive_data=true;Corriger et prévenir les vulnérabilités et exploitations malveillantes sur AWS
Il est essentiel de revoir les pratiques de sécurité d’EliCorp afin de renforcer la protection de l’infrastructure AWS et d’éviter les attaques similaires.
Restreindre l’accès aux environnements sensibles
La phase de reconnaissance a révélé des points d’entrée publics, comme des instances de staging accessibles sur Internet.
Ces environnements de staging, de développement ou de test ne devraient pas être exposés publiquement. EliCorp pourrait limiter l’accès aux environnements de staging en utilisant des groupes de sécurité AWS pour restreindre les adresses IP autorisées, ou en mettant en place des VPN pour que seuls les utilisateurs authentifiés puissent y accéder.
Appliquer le principe du moindre privilège dans IAM
Le pentest a révélé que certaines clés d’API et rôles IAM avaient des permissions excessives, y compris un accès à des ressources critiques comme les instances RDS.
Le principe du moindre privilège implique de limiter les permissions IAM à celles strictement nécessaires pour chaque utilisateur, service ou application. Par ailleurs, il est essentiel de revoir régulièrement les rôles et politiques IAM et de révoquer les accès superflus.
Sécuriser les buckets S3
Des fichiers sensibles ont été trouvés dans des buckets S3 publics, ce qui a permis d’obtenir des informations compromettantes.
Les buckets S3 devraient être configurés pour n’autoriser l’accès qu’aux utilisateurs et services spécifiques.
EliCorp devrait aussi activer les journaux d’accès pour surveiller toute tentative d’accès aux buckets S3.
Stocker les secrets de manière sécurisée
Durant le pentest, des secrets (comme des clés d’API) étaient stockés dans des fichiers de configuration accessibles publiquement.
Les secrets et informations sensibles ne doivent jamais être en clair dans les fichiers de configuration. AWS Secrets Manager ou AWS Parameter Store offrent une gestion sécurisée des secrets en limitant l’accès et en utilisant un chiffrement.
Limiter l’accès aux bases de données RDS
L’accès direct aux instances RDS a été permis par une configuration de groupe de sécurité trop permissive.
En restreignant les groupes de sécurité et en utilisant les options de VPC (Virtual Private Cloud) pour isoler les bases de données, EliCorp pourrait réduire le risque de compromission.
Audit en boite blanche d’un pipeline CI/CD sur AWS
Lors d’une de missions, un de nos clients nous a sollicité pour examiner son pipeline CI/CD sur AWS.
En partant d’un accès limité à GitLab, nous avons découvert et exploité des vulnérabilités ; qui nous ont notamment permis d’élever nos privilèges et d’accéder à des données sensibles.
Pour en savoir plus, vous pouvez consulter notre write-up dédié : Audit en boite blanche d’un pipeline CI/CD sur AWS.
Réaliser un pentest AWS avec Vaadata, entreprise spécialisée en sécurité offensive
Il est important d’évaluer le niveau de résistance de votre infrastructure AWS face aux attaques décrites dans cet article.
Cette évaluation peut être réalisée par l’un des audits que nous proposons. Qu’elle soit réalisée en boite noire, grise ou blanche, nous vous proposons d’identifier toutes les vulnérabilités de votre infrastructure AWS et de vous accompagner dans leur correction.
Auteur : Amin TRAORÉ – CMO @Vaadata