Des rôles par ci, des rôles par là, des rôles partout ! Explorons la sécurité d'AWS IAM Roles Anywhere

Résumé

Alors que les organisations s'appuient de plus en plus sur des applications, des appareils et des services pour interagir dans des environnements hybrides, les identités non humaines deviennent de plus en plus courantes. Pour permettre à ces identités un accès sécurisé aux ressources de l'organisation, Amazon Web Services (AWS) a lancé le service IAM Roles Anywhere, qui autorise les workloads situés en dehors d’AWS à s’authentifier à l’aide de certificats numériques plutôt que par des clés d’accès traditionnelles.

Le service AWS IAM Roles Anywhere offre plusieurs avantages en matière de sécurité et reste relativement simple à configurer, en particulier pour les organisations disposant déjà d’une infrastructure à clé publique (PKI). En règle générale, sa mise en œuvre exige toutefois une réflexion approfondie sur les principes de moindre privilège et sur la définition des autorisations d’accès lors de la conception de l’architecture. En l’absence de contrôles de sécurité adéquats et d’une approche de défense intégrée, une organisation pourrait, sans le vouloir, exposer son environnement cloud à des risques non maîtrisés.

Dans cet article, nous analysons les principaux risques liés à une configuration inadéquate ou à une conception architecturale déficiente lors de l’utilisation du service Roles Anywhere. Ces risques partagent une cause commune : la configuration par défaut du service, qui se révèle relativement permissive dans le contexte du compte AWS et de la région où le service est activé.

Nous analysons ces risques à la fois du point de vue d’un cyberattaquant et de celui d’une organisation. Cette exploration devrait aider les lecteurs à mieux comprendre les risques potentiels liés à l’utilisation de ce service, ainsi que les moyens dont disposent les organisations pour les atténuer.

Cortex Cloud vous protège contre les configurations erronées de l’infrastructure à clé publique (PKI) décrites dans cet article. Grâce à des règles basées sur les agents Cloud XDR ainsi qu’à des règles d’analyse comportementale, Cortex Cloud est capable de détecter et de bloquer les usages abusifs des politiques IAM, tout en automatisant la réponse via les capacités de la plateforme XSOAR.

Les organisations peuvent bénéficier d’un accompagnement pour évaluer leur posture de sécurité cloud grâce à l’évaluation de sécurité cloud d’Unit 42.

Si vous pensez avoir été compromis ou en cas de question urgente, contactez l’équipe de réponse à incident d’Unit 42.

Introduction

Roles Anywhere est un service de gestion des accès lancé en 2022. Il permet aux workloads externes de s’authentifier auprès d’AWS à l’aide de certificats numériques X.509. Cette fonctionnalité élimine le besoin de générer et gérer des identifiants à long terme pour ces workloads, rendant ainsi les opérations sur les API cloud plus sûres et plus simples à administrer dans les environnements AWS.

En d’autres termes, le service Roles Anywhere permet de définir quelles autorités de certification (CA) sont autorisées à valider les certificats des clients. Un certificat client signé par l’une de ces CA peut être utilisé pour :

• s’authentifier auprès d’AWS
• obtenir une identité cloud-native correspondante (sous forme d’identifiants temporaires)
• appeler les API cloud d’AWS comme d’habitude, en signant les requêtes à l’aide de ces identifiants temporaires

Composants et concepts clés

Le processus d'authentification se compose de plusieurs éléments essentiels :

• Points d’ancrage de confiance : un point d’ancrage de confiance est une ressource qui représente le certificat d’autorité de certification (CA) dans Roles Anywhere. Lors de la création d’un point d’ancrage, un certificat CA doit y être associé. Il existe deux types de point d’ancrage de confiance :
  • Le certificat ACM-PCA (AWS Certificate Manager – Private Certificate Authority), une ressource gérée par AWS.
  • Le bundle de certificats : un certificat X.509 encodé au format ASCII Privacy-Enhanced Mail (PEM), directement rattaché au point d’ancrage.
• Profils : ces ressources déterminent le niveau d’accès accordé à une entité authentifiée via Roles Anywhere. Chaque profil est associé à des rôles IAM (gestion et accès des identités) qui définissent les autorisations, ainsi qu’à des mécanismes supplémentaires permettant d’affiner ces droits d’accès.
• Rôles IAM : ces rôles sont associés aux véritables politiques IAM, qui octroient (ou restreignent) les autorisations d’accès aux ressources AWS.

