AWS - STS Enum

Tip

Apprenez & pratiquez AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Apprenez & pratiquez GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Apprenez & pratiquez Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Soutenez HackTricks

STS

AWS Security Token Service (STS) est principalement conçu pour Ă©mettre des identifiants temporaires Ă  privilĂšges limitĂ©s. Ces identifiants peuvent ĂȘtre demandĂ©s pour des utilisateurs AWS Identity and Access Management (IAM) ou pour des utilisateurs authentifiĂ©s (utilisateurs fĂ©dĂ©rĂ©s).

Étant donnĂ© que le but de STS est d’émettre des identifiants pour l’usurpation d’identitĂ©, le service est extrĂȘmement prĂ©cieux pour l’escalade de privilĂšges et le maintien de la persistance, mĂȘme s’il peut ne pas avoir une large gamme d’options.

Usurpation de RĂŽle

L’action AssumeRole fournie par AWS STS est cruciale car elle permet Ă  un principal d’acquĂ©rir des identifiants pour un autre principal, l’usurpant essentiellement. Lors de l’invocation, elle rĂ©pond avec un ID de clĂ© d’accĂšs, une clĂ© secrĂšte et un jeton de session correspondant Ă  l’ARN spĂ©cifiĂ©.

Pour les testeurs de pĂ©nĂ©tration ou les membres de l’équipe rouge, cette technique est essentielle pour l’escalade de privilĂšges (comme expliquĂ© ici). Cependant, il convient de noter que cette technique est assez Ă©vidente et peut ne pas surprendre un attaquant.

Logique d’Usurpation de Rîle

Pour assumer un rĂŽle dans le mĂȘme compte si le rĂŽle Ă  assumer permet spĂ©cifiquement un ARN de rĂŽle comme dans :

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<acc_id>:role/priv-role"
},
"Action": "sts:AssumeRole",
"Condition": {}
}
]
}

Le rĂŽle priv-role dans ce cas, n’a pas besoin d’ĂȘtre spĂ©cifiquement autorisĂ© Ă  assumer ce rĂŽle (avec cette autorisation, c’est suffisant).

Cependant, si un rîle permet à un compte de l’assumer, comme dans :

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<acc_id>:root"
},
"Action": "sts:AssumeRole",
"Condition": {}
}
]
}

Le rĂŽle essayant de l’assumer aura besoin d’une permission sts:AssumeRole spĂ©cifique sur ce rĂŽle pour l’assumer.

Si vous essayez d’assumer un rĂŽle d’un compte diffĂ©rent, le rĂŽle assumĂ© doit le permettre (indiquant le ARN du rĂŽle ou le compte externe), et le rĂŽle essayant d’assumer l’autre DOIT avoir des permissions pour l’assumer (dans ce cas, ce n’est pas optionnel mĂȘme si le rĂŽle assumĂ© spĂ©cifie un ARN).

ÉnumĂ©ration

# Get basic info of the creds
aws sts get-caller-identity
aws sts get-access-key-info --access-key-id <AccessKeyID>

# Get CLI a session token with current creds
## Using CLI creds
## You cannot get session creds using session creds
aws sts get-session-token
## MFA
aws sts get-session-token --serial-number <arn_device> --token-code <otp_code>

Privesc

Dans la page suivante, vous pouvez vérifier comment abuser des permissions STS pour escalader les privilÚges :

AWS - STS Privesc

Post Exploitation

AWS - STS Post Exploitation

Persistence

AWS - STS Persistence

Références

Tip

Apprenez & pratiquez AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Apprenez & pratiquez GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Apprenez & pratiquez Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Soutenez HackTricks