# AWS - STS Privesc

{{#include ../../../banners/hacktricks-training.md}}

## STS

### `sts:AssumeRole`

Chaque rôle est créé avec une **politique de confiance de rôle**, cette politique indique **qui peut assumer le rôle créé**. Si un rôle du **même compte** indique qu'un compte peut l'assumer, cela signifie que le compte pourra accéder au rôle (et potentiellement **privesc**).

Par exemple, la politique de confiance de rôle suivante indique que n'importe qui peut l'assumer, donc **tout utilisateur pourra privesc** aux permissions associées à ce rôle.
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": "sts:AssumeRole"
}
]
}
```
Vous pouvez usurper un rôle en exécutant :
```bash
aws sts assume-role --role-arn $ROLE_ARN --role-session-name sessionname
```
**Impact potentiel :** Privesc au rôle.

> [!CAUTION]
> Notez que dans ce cas, la permission `sts:AssumeRole` doit être **indiquée dans le rôle à abuser** et non dans une politique appartenant à l'attaquant.\
> Avec une exception, afin de **prendre un rôle d'un compte différent**, le compte de l'attaquant **doit également** avoir le **`sts:AssumeRole`** sur le rôle.

### **`sts:GetFederationToken`**

Avec cette permission, il est possible de générer des identifiants pour usurper n'importe quel utilisateur :
```bash
aws sts get-federation-token --name <username>
```
C'est ainsi que cette permission peut être accordée en toute sécurité sans donner accès à l'imitation d'autres utilisateurs :
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "sts:GetFederationToken",
"Resource": "arn:aws:sts::947247140022:federated-user/${aws:username}"
}
]
}
```
### `sts:AssumeRoleWithSAML`

Une politique de confiance avec ce rôle accorde **aux utilisateurs authentifiés via SAML l'accès pour usurper le rôle.**

Un exemple de politique de confiance avec cette autorisation est :
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "OneLogin",
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::290594632123:saml-provider/OneLogin"
},
"Action": "sts:AssumeRoleWithSAML",
"Condition": {
"StringEquals": {
"SAML:aud": "https://signin.aws.amazon.com/saml"
}
}
}
]
}
```
Pour générer des identifiants afin d'usurper le rôle, vous pourriez utiliser quelque chose comme :
```bash
aws sts  assume-role-with-saml --role-arn <value> --principal-arn <value>
```
Mais les **fournisseurs** peuvent avoir leurs **propres outils** pour faciliter cela, comme [onelogin-aws-assume-role](https://github.com/onelogin/onelogin-python-aws-assume-role) :
```bash
onelogin-aws-assume-role --onelogin-subdomain mettle --onelogin-app-id 283740 --aws-region eu-west-1 -z 3600
```
**Impact potentiel :** Privesc au rôle.

### `sts:AssumeRoleWithWebIdentity`

Cette autorisation permet d'obtenir un ensemble de credentials de sécurité temporaires pour **les utilisateurs qui ont été authentifiés dans une application mobile, web, EKS...** avec un fournisseur d'identité web. [En savoir plus ici.](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithWebIdentity.html)

Par exemple, si un **compte de service EKS** doit être capable de **se faire passer pour un rôle IAM**, il aura un jeton dans **`/var/run/secrets/eks.amazonaws.com/serviceaccount/token`** et peut **assumer le rôle et obtenir des credentials** en faisant quelque chose comme :
```bash
aws sts assume-role-with-web-identity --role-arn arn:aws:iam::123456789098:role/<role_name> --role-session-name something --web-identity-token file:///var/run/secrets/eks.amazonaws.com/serviceaccount/token
# The role name can be found in the metadata of the configuration of the pod
```
### Abus de fédération

{{#ref}}
../aws-basic-information/aws-federation-abuse.md
{{#endref}}

{{#include ../../../banners/hacktricks-training.md}}
