L'escalade de privilèges AWS est un problème d'autorisations. Un principal qui détient l'une d'un ensemble connu d'actions dangereuses peut se promouvoir au rang d'administrateur sans toucher à un hôte. Le catalogue ci-dessous est l'union des chemins iam-vulnerable de BishopFox et de la liste de méthodes de Rhino Security Labs, regroupés par la primitive que chacun exploite.
Les chemins#
- PassRole :
iam:PassRolecombiné à une action de création de service (EC2, Lambda, Glue, CloudFormation, Data Pipeline, CodeBuild, SageMaker) pour exécuter du code en tant que rôle privilégié. - Manipulation de politiques : éditer directement une politique IAM, via de nouvelles versions de politique par défaut et l'attachement ou l'inlining de politiques d'utilisateur, de groupe et de rôle.
- Création d'identifiants : générer de nouveaux identifiants pour un principal sur lequel vous pouvez écrire, via des clés d'accès et des profils de connexion console.
- Ressources existantes : escalader via des ressources qui s'exécutent déjà avec un rôle privilégié, en mettant à jour des stacks, des dev endpoints et du code de fonction, ou en générant des URL présignées et des accès Instance Connect.
- Appartenance à un groupe :
iam:AddUserToGrouppour rejoindre un groupe qui porte plus d'autorisations. - Politique de confiance : réécrire l'
AssumeRolePolicyDocumentd'un rôle pour pouvoir l'endosser.
Choisir un chemin#
Les chemins les plus discrets ne requièrent aucune nouvelle ressource : un CreatePolicyVersion ou un AttachUserPolicy modifie le principal sur place. Les chemins qui créent une ressource (une instance EC2, une Lambda) sont plus bruyants mais fonctionnent lorsque le seul levier que vous détenez est PassRole plus une action d'exécution. PMapper et le iam__privesc_scan de Pacu énumèrent lesquels de ces chemins le principal courant peut atteindre.