En pratique, l’authentification via Roles Anywhere s’effectue en envoyant une requête vers le terminal /sessions. Cette requête est signée à l’aide de la clé privée du certificat et inclut, comme paramètres, l’Amazon Resource Name (ARN) de l’ancrage de confiance (Trust Anchor), ainsi que les ARN du profil et du rôle.

La manière la plus simple de composer cette requête consiste à utiliser l’outil aws_signing_helper. Cet utilitaire automatise le processus d’authentification et peut également rendre les identifiants disponibles localement en émulant le terminal de l’Instance Metadata Service, à l’image du fonctionnement des instances Amazon Elastic Compute Cloud (EC2).

La figure 2 présente des exemples de requêtes et de réponses dans le cadre de l’authentification avec Roles Anywhere.

Utilisation courante de Roles Anywhere

Pour mieux comprendre le processus de configuration de Roles Anywhere, prenons l’exemple suivant :

• Un pod Kubernetes situé en dehors d’AWS a besoin d’un accès pour lire des objets dans un bucket Amazon S3.
• L’ingénieur cloud émet un certificat et le signe à l’aide du certificat du point d’ancrage de confiance. Le certificat signé est ensuite stocké dans le pod, avec sa clé privée.
• L’ingénieur crée un rôle IAM comprenant les autorisations S3 nécessaires et l’associe à un profil Roles Anywhere.
• Le pod Kubernetes peut alors utiliser le certificat, ainsi que les identifiants liés au rôle et la clé privée, pour signer les requêtes, s’authentifier et lire les objets du bucket S3 configuré.

Sécurisation du processus d’authentification par défaut

Un aspect intéressant de ce processus d’authentification réside dans le fait qu’il n’existe, par défaut, aucune corrélation entre une ancre de confiance et un profil spécifique. Il est essentiel que les organisations comprennent les risques associés à cette configuration et configurentcorrectement les ressources Roles Anywhere ainsi que les politiques de confiance des rôles IAM.

Autrement dit, les organisations doivent veiller à ce que chaque certificat client soit signé par une ancre de confiance spécifique et destiné à un profil bien défini. Cela permet d’empêcher tout accès non autorisé à d’autres profils ou ancres de confiance au sein du même compte AWS et de la même région.

Pour illustrer les conséquences potentielles de ce processus, reprenons l’exemple du pod mentionné précédemment. Jusqu’ici, les étapes suivies sont légitimes. Le pod dispose exactement des autorisations dont il a besoin, ni plus ni moins.

Mais que se passerait-il si un attaquant parvenait à accéder au pod ? Si d'autres profils ont été créés dans le même compte et la même région AWS, l'attaquant pourrait utiliser le certificat pour obtenir un accès aux rôles associés à ces profils :

• L’attaquant pourrait déduire les ARN d’un autre rôle IAM rattaché au même profil, ou bien les ARN et les rôles associés à un autre profil. Déduire ces ARN est une opération complexe qui nécessite des autorisations supplémentaires dans l’environnement AWS. Nous aborderons ces techniques plus loin dans l’article.
• Une fois toutes les informations nécessaires réunies, l’attaquant peut formuler des requêtes afin d’obtenir des identifiants temporaires pour différents rôles, et exploiter leurs autorisations pour mener des opérations malveillantes.

AWS propose plusieurs moyens de restreindre l’accès via Roles Anywhere, notamment en utilisant des conditions dans la politique de confiance du rôle. Toutefois, la politique de confiance par défaut de Roles Anywhere ne comporte aucune condition dans sa déclaration. Cela signifie que tout environnement utilisant cette configuration par défaut ne bénéficie d’aucune restriction d’accès. Il incombe donc à chaque organisation de s’assurer qu’elle ne repose pas sur les paramètres par défaut pour la configuration de Roles Anywhere.

Lors de la création d’un rôle par défaut utilisé pour Roles Anywhere, la politique de confiance suivante est définie :

