← Tous les articles Chemins d'attaque

Analyse des chemins d'attaque vs validation des chemins d'attaque dans AWS

Par l'équipe Pathbreak · · 8 min de lecture

Points clés

  • L'analyse des chemins d'attaque relie des constats isolés pour former la séquence d'étapes qu'un attaquant pourrait suivre d'un point d'entrée jusqu'à une cible. Elle répond à la question de ce qui pourrait être enchaîné.
  • La validation des chemins d'attaque confronte chaque chaîne candidate à l'autorisation qu'AWS évaluerait : politiques d'identité, politiques de ressource, politiques de confiance, service control policies, permission boundaries et clés de condition. Elle répond à la question de savoir lesquelles de ces chaînes fonctionnent.
  • Dans AWS, les deux réponses diffèrent beaucoup. Une chaîne qui paraît complète sur un graphe peut encore être bloquée par une SCP, une boundary ou une clé de condition, et seule la résolution de l'ensemble vous dit quelles chaînes subsistent.
  • La validation dans le plan de contrôle n'exige pas d'exécuter un exploit. Résoudre l'autorisation réelle en lecture seule donne la même réponse sans aucun des risques.
  • La priorisation dépend de la validation. Dans le compte de laboratoire Pathbreak, 4,942 chemins candidats ont été ramenés à une liste classée où deux changements ont supprimé 80 pour cent du risque.

L'analyse des chemins d'attaque trouve les chaînes de permissions, de relations de confiance et d'expositions qu'un attaquant pourrait utiliser pour aller d'un point d'entrée jusqu'à une cible dans AWS. La validation des chemins d'attaque vérifie chacune de ces chaînes par rapport à l'autorisation qu'AWS évalue à chaque appel, et conserve celles qui fonctionnent.

Au lieu d'une liste de 3,000 problèmes isolés, l'analyse produit des chaînes : cette instance publique porte ce rôle, ce rôle peut passer tel autre rôle à Lambda, cet autre rôle est administrateur. La plupart des plateformes de sécurité cloud en proposent aujourd'hui une forme, et c'est un net progrès par rapport aux listes triées par sévérité.

La validation est l'étape qui suit l'analyse. Dans AWS, la question est plus difficile qu'elle n'en a l'air, car plusieurs types de politiques interviennent dans chaque décision, et les deux réponses divergent plus que la plupart des équipes ne s'y attendent.

Ce que fait l'analyse des chemins d'attaque

CreateFunction iam:PassRole runs as role 01 Attacker principal 02 New Lambda 03 Passed role 04 Administrator
La chaîne de cet article. En détenant iam:PassRole et lambda:CreateFunction ensemble, un principal crée une fonction, lui confie un rôle privilégié, et la fonction s'exécute sous ce rôle. Cet article la fait passer de candidate sur le graphe à chemin prouvé.

L'analyse part d'un inventaire : principals, rôles, politiques, relations de confiance, calcul, stockage et les liens réseau entre eux. Elle construit un graphe, puis y cherche les routes qui aboutissent à quelque chose de sensible, un rôle administrateur, une base de données de production, un bucket de données clients. Chaque saut est une technique connue. iam:PassRole avec lambda:CreateFunction est un saut. sts:AssumeRole vers un compte qui fait confiance est un saut. Une URL de fonction publique est un point d'entrée.

Le résultat est un ensemble de chemins candidats. Ils sont candidats parce que le graphe a été construit à partir des documents de politique tels qu'ils sont écrits, et qu'une politique d'identité seule ne vous dit pas ce qu'AWS décidera au moment de l'appel.

Là où l'analyse s'arrête

AWS évalue chaque appel d'API au regard de plusieurs documents à la fois, et n'importe lequel d'entre eux peut transformer un allow en deny. Un chemin qui existe sur le graphe peut être bloqué par chacun des éléments suivants :

  • Service control policies. Une SCP sur l'unité organisationnelle peut refuser lambda:CreateFunction pour toute l'OU, et aucune politique d'identité à l'intérieur ne peut passer outre.
  • Permission boundaries. Une boundary sur le principal source plafonne ce que ses politiques d'identité peuvent accorder. Si la boundary omet iam:PassRole, le passage échoue même si la politique d'identité l'autorise.
  • Politiques de confiance. Le rôle cible doit faire confiance au service ou au principal dont dépend le saut. Un rôle qui ne fait pas confiance à lambda.amazonaws.com ne peut pas être passé à Lambda, quoi que détienne l'appelant.
  • Politiques de ressource. Le bucket, la clé, la file d'attente ou la fonction au bout du chemin a sa propre politique, et elle peut refuser le principal sous lequel la chaîne est arrivée.
  • Clés de condition. iam:PassedToService, aws:SourceAccount, aws:PrincipalOrgID et la vérification sts:ExternalId restreignent toutes une autorisation qui paraît large dans la liste des actions.
  • Refus explicites. Une instruction deny n'importe où dans l'évaluation l'emporte sur tous les allow, et elle se trouve souvent dans une autre politique que celle que le graphe a lue.

