Researchs
  • About Me
  • Bypassing DEP - Increasing the Gap
  • Hijacking Cloud CI/CD Systems for Fun and Profit
  • Found some Access Keys?
  • AWS Cloud Security
    • AWS Cloud Researchs
      • AWS and the Secrets Exposed on Public ECR Repository
    • Hacking API Gateway
      • API Gateway - Security
      • API Gateway API Calls
    • Hacking S3
      • S3 - Security
      • S3 API Calls
    • Hacking Cognito
      • Cognito - Security
      • Cognito - API Calls
    • Hacking Lamda
      • Lambda - Security
      • Lambda - API Calls
    • Hacking Cloudbuild
      • Cloudbuild - Security
      • Cloudbuild - API Calls
    • AWS Services
  • Windows Security Research
    • Exploit Development
      • RTCore64.sys - CVE-2019-16098
      • Mouse Server
      • mskssrv.sys - CVE-2023–29360
    • Fuzzing
      • WTF
  • Supply Chain Research
    • Abusing Netlify Functions
  • Reverse Engineering
    • Reversing.kr
      • Easy_CrackMe
      • Easy KeyGen
  • Failed Research Attempts
    • Github Actions - Cloud
    • CloudTrail
Powered by GitBook
On this page
  • Scenario I - My S3 is open
  • Senario II - S3 Ransomware
  • Scenario III - Bucket Policy wide open
  1. AWS Cloud Security
  2. Hacking S3

S3 - Security

PreviousHacking S3NextS3 API Calls

Last updated 2 years ago

Following are some interesting security scenarios :-

Scenario I - My S3 is open

Many times S3 bucket are open to world and allows un-authorized read and write access. This was the major reason for CapitalOne breach.

In order to list objects in a S3 bucket named "test-bucket" simply either visit https://test-bucket.s3.amazonaws.com or perform the following API call.

aws s3 ls s3://test-bucket

Senario II - S3 Ransomware

We share a research done by RhinoSecurity team which is cloud's equivalent for Ransomware in S3. S3 bucket with write access can be encrypted with a KMS key which belongs to attacker's account. In this case, the owner of bucket will not be able to decrypt the content since the encrypted key doesn't belong to his account. Once the bucket has been encrypted, attacker can leave ransom.txt as a ransom note and ransom the bucket.

More details about this interesting research can be found

Scenario III - Bucket Policy wide open

Many times users make sure to not make bucket public but a misconfigured bucket policy makes a bucket public indirectly.

For example consider the below bucket policy :-

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Statement2",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::securitylabs-articles/*"
        }
    ]
}

This policy is a vulnerable S3 policy which indicates that Anyone on internet can download objects from my bucket securitylabs-articles .

Here the vulnerable part is the Principal field which is * which indicates that anyone on internet can download objects. Assuming there is a object called note.txt then to download the object one has to just make the below curl request

curl https://securitylabs-articles.s3.amazonaws.com/note.txt
here