Cette politique indique que ce rôle peut être assumé par le service Roles Anywhere. Cependant, elle ne comporte aucune autre restriction quant aux sources autorisées à l’assumer. Cela signifie que si un rôle est associé à un profil, tout certificat signé par un ancrage de confiance dans la même région peut assumer ce rôle.

Pour remédier à cela, AWS a introduit la section Condition dans les politiques. Cette section permet d’imposer des restrictions supplémentaires aux ressources, en spécifiant les exigences qu’elles doivent remplir pour pouvoir exécuter une action donnée.

La politique suivante ajoute une section Condition à la politique par défaut, afin de restreindre l’accès au rôle via l’authentification Roles Anywhere uniquement à partir d’une autorité de confiance spécifique.

Pour restreindre encore davantage l’accès des certificats signés, nous recommandons d’utiliser la fonctionnalité de mappage des attributs de certificat. AWS recommande également cette approche dans la documentation de Roles Anywhere :

Concrètement, il est possible d’associer les attributs d’un certificat à des valeurs qui seront évaluées dans la politique de confiance. On peut ainsi restreindre l’accès à des rôles en fonction du nom commun (Common Name), de l’unité d’organisation ou de tout autre attribut présent dans le certificat.

Cette approche est vivement recommandée, car elle permet de garantir que, même si une ressource utilisant Roles Anywhere pour s’authentifier est compromise, elle ne pourra pas accéder à d’autres rôles.

La condition suivante combine la restriction par ancrage de confiance mentionnée précédemment avec une limitation d’accès fondée sur les attributs du certificat :

Comme pour tout autre service, le principe du moindre privilège doit être appliqué lors de la mise en place de l’infrastructure Roles Anywhere. L’utilisation du mappage des attributs du certificat permet de le mettre en œuvre efficacement.

La perspective de l’attaquant

Scénario n°1 – Utilisation de certificats et de clés privées valides par un attaquant

Comme indiqué précédemment, les éléments suivants sont nécessaires pour s’authentifier via Roles Anywhere :

• Le certificat client
• La clé privée associée au certificat client
• L’ARN de l’ancrage de confiance ayant signé le certificat
• L’ARN d’un profil situé dans la même région
• L’ARN d’un rôle IAM attaché à ce profil

Dans le scénario suivant, un attaquant compromet une configuration par défaut de Roles Anywhere en s’emparant d’un certificat client utilisé pour l’authentification, ainsi que de sa clé privée. Pour exploiter cette configuration par défaut à des fins malveillantes et accéder à d’autres rôles dans le compte, l’attaquant doit encore découvrir les ARN des ressources concernées afin de pouvoir s’authentifier auprès d’AWS. Or, obtenir ces ARN n’est pas une tâche facile : cela nécessite des privilèges supplémentaires et indépendants au sein du compte.

Les techniques suivantes peuvent être utilisées pour obtenir ces informations :

Utilisation des actions de Roles Anywhere: Un attaquant ayant obtenu des autorisations suffisantes sur le service Roles Anywhere peut tout simplement exécuter des actions permettant de récupérer les ARN nécessaires. Il peut, par exemple, utiliser les actions list-trust-anchors et list-profiles, qui requièrent respectivement les autorisations rolesanywhere:ListTrustAnchors et rolesanywhere:ListProfiles. La sortie de ces commandes fournit tous les ARN requis pour formuler une requête d’authentification, puisque la commande list-profiles retourne également tous les rôles associés au profil.

Exploitation des données des journaux: CloudTrail est le principal mécanisme de journalisation d'AWS. Un attaquant disposant d’un accès indépendant aux journaux CloudTrail (ou aux services de stockage qui les hébergent) pourrait identifier des éléments créés par le service Roles Anywhere. Certains journaux CloudTrail contiennent en effet tous les ARN nécessaires au processus d’authentification. Les événements générés par plusieurs actions du service Roles Anywhere révèlent ces ARN dans les journaux.

Le journal le plus pertinent est CreateSession. Il est généré lorsque le service Roles Anywhere est utilisé pour l’authentification, c’est-à-dire lorsqu’il crée des informations d’identification temporaires et les envoie à l’utilisateur. La figure 3 montre un exemple d’entrée de journal CreateSession et met en évidence l’ARN associé.

