AWS - STS Enum

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 escalader les privilèges et maintenir la persistance, même s'il ne dispose peut-être pas d'un large éventail 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, en les 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 d'intrusion ou les membres de l'équipe rouge, cette technique est instrumentale pour l'escalade de privilèges (comme expliqué ici). Cependant, il est à noter que cette technique est assez visible 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 (cette autorisation est suffisante).

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 spécifique sts:AssumeRole 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 (en indiquant le rôle ARN ou le compte externe), et le rôle essayant d'assumer l'autre DOIT avoir les permissions pour l'assumer (dans ce cas, ce n'est pas optionnel même si le rôle assumé spécifie un ARN).

Enumeration

# 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

Sur la page suivante, vous pouvez voir 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

Soutenez HackTricks

Last updated