Les chercheurs en sécurité ont découvert une attaque par confusion de nom qui permet l’accès à un compte Amazon Web Services à toute personne qui publie une Amazon Machine Image (AMI) avec un nom spécifique.
Baptisée « whoAMI », l’attaque a été conçue par des chercheurs de DataDog en août 2024, qui ont démontré qu’il était possible pour les attaquants d’obtenir l’exécution de code au sein des comptes AWS en exploitant la façon dont les projets logiciels récupèrent les ID AMI.
Amazon a confirmé la vulnérabilité et a apporté un correctif en septembre, mais le problème persiste côté client dans les environnements où les organisations ne parviennent pas à mettre à jour le code.
Exécution de l’attaque whoAMI
Les AMI sont des machines virtuelles préconfigurées avec les logiciels nécessaires (système d’exploitation, applications) utilisés pour créer des serveurs virtuels, appelés instances EC2 (Elastic Compute Cloud) dans l’écosystème AWS.
Il existe des AMI publiques et privées, chacune avec un identifiant spécifique. Dans le cas des AMI publiques, les utilisateurs peuvent rechercher dans le catalogue AWS le bon ID de l’AMI dont ils ont besoin.
Pour vous assurer que l’AMI provient d’une source fiable sur AWS Marketplace, la recherche doit inclure l’attribut « propriétaires », sinon le risque d’une attaque de confusion de nom whoAMI augmente.
L’attaque whoAMI est possible en raison d’une sélection d’AMI mal configurée dans les environnements AWS:
- La récupération des AMI par logiciel à l’aide de l’API ec2:DescribeImages sans spécifier de propriétaire
- L’utilisation de caractères génériques par les scripts au lieu d’ID AMI spécifiques
- La pratique de certains outils d’infrastructure en tant que code comme Terraform utilisant « most_recent = true », sélectionnant automatiquement la dernière AMI qui correspond au filtre.
Ces conditions permettent aux attaquants d’insérer des AMI malveillantes dans le processus de sélection en nommant la ressource de manière similaire à une ressource de confiance. Sans spécifier de propriétaire, AWS renvoie toutes les AMI correspondantes, y compris celles de l’attaquant.
Si le paramètre « most_recent » est défini sur « true », le système de la victime fournit les dernières AMI ajoutées à la place de marché, qui peuvent inclure une AMI malveillante portant un nom similaire à une entrée légitime.
Fondamentalement, tout ce qu’un attaquant doit faire est de publier une AMI avec un nom qui correspond au modèle utilisé par les propriétaires de confiance, ce qui permet aux utilisateurs de la sélectionner facilement et de lancer une instance EC2.
L’attaque whoAMI ne nécessite pas de violation du compte AWS de la cible. L’attaquant n’a besoin que d’un compte AWS pour publier son backdoor AM I dans le catalogue public d’AMI de la Communauté et choisir stratégiquement un nom qui imite les AMI de ses cibles.
Datadog indique que d’après sa télémétrie, environ 1% des organisations surveillées par l’entreprise sont vulnérables aux attaques whoAMI, mais « cette vulnérabilité affecte probablement des milliers de comptes AWS distincts. »
Mesures de réponse et de défense d’Amazon
Les chercheurs de DataDog ont informé Amazon de la faille et la société a confirmé que les systèmes internes hors production étaient vulnérables à l’attaque whoAMI.
Le problème a été résolu l’année dernière le 19 septembre et le 1er décembre, AWS a introduit un nouveau contrôle de sécurité nommé « AMI autorisées » permettant aux clients de créer une liste d’autorisations de fournisseurs d’AMI de confiance.
AWS a déclaré que la vulnérabilité n’avait pas été exploitée en dehors des tests des chercheurs en sécurité, de sorte qu’aucune donnée client n’a été compromise via des attaques whoAMI.
Amazon conseille aux clients de toujours spécifier les propriétaires d’AMI lors de l’utilisation de l’API « ec2:DescribeImages » et d’activer la fonctionnalité « AMI autorisées » pour une protection supplémentaire.
La nouvelle fonctionnalité est disponible via AWS Console → EC2 → Attributs de compte → AMI autorisées.
Depuis novembre dernier, Terraform 5.77 a commencé à envoyer des avertissements aux utilisateurs lorsque « most_recent = true » est utilisé sans filtre propriétaire, avec une application plus stricte prévue pour les futures versions (6.0).
Les administrateurs système doivent auditer leur configuration et mettre à jour leur code sur les sources AMI (Terraform, AWS CLI, Python Boto3 et Go AWS SDK) pour une récupération sûre des AMI.
Pour vérifier si des AMI non approuvées sont actuellement utilisées, activez le mode d’audit AWS via « AMI autorisées » et passez en « Mode d’application » pour les bloquer.
DataDog a également publié un scanner pour vérifier le compte AWS pour les instances créées à partir d’AMI non fiables, disponible dans ce référentiel GitHub.