Les ARN d’un point d’ancrage de confiance, d’un profil et de l’un des rôles qui lui sont associés apparaissent dans ce journal d’événement. Si le certificat de l’attaquant a été signé par le point d’ancrage indiqué dans le journal, il pourra l’utiliser pour s’authentifier.

La figure 5 présente une illustration détaillée des étapes suivies par l’attaquant.

Scénario n° 2 – Exploitation de permissions directes sur le service Roles Anywhere

Un autre scénario dans lequel une configuration par défaut du service Roles Anywhere peut être exploitée survient lorsqu’un attaquant accède à une identité disposant de permissions sur ce service. Ces autorisations peuvent être accordées via une instruction Allow directe sur le service, ou de manière indirecte à travers un élément NotAction.

Les étapes suivantes peuvent être utilisées pour exploiter ces permissions :

• L’attaquant accède à une identité disposant d’une configuration et de permissions par défaut sur le service Roles Anywhere.
• Il crée deux certificats - un certificat d’autorité de certification (CA) et un certificat client - puis utilise le certificat CA pour signer le certificat client. Étant à l’origine de la création, l’attaquant détient également les clés privées associées à ces certificats.
• L’attaquant utilise l’identité compromise pour créer un point d’ancrage de confiance et y associe le certificat CA.
• Grâce aux permissions de type « list » sur le service Roles Anywhere, il récupère les ARN des profils et des rôles IAM.
• En combinant ces ARN, le certificat client et sa clé privée, l’attaquant procède à l’authentification via Roles Anywhere.
• Si la politique de confiance du rôle IAM refuse l’accès, l’attaquant peut consulter les « Subjects » Roles Anywhere pour identifier les détails d’un certificat précédemment utilisé pour l’authentification, puis reproduire ses champs dans un nouveau certificat client.

Plus précisément, un attaquant disposant de permissions suffisantes sur Roles Anywhere peut créer un certificat, le signer avec son propre certificat CA, puis l’associer à une nouvelle ancre de confiance ou à une ancre existante. Cela nécessite les permissions rolesanywhere:CreateTrustAnchor ou rolesanywhere:UpdateTrustAnchor.

Étant donné que l’attaquant contrôle à la fois le certificat client et le certificat CA, le certificat sera considéré comme valide. L’étape suivante consiste à identifier les profils et les rôles disponibles en utilisant la commande list-profiles du service Roles Anywhere ou l’une des autres techniques évoquées précédemment.

Avec ces informations, l’attaquant peut générer des identifiants via Roles Anywhere et effectuer des opérations dans le contexte du rôle utilisé.

Si les mesures de sécurité de l’organisation ciblée ne détectent pas l’activité malveillante, ce processus peut également servir de vecteur de persistance : l’ancre de confiance permet en effet de générer des identifiants valides tant que le problème n’est pas corrigé.

Mesures d’atténuation et recommandations

• Nous recommandons vivement d’ajouter des conditions à la politique de confiance par défaut des rôles utilisés avec Roles Anywhere. Comme mentionné précédemment, la politique par défaut autorise toute ancre de confiance à assumer le rôle. Il est donc essentiel de restreindre l’accès à ce rôle à une seule ancre de confiance : celle utilisée pour authentifier la charge de travail concernée.

Des conditions supplémentaires doivent également être mises en place afin de limiter l’accès uniquement aux certificats présentant certains attributs, comme Common Name ou Organization. Toutefois, ces conditions ne constituent pas une solution miracle et peuvent être contournées dans certains cas, par exemple si un attaquant parvient à extraire les informations d’attributs à partir du certificat.

• Nous recommandons d’utiliser des ancres de confiance de type ACM-PCA. Ce faisant, même un attaquant disposant d’un accès complet au service Roles Anywhere ne pourra pas téléverser son propre certificat CA dans l’ancre de confiance. Le type d’ancre ne pouvant pas être modifié, des autorisations ACM-PCA spécifiques (et rarement attribuées) seront nécessaires pour authentifier une entité.
  • Il s'agit là d'un point crucial. Si les rôles censés être assumés par les ancres de confiance utilisent la condition mentionnée dans le point précédent, ils ne pourront pas être accessibles. Il convient toutefois de noter que les autorités de certification privées dans AWS présentent leurs propres considérations de sécurité et peuvent elles aussi constituer un risque si elles ne sont pas correctement configurées.
