Few keywords used in below code syntax:
–profile x1 - Its an AWS comfigured profile in my local system which has access to most of the required AWS services.
s3-bcket-292828 - Its a bucket which I have created on my AWS account for demo purpose and to explain concepts

Object metadata and versioning

Test Case - Abusing Bucket Versioning

Assumption - Buckets are made public or have list object permission to the bucket

Assuming that the buckets are made public or assuming if users on the internet have list object permission to the bucket. Now because versioning is enabled, any malicious user on the internet can just list the object versions and check what addition or deletion has been done or what data has been modified.

Note: Most of the data breaches these days happen due to present sensitive API KEY, Secrets, Passwords etc, in the source code or in git commits(versioning).

S3 allows a user to list object version using below AWS CLI command -

aws s3api list-object-versions --bucket s3-bcket-292828 --profile x1

Once attackers know the version ID which can be extracted from above command’s response, malicious user can simply run below AWS command to download the previous version of the file -

aws s3api get-object --bucket s3-bcket-292828 --key abc.txt --version-id 36tWHDH.alg9jXtfWSpjmYdlFYiyYMzG  abc --profile x1

Instead of my name pankaj in the text file abc, it could have been AWS secret key and Access Key.

Access Control in S3

Access Controls

  • IAM Policies
  • S3 Bucket Policies
  • Access Control Lists

S3 Bucket Policies

These are specific for S3 Buckets, it can not be attached to a role, user or a group directly. S3 bucket policies do have a parameter called Principal(User) which defines entity this policy is applicable to. One of the advantage of using S3 Bucket policy is to allow the cross account access.

An Example S3 Bucket policy which allows a user x1 to list objects inside S3 bucket is following -

    "Version": "2012-10-17",
    "Id": "Policy1634491339238",
    "Statement": [
            "Sid": "Stmt1634491334772",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::9560xxxxxxxx:user/x1"
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::s3-bcket-292828"

Why to use an S3 Bucket

  • To grant cross-Account Access to your S3 bucket, without using IAM roles
  • IAM policies bump up against the size limit(up to 2 kb for users, 5kb for groups, and 10kb for roles). S3 supports bucket policies of up to 20kb. So if your S3 related IAM policy for user is larger than 2kb then you can use S3 bucket policy. (credit - acloud.guru)

Server-side encryption and client-side encryption

Object locking

Understanding S3 Storage Classes

Access Control Policy Evaluation

Enumerating public S3 buckets

Identifying bucket policy/ACL constraints on an S3 bucket

Identifying anonymous write operations on an S3 bucket

Leveraging misconfigured bucket policies and ACPs

Anonymous/Authorized public read

Reading policies and identifying object names

Writing objects to buckets

Overwriting bucket ACL and object ACL

Overwriting bucket policies

Performing denial of service

Chaining web application attacks through S3 resources