Lire l'un de ces documents est facile. Le travail consiste à les résoudre tous ensemble, dans l'ordre qu'AWS applique, pour chaque étape de chaque chaîne, et c'est cette étape qui sépare un chemin candidat d'un chemin prouvé. Sautez-la et la liste est longue, et une large part échouerait dès le premier appel.

Comment valider un chemin d'attaque cloud dans AWS

Prenons une chaîne courante. Un rôle CI nommé ci-deploy détient iam:PassRole sur un rôle nommé data-pipeline, ainsi que lambda:CreateFunction et lambda:InvokeFunction. Le rôle data-pipeline possède AdministratorAccess. Sur le graphe, c'est un chemin en deux sauts du rôle CI à administrateur : créer une fonction avec data-pipeline attaché, l'invoquer, et le code de la fonction s'exécute en tant qu'administrateur.

L'analyse marque le chemin comme atteignable. La validation le parcourt ensuite une vérification à la fois :

  1. La politique d'identité de ci-deploy autorise-t-elle iam:PassRole sur l'ARN de data-pipeline, ou sur un wildcard qui le couvre ? Oui, sur arn:aws:iam::*:role/data-*.
  2. Le passage est-il restreint par iam:PassedToService ? Aucune condition n'est présente, donc n'importe quel service est accepté.
  3. La politique de confiance de data-pipeline fait-elle confiance à lambda.amazonaws.com ? Oui, elle a été créée pour un pipeline basé sur Lambda.
  4. Une SCP sur l'OU du compte refuse-t-elle lambda:CreateFunction ou iam:PassRole ? L'OU a une SCP, et elle ne refuse ni l'un ni l'autre.
  5. Une permission boundary sur ci-deploy exclut-elle l'une de ces actions ? Le rôle n'a pas de boundary.
  6. L'exécution de la fonction atteint-elle quelque chose d'important ? data-pipeline est administrateur, donc la réponse est tout le compte, et via deux relations de confiance inter-comptes, deux comptes de plus.

Toutes les vérifications sont passées, donc le chemin est prouvé. Aucune fonction n'a été créée et rien n'a été invoqué. Chaque étape a résolu les mêmes documents qu'AWS, dans le même ordre, et a rendu la même décision. C'est ce que signifie la validation dans le plan de contrôle. L'exploit est une permission, donc la preuve est le résultat de l'autorisation.

Le correctif découle de l'étape deux. Le changement le plus étroit consiste à ajouter iam:PassedToService à l'autorisation de passage pour que seul le service prévu puisse recevoir le rôle, ou à remplacer l'ARN wildcard par le seul rôle dont la CI a besoin. Après le changement, les six mêmes vérifications sont relancées et l'étape deux échoue. Le chemin a disparu, et la confirmation est enregistrée à côté du constat. L'entrée de la carte pour cette chaîne contient les événements CloudTrail et la description complète.

Peut-on valider des chemins d'attaque en production sans risque ?

Oui, lorsque la validation se fait en lecture seule. Pathbreak se connecte via un rôle IAM en lecture seule et à moindre privilège, que vous créez et pouvez révoquer à tout moment. Chaque appel qu'il effectue est une lecture (Get, List et Describe), et l'autorisation de chaque étape est résolue à partir des documents de politique que renvoient ces appels. Aucune fonction n'est créée, aucun rôle du chemin n'est assumé et aucune ressource n'est modifiée, de sorte que les charges de travail de production continuent de tourner comme avant.

La session du rôle et ses lectures apparaissent dans CloudTrail comme des événements de gestion sous le rôle Pathbreak, ce qui rend l'activité facile à auditer. Pathbreak lit la configuration, y compris les endroits où des identifiants sont souvent exposés, comme les données utilisateur des instances, les variables d'environnement des fonctions et les sorties des piles. Il ne lit pas le contenu du stockage objet ni des bases de données.

La validation en lecture seule répond à une question pour chaque étape : AWS autoriserait-il cet appel pour ce principal ? Elle ne teste ni le code applicatif, ni les exploits contre des hôtes en fonctionnement, ni la capacité de la détection et de la réponse à repérer un attaquant. Une évaluation manuelle de la sécurité AWS couvre ces points, et Pathbreak fonctionne en complément. Certains outils valident en exécutant des étapes d'attaque dans l'environnement, et ce comparatif explique quand chaque approche convient.

Pourquoi la différence décide de ce que vous corrigez en premier

Classer les chemins par impact ne fonctionne que si les chemins sont réels. Une liste qui mélange des chaînes prouvées et des chaînes qu'une SCP bloque déjà poussera les équipes vers un travail qui ne change rien. Dans le compte de laboratoire Pathbreak, l'analyse a produit 4,942 chemins candidats. Après validation et classement par rayon d'impact, un seul Deny sur un rôle a supprimé 3,893 des 4,087 chemins restants, et deux changements ensemble ont supprimé 80 pour cent du risque dans le compte. Cet ordre n'apparaît qu'une fois chaque chemin résolu face à l'autorisation réelle.

