English
Español
Français
Deutsch
日本語
한국어
العربيةLa carte d'escalade de privilèges AWS
Points clés
- Nous avons construit une référence des permissions AWS qu'un attaquant peut enchaîner vers les droits admin, les données ou la persistance, avec une page pour chacune.
- Chaque entrée porte les mêmes quatre éléments : comment la permission est utilisée, les événements CloudTrail qui l'attrapent, la technique MITRE ATT&CK, et le contrôle qui supprimerait le chemin.
- Plus de la moitié des entrées d'escalade de privilèges passent par iam:PassRole. C'est la permission qui touche le plus de services.
- Certaines permissions escaladent à elles seules. Beaucoup n'escaladent qu'en combinaison, détenues avec d'autres. Ces combinaisons toxiques sont celles qu'un examen politique par politique manque.
- Savoir qu'une permission est dangereuse n'est pas la même chose que savoir qu'elle est dangereuse dans votre compte. Cela demande une validation par rapport à votre autorisation réelle, et une décision de contexte métier sur le caractère porteur ou non de la permission.
Demandez à dix ingénieurs AWS quelles permissions sont dangereuses et vous obtiendrez dix listes courtes. Tout le monde cite iam:PassRole. La plupart citent les modifications de politiques. Après cela, ça devient flou, parce que la vraie réponse est longue, elle change à mesure qu'AWS livre de nouveaux services, et l'essentiel du danger réside dans les combinaisons plutôt que dans les actions isolées.
Alors nous l'avons écrit. La carte d'escalade de privilèges AWS est une page pour chaque permission qu'un attaquant peut enchaîner vers l'accès administrateur, les données, ou un moyen de revenir. Vous pouvez la parcourir par service, par technique, ou par combinaison de permissions, et chaque entrée se lit de la même façon.
Ce que contient chaque page
Chaque entrée répond à quatre questions. Comment la permission est-elle utilisée, seule ou uniquement aux côtés d'autres. Comment la voyez-vous, sous la forme des événements CloudTrail qui enregistrent l'appel. Où se situe-t-elle dans le manuel de l'attaquant, sous la forme de la technique MITRE ATT&CK. Et qu'est-ce qui supprimerait le chemin, sous la forme du contrôle qu'un défenseur pourrait appliquer. La page dessine le mouvement comme une chaîne, du principal attaquant jusqu'à ce que la permission atteint, avec l'action API réelle à chaque étape.
Un chemin, étape par étape
Prenez le mouvement ci-dessus, celui sur lequel reposent plus de la moitié des entrées d'escalade de privilèges. Lues comme deux instructions de politique distinctes, ni l'une ni l'autre ne paraît dangereuse. Enchaînées, elles exécutent du code attaquant en tant que rôle qui n'a jamais été accordé au principal.
- Étape 1. Commencez comme un principal ordinaire. Un rôle de développeur ou de CI qui détient lambda:CreateFunction et iam:PassRole suffit. Rien ici n'est encore administrateur.
- Étape 2. Créez une fonction avec du code attaquant (lambda:CreateFunction). Le corps de la fonction est ce que l'attaquant veut exécuter.
- Étape 3. Passez-lui un rôle privilégié (iam:PassRole). Pointez la fonction vers un rôle doté de plus d'accès que le principal, par exemple un rôle qui peut lire chaque bucket ou attacher des politiques.
- Étape 4. Invoquez-la, et le code s'exécute en tant que ce rôle. Le principal a emprunté un accès qui ne lui a jamais été accordé, et c'est là toute l'escalade.
- Étape 5. La coupe : limitez iam:PassRole à des ARN de rôles spécifiques et fixez iam:PassedToService. Ce seul changement ferme ce chemin et une grande partie du reste de la carte, car chaque service qui exécute du code pour vous accepte un rôle transmis de la même manière.
Ce n'est qu'une entrée. La carte dessine la même chaîne pour chaque permission qu'elle couvre, afin que vous puissiez voir le mouvement avant de décider si la permission est porteuse dans votre propre compte.
iam:PassRole est le fil conducteur
Parmi les entrées d'escalade de privilèges de la carte, plus de la moitié reposent sur iam:PassRole. Elle apparaît dans des chemins qui atteignent deux douzaines de services différents, car chaque service qui exécute du code pour vous acceptera un rôle que vous lui remettez. Lambda, EC2, ECS, Glue, SageMaker, CodeBuild, Step Functions et les autres prennent tous un rôle transmis et s'exécutent en tant que ce rôle. C'est pourquoi une seule autorisation iam:PassRole sur une ressource générique vaut plus pour un attaquant que presque toute autre permission. Limitez-la à des ARN de rôles spécifiques et fixez iam:PassedToService, et une grande partie de la carte se ferme d'un coup.
Permissions isolées et combinaisons toxiques
Certaines permissions escaladent à elles seules. iam:AttachUserPolicy avec une ressource assez large escalade à elle seule. Mais beaucoup des chemins les plus dangereux nécessitent deux permissions ou plus détenues ensemble, et aucune ne paraît alarmante seule. iam:PassRole est inoffensive sans une action de service pour l'utiliser. lambda:CreateFunction est inoffensive sans rôle à transmettre. Détenez les deux et vous avez du code arbitraire qui s'exécute en tant que rôle privilégié.
Ces combinaisons toxiques sont celles qui passent au travers de l'examen, parce qu'un audit de politiques qui examine une instruction à la fois ne voit jamais la paire. La carte étiquette chaque entrée comme directement exploitable ou comme combinaison toxique, et vous pouvez filtrer pour n'afficher que les combinaisons.
Pourquoi une liste de permissions ne dit pas tout
Une référence comme celle-ci vous dit quelles permissions peuvent être dangereuses. Elle ne peut pas vous dire lesquelles sont dangereuses dans votre compte. Cela dépend de qui détient réellement la permission, de la concordance des politiques de confiance et des conditions, de l'existence d'une SCP qui la bloque déjà, et du caractère privilégié ou non du rôle qu'elle atteint. La même permission peut être porteuse dans un compte et pur risque dans un autre.
La carte est donc délibérément prudente quant au correctif. Chaque page montre le contrôle qui supprimerait le chemin, puis indique clairement que la décision de l'appliquer relève du métier, et non d'un changement automatique. Retirer une permission dont dépend un pipeline est une forme de panne à part entière.
Comment l'utiliser
Partez d'un service que vous exploitez et lisez ses entrées. Recherchez une permission que vous êtes sur le point d'accorder et voyez ce qu'elle ouvre. Saisissez deux permissions pour vérifier si, ensemble, elles forment un chemin. Chaque page relie les événements de détection sur lesquels vous pouvez alerter dès aujourd'hui et la technique MITRE pour votre propre cartographie, de sorte que la carte est utile que vous soyez en train de durcir, de détecter ou de modéliser les menaces.
Comment Pathbreak l'utilise
La carte est la version publique de ce sur quoi Pathbreak raisonne à l'intérieur de votre compte. Nous nous connectons en lecture seule, résolvons vos politiques IAM, rôles et relations de confiance réels, et confirmons lesquels de ces chemins existent réellement pour vos identités. Ensuite, nous les classons selon l'ampleur de ce que chacun ouvre et, avec votre modèle de menace et votre contexte métier, montrons quels rares changements coupent le plus. Les premiers chemins validés reviennent dans l'heure.
Questions fréquentes
Quelle est la permission IAM AWS la plus dangereuse ?
iam:PassRole est la permission la plus réutilisée dans les chemins d'escalade de privilèges. Accordée sur une ressource générique, elle permet à un principal de remettre un rôle privilégié à un service qu'il peut exécuter, tel que Lambda ou EC2, et d'hériter de ce rôle. Elle est dangereuse en combinaison avec une action de service plutôt qu'à elle seule, ce qui explique en partie pourquoi elle est si souvent laissée trop large. La carte d'escalade de privilèges AWS de Pathbreak montre chaque combinaison qui la transforme en chemin.
Qu'est-ce qu'une combinaison toxique de permissions ?
C'est un ensemble de deux permissions ou plus qui sont sûres individuellement mais accordent une escalade lorsqu'un même principal les détient ensemble. iam:PassRole plus lambda:CreateFunction en est un exemple classique. Les examens qui vérifient une instruction de politique à la fois les manquent, parce que le risque est dans l'association, pas dans l'une ou l'autre permission seule. La carte Pathbreak les signale comme des combinaisons toxiques.
Comment savoir lesquelles de ces permissions sont réellement dangereuses dans mon compte ?
Vous les validez par rapport à votre autorisation réelle. Une permission ne forme un chemin que si un principal la détient réellement, que les politiques de confiance et les conditions l'autorisent, qu'aucun garde-fou ne la bloque, et que le rôle qu'elle atteint est privilégié. Pathbreak résout cela en lecture seule et ne signale que les chemins qui se résolvent, plutôt que chaque permission qui pourrait en théorie être risquée.
Devrais-je simplement supprimer chaque permission de la carte ?
Non. Beaucoup de ces permissions accomplissent un travail légitime. La carte montre le contrôle qui supprimerait chaque chemin, mais la décision de l'appliquer relève du métier. La bonne approche consiste à valider quels chemins existent, à les classer selon l'ampleur de ce qu'ils ouvrent, et à couper les quelques-uns qui comptent le plus sans casser ce qui en dépend. Pathbreak valide lesquelles forment un chemin réel dans vos comptes, pour que vous corrigiez celles-là en premier.
La carte couvre-t-elle plus que l'escalade de privilèges ?
Oui. En plus de l'escalade de privilèges, elle couvre l'accès aux identifiants, l'évasion de défense contre votre propre journalisation et vos garde-fous, l'exposition de ressources à des principaux externes ou publics, l'accès aux données, et la persistance, car les vrais chemins d'attaque traversent ces catégories en chemin vers l'impact. Pathbreak maintient la carte et valide les mêmes techniques dans sa plateforme.
Voyez lesquels de ces chemins existent dans vos propres comptes AWS.
Demander un scan gratuit