• Les autorisations doivent toujours être attribuées selon le principe du moindre privilège. L’authentification via Roles Anywhere est généralement accordée à des identités non humaines, et les dispositifs qui utilisent ce service ont en principe des tâches spécifiques et prédéfinies à accomplir. Par conséquent, le niveau d’accès de ces identités ne doit pas dépasser les exigences strictes liées aux tâches qui leur sont assignées. En complément des rôles IAM eux-mêmes, il est également possible d’associer une politique de session à un profil. Cette politique définit les autorisations maximales qu’un rôle peut obtenir lorsqu’il est assumé via Roles Anywhere.
• Surveillez et tracez régulièrement les ressources AWS IAM Roles Anywhere : il est essentiel de maintenir une surveillance continue des ancres de confiance, des profils et des ressources associées. Étant donné que les ancres de confiance et les profils ne sont pas créés fréquemment, leur création ou leur modification constitue un événement potentiellement suspect. Toute modification inattendue de ces ressources doit être immédiatement analysée afin de vérifier qu’aucune activité non autorisée n’est en cours. Des audits réguliers et des alertes automatisées permettent de détecter et de traiter rapidement d’éventuelles menaces de sécurité.
• Exécutez la requête XQL suivante dans Cortex Query Builder pour identifier les rôles qui font confiance au service Roles Anywhere sans appliquer de conditions de restriction.

Conclusion

Cet article a examiné les principaux risques liés à l’utilisation des configurations par défaut du service Roles Anywhere d’AWS, tant du point de vue d’un attaquant potentiel que de celui d’un défenseur. Nous avons présenté plusieurs stratégies d’atténuation que les organisations devraient mettre en œuvre pour mieux gérer ces risques. Nous espérons que cette analyse aidera les lecteurs à mieux comprendre les vulnérabilités potentielles associées à la configuration par défaut de ce service, ainsi que les meilleures pratiques pour les atténuer.

Un enseignement clé de cet article est qu’il est essentiel, lors de l’utilisation de services proposés par des fournisseurs cloud, de bien comprendre leur configuration et leur architecture, plutôt que de s’y fier aveuglément.

• Appliquer les bonnes pratiques de sécurité, le principe du moindre privilège et une approche de défense intégrée.
• Cela permet de garantir que les services sont correctement architecturés et surveillés en cas de modification de leur configuration.
• La mise en place d’une surveillance en temps réel contribue à assurer la sécurité des environnements cloud personnalisés.

Cortex Cloud vous protège contre les configurations erronées de l’infrastructure à clé publique (PKI) décrites dans cet article. Grâce à des règles basées sur les agents Cloud XDR ainsi qu’à des règles d’analyse comportementale, Cortex Cloud est capable de détecter et de bloquer les usages abusifs des politiques IAM, tout en automatisant la réponse via les capacités de la plateforme XSOAR.

Les organisations peuvent bénéficier d’un accompagnement pour évaluer leur posture de sécurité cloud grâce à l’évaluation de sécurité cloud d’Unit 42.

Si vous pensez avoir été compromis ou en cas de question urgente, prenez contact avec l’équipe de réponse à incident d’Unit 42 ou appelez les numéros suivants :

• Amérique du Nord : Gratuit : +1 (866) 486-4842 (866.4.UNIT42)
• ROYAUME-UNI : +44.20.3743.3660
• Europe et Moyen-Orient : +31.20.299.3130
• Asie : +65.6983.8730
• Japon : +81.50.1790.0200
• Australie : +61.2.4062.7950
• Inde : 00080005045107

Palo Alto Networks a partagé ces résultats avec les membres de la Cyber Threat Alliance (CTA). Les membres de la CTA utilisent ces renseignements pour déployer rapidement des mesures de protection auprès de leurs clients et pour perturber systématiquement les cyberacteurs malveillants. En savoir plus sur la Cyber Threat Alliance.

Ressources complémentaires

• Le principe du moindre privilège : les explications- Palo Alto Networks
• Le modèle de confiance IAM de Roles Anywhere - Documentation officielle d'Amazon Web Services