Comment Pathbreak procède

Pathbreak construit le graphe, raisonne dessus pour produire des chaînes candidates, puis valide chaque chaîne de bout en bout en résolvant l'autorisation qu'AWS évaluerait : politiques d'identité et de ressource, politiques de confiance, SCP, boundaries et conditions. L'accès est en lecture seule et rien n'est exécuté. Chaque chemin validé est classé selon ce qu'il atteint, et accompagné du changement précis qui le brise. Une fois le changement déployé, le chemin est réévalué et le résultat enregistré, de sorte que le correctif est confirmé par des preuves.

Vue d'un chemin d'attaque dans Pathbreak : un rôle de staging lit une stack CloudFormation dont le template expose un identifiant d'un utilisateur admin, avec la note de risque et les preuves pour le lien sélectionné
Un chemin validé dans Pathbreak. Le rôle PathbreakLabStaging peut lire une stack CloudFormation dont le template intègre une clé de longue durée d'un utilisateur admin. Le lien sélectionné montre la technique, la preuve (un identifiant observé) et la raison de la note attribuée au chemin.

Questions fréquentes

Qu'est-ce que l'analyse des chemins d'attaque ?

L'analyse des chemins d'attaque relie des constats de sécurité isolés pour former la séquence d'étapes qu'un attaquant pourrait suivre d'un point d'entrée jusqu'à une cible, généralement en construisant un graphe des identités, permissions et ressources et en y cherchant des routes vers des actifs sensibles. Pathbreak construit ce graphe pour AWS, puis valide chaque chemin qu'il trouve.

Qu'est-ce que la validation des chemins d'attaque ?

La validation des chemins d'attaque confronte chaque chemin candidat à l'autorisation que le fournisseur cloud évaluerait pour chaque étape. Dans AWS, cela signifie résoudre ensemble les politiques d'identité, les politiques de ressource, les politiques de confiance, les service control policies, les permission boundaries et les clés de condition, et confirmer que le chemin fonctionne. Pathbreak valide ainsi les chemins d'attaque dans AWS, en lecture seule, et enregistre le résultat pour chaque étape.

La validation implique-t-elle d'exécuter des exploits dans mon compte AWS ?

Non. Dans le plan de contrôle AWS, les mouvements de l'attaquant sont des appels d'API, et chaque appel est autorisé ou refusé par des documents de politique. Résoudre ces documents en lecture seule donne la même décision qu'AWS, de sorte qu'un chemin peut être prouvé sans rien créer, invoquer ni modifier. C'est ainsi que Pathbreak valide les chemins d'attaque dans AWS.

Un CSPM peut-il faire de la validation des chemins d'attaque ?

Les outils CSPM et CNAPP proposent une analyse des chemins d'attaque sur un graphe de votre configuration. La validation telle que décrite ici consiste à évaluer chaque couche de l'autorisation AWS pour chaque étape et à confirmer ensuite le correctif. Pathbreak le fait et peut fonctionner aux côtés d'un CSPM ou remplacer un scanner autonome.

Comment valider des chemins d'attaque cloud dans AWS ?

On construit un graphe des principaux, des rôles, des relations de confiance et des ressources, puis on en tire des chaînes candidates. Pour chaque étape d'une chaîne, on résout ensemble la politique d'identité, la politique de ressource, la politique de confiance, la politique de contrôle des services, la limite d'autorisations et les clés de condition, dans l'ordre où AWS les évalue, et on ne garde que les chaînes dont chaque étape est autorisée. Une fois la correction déployée, on relance les mêmes vérifications pour confirmer que le chemin a disparu. Pathbreak automatise ces étapes pour AWS.

Qu'est-ce qui apparaît dans CloudTrail quand Pathbreak valide des chemins d'attaque ?

L'appel sts:AssumeRole qui ouvre chaque session sur le rôle IAM en lecture seule que vous avez créé, puis des appels de lecture. Les appels Get, List et Describe de Pathbreak apparaissent dans CloudTrail comme des événements de gestion sous ce rôle. Rien dans le chemin n'est créé, invoqué ni modifié, donc la validation ne laisse aucun événement d'écriture.

Que ne couvre pas la validation des chemins d'attaque en lecture seule ?

Elle indique si AWS autoriserait chaque étape d'un chemin. Elle ne teste ni le code applicatif, ni les exploits contre des hôtes en fonctionnement, ni la capacité de la détection et de la réponse à repérer un attaquant. Une évaluation manuelle de la sécurité AWS couvre ces points, et Pathbreak fonctionne en complément.

Articles associés

Voyez quels chemins d'attaque dans vos comptes AWS sont prouvés, et le changement qui brise chacun d'eux.

Demander une démo Voir la démo