AWS - EC2 Privesc
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Pour plus d'infos sur EC2, consultez :
iam:PassRole, ec2:RunInstancesUn attaquant pourrait créer une instance en attachant un rôle IAM puis accéder à l'instance pour voler les identifiants du rôle IAM depuis le point de terminaison des métadonnées.
Accès via SSH
Lancez une nouvelle instance en utilisant une clé ssh créée (--key-name) puis connectez-vous via ssh (si vous souhaitez en créer une nouvelle, vous devrez peut-être avoir la permission ec2:CreateKeyPair).
Accès via rev shell dans les données utilisateur
Vous pouvez exécuter une nouvelle instance en utilisant des données utilisateur (--user-data) qui vous enverra une rev shell. Vous n'avez pas besoin de spécifier de groupe de sécurité de cette manière.
Soyez prudent avec GuardDuty si vous utilisez les identifiants du rôle IAM en dehors de l'instance :
Impact potentiel : Privesc direct à tout rôle EC2 attaché aux profils d'instance existants.
Avec cet ensemble de permissions, vous pourriez également créer une instance EC2 et l'enregistrer dans un cluster ECS. De cette manière, les services ECS seront exécutés à l'intérieur de l'instance EC2 à laquelle vous avez accès, puis vous pourrez pénétrer ces services (conteneurs docker) et voler leurs rôles ECS attachés.
Pour apprendre à forcer les services ECS à s'exécuter dans cette nouvelle instance EC2, consultez :
Si vous ne pouvez pas créer une nouvelle instance mais avez la permission ecs:RegisterContainerInstance, vous pourriez être en mesure d'enregistrer l'instance dans le cluster et d'effectuer l'attaque commentée.
Impact potentiel : Privesc direct vers les rôles ECS attachés aux tâches.
iam:PassRole, iam:AddRoleToInstanceProfileSemblable au scénario précédent, un attaquant avec ces permissions pourrait changer le rôle IAM d'une instance compromise afin de pouvoir voler de nouvelles informations d'identification.
Comme un profil d'instance ne peut avoir qu'un seul rôle, si le profil d'instance a déjà un rôle (cas courant), vous aurez également besoin de iam:RemoveRoleFromInstanceProfile.
Si le profil d'instance a un rôle et que l'attaquant ne peut pas le supprimer, il existe une autre solution. Il pourrait trouver un profil d'instance sans rôle ou en créer un nouveau (iam:CreateInstanceProfile), ajouter le rôle à ce profil d'instance (comme discuté précédemment), et associer le profil d'instance compromis à une instance compromise :
Si l'instance n'a pas de profil d'instance (ec2:AssociateIamInstanceProfile) *
Impact potentiel : Privesc direct vers un rôle EC2 différent (vous devez avoir compromis une instance AWS EC2 et avoir des permissions supplémentaires ou un statut de profil d'instance spécifique).
iam:PassRole(( ec2:AssociateIamInstanceProfile& ec2:DisassociateIamInstanceProfile) || ec2:ReplaceIamInstanceProfileAssociation)Avec ces permissions, il est possible de changer le profil d'instance associé à une instance, donc si l'attaque avait déjà accès à une instance, il pourra voler des identifiants pour plus de rôles de profil d'instance en changeant celui qui lui est associé.
S'il a un profil d'instance, vous pouvez supprimer le profil d'instance (ec2:DisassociateIamInstanceProfile) et l'associer *
ou remplacer le profil d'instance de l'instance compromise (ec2:ReplaceIamInstanceProfileAssociation). *
Impact potentiel : Privesc direct vers un rôle EC2 différent (vous devez avoir compromis une instance AWS EC2 et avoir des permissions supplémentaires ou un statut de profil d'instance spécifique).
ec2:RequestSpotInstances,iam:PassRoleUn attaquant avec les permissions ec2:RequestSpotInstancesetiam:PassRole peut demander une instance Spot avec un rôle EC2 attaché et un rev shell dans les données utilisateur.
Une fois l'instance lancée, il peut voler le rôle IAM.
ec2:ModifyInstanceAttributeUn attaquant avec le ec2:ModifyInstanceAttribute peut modifier les attributs des instances. Parmi eux, il peut changer les données utilisateur, ce qui implique qu'il peut faire en sorte que l'instance exécute des données arbitraires. Cela peut être utilisé pour obtenir un rev shell sur l'instance EC2.
Notez que les attributs ne peuvent être modifiés que lorsque l'instance est arrêtée, donc les permissions ec2:StopInstances et ec2:StartInstances.
Impact potentiel : Privesc direct vers tout rôle IAM EC2 attaché à une instance créée.
ec2:CreateLaunchTemplateVersion,ec2:CreateLaunchTemplate,ec2:ModifyLaunchTemplateUn attaquant avec les permissions ec2:CreateLaunchTemplateVersion,ec2:CreateLaunchTemplate et ec2:ModifyLaunchTemplate peut créer une nouvelle version de modèle de lancement avec un rev shell dans les données utilisateur et tout rôle IAM EC2 dessus, changer la version par défaut, et tout groupe Autoscaler utilisant ce modèle de lancement qui est configuré pour utiliser la dernière ou la version par défaut va relancer les instances en utilisant ce modèle et exécutera le rev shell.
Impact potentiel : Privesc direct vers un rôle EC2 différent.
autoscaling:CreateLaunchConfiguration, autoscaling:CreateAutoScalingGroup, iam:PassRoleUn attaquant avec les permissions autoscaling:CreateLaunchConfiguration,autoscaling:CreateAutoScalingGroup,iam:PassRole peut créer une configuration de lancement avec un rôle IAM et un rev shell à l'intérieur des données utilisateur, puis créer un groupe d'autoscaling à partir de cette configuration et attendre que le rev shell vole le rôle IAM.
Impact potentiel : Privesc direct vers un rôle EC2 différent.
!autoscalingL'ensemble des permissions ec2:CreateLaunchTemplate et autoscaling:CreateAutoScalingGroup n'est pas suffisant pour escalader les privilèges vers un rôle IAM car pour attacher le rôle spécifié dans la Configuration de Lancement ou dans le Modèle de Lancement vous avez besoin des permissions iam:PassRole et ec2:RunInstances (ce qui est un privesc connu).
ec2-instance-connect:SendSSHPublicKeyUn attaquant avec la permission ec2-instance-connect:SendSSHPublicKey peut ajouter une clé ssh à un utilisateur et l'utiliser pour y accéder (s'il a un accès ssh à l'instance) ou pour escalader les privilèges.
Impact potentiel : Privesc direct aux rôles IAM EC2 attachés aux instances en cours d'exécution.
ec2-instance-connect:SendSerialConsoleSSHPublicKeyUn attaquant ayant la permission ec2-instance-connect:SendSerialConsoleSSHPublicKey peut ajouter une clé ssh à une connexion série. Si la série n'est pas activée, l'attaquant a besoin de la permission ec2:EnableSerialConsoleAccess pour l'activer.
Pour se connecter au port série, vous devez également connaître le nom d'utilisateur et le mot de passe d'un utilisateur à l'intérieur de la machine.
Cette méthode n'est pas très utile pour le privesc car vous devez connaître un nom d'utilisateur et un mot de passe pour l'exploiter.
Impact potentiel : (Hautement invérifiable) Privesc direct vers les rôles IAM EC2 attachés aux instances en cours d'exécution.
describe-launch-templates,describe-launch-template-versionsÉtant donné que les modèles de lancement ont une version, un attaquant avec les permissions ec2:describe-launch-templates et ec2:describe-launch-template-versions pourrait les exploiter pour découvrir des informations sensibles, telles que des identifiants présents dans les données utilisateur. Pour ce faire, le script suivant parcourt toutes les versions des modèles de lancement disponibles :
Dans les commandes ci-dessus, bien que nous spécifions certains motifs (aws_|password|token|api), vous pouvez utiliser une regex différente pour rechercher d'autres types d'informations sensibles.
En supposant que nous trouvions aws_access_key_id et aws_secret_access_key, nous pouvons utiliser ces identifiants pour nous authentifier sur AWS.
Impact potentiel : Escalade de privilèges directe vers l'utilisateur(s) IAM.
Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE) Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE)
