How I Found an Open AWS S3 Bucket and Used It to Take Over a Subdomain

2 days ago 16
BOOK THIS SPACE FOR AD
ARTICLE AD

Boubker Chamekh

Greetings, fellow hackers!

My name is Boubker Chamekh, and I am from Morocco. My philosophy in life is to be patient until you achieve your goals, and this approach has helped me in my bug-hunting journey. Today, I want to share my experience of discovering an open AWS S3 bucket that led to a subdomain takeover.

This bug was discovered in a private program on HackerOne, so let’s consider the target as redacted.com. During my reconnaissance, I used a script to identify low-hanging fruit, such as subdomain enumeration and subdomain takeovers. While searching, I noticed several domains with CNAME records pointing to redacted.dev, which I recognized as a developer-related domain. Although it was marked as out of scope, that didn’t stop me from exploring it further.

What is a CNAME Record?

Imagine your website is a house, and your domain name (like example.com) is the address. A CNAME (Canonical Name) record is like a forwarding address that tells the internet, “Hey, if you’re looking for shop.example.com, you’ll actually find it at someotherplace.com.

Using Google Dorks, I identified some subdomains, for example, site:*.redacted.dev. Upon accessing one of these subdomains, I found an endpoint revealing OpenAPI information and other endpoints. One of these endpoints was /api/v2/streamer/uid. Out of curiosity, I modified the endpoint to /api/v2/streamers and discovered a list of streamers along with additional information, including references to their AWS S3 buckets.

I attempted to access these S3 buckets using the command:

aws s3 ls s3://<bucket-name> - no-sign-request

Most of the buckets denied access, except for two. One of them returned an error indicating it was not in use, which allowed me to claim it. The second bucket was publicly accessible, named redacted-public.s3.amazonaws.com.

Upon examining the open bucket, I realized it was intentionally made public as it did not contain any sensitive information, nor could I delete or upload files. However, while investigating the content, I came across an endpoint pointing to an HTML file named state.html. Opening this file in my browser displayed a blank screen.

Using the browser’s developer tools by click on inspect and then inspector, I found another AWS S3 bucket referenced in the code with endpoint state.html. This bucket was not claimed, so I immediately took ownership of it.

To monitor my targets efficiently, I use a script that runs subdomain enumeration via a cron job every 24 hours. This script sends updates to a Discord channel whenever a new subdomain is discovered. After taking over the S3 bucket, I set and uploaded a POC file named poc.html. I got noticed that there is a new subdomain became active , I clicked on it and that give me an error to access the endpoint poc.html so I know it it was a subdomain takeover .

I reported this issue, and it was accepted by the program. They rewarded me with a bounty for my findings.

Takeaway

Always consider looking beyond the “out-of-scope” areas. Just because something is marked as out of scope doesn’t mean you can’t explore it . Additionally, dig deeper into the content you find in S3 buckets. You might uncover sensitive information or bugs, such as the subdomain takeover I discovered.

This is my linkedin https://www.linkedin.com/in/boubker-chamekh-4b0025235/

Read Entire Article