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.
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.
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) :
Pour plus d’informations, vous pouvez consulter notre article qui explore les vulnérabilités courantes des infrastructures cloud.
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.
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.
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.txtEn 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.txtEn 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.
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.
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.
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-userL’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.
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.
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 pentestSessionAyant 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;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.
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.
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.
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.
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.
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.
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.
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
