S3 Bucket Takeover

How I took over a subdomain by claiming an unowned S3 bucket

Introduction

Subdomain takeover is a common vulnerability that occurs when a subdomain points to an external service that is no longer in use, allowing an attacker to claim it and potentially serve malicious content. In this blog, I’ll walk you through how I identified and exploited an unclaimed Amazon S3 bucket to take over a subdomain.

Reconnaissance

The first step in this process was discovering vulnerable subdomains. I used my subdomain enumeration tool (SubRaptorX 2.0)

Once I had a list of subdomains, I checked their DNS records using dig and nslookup:

nslookup vulnerable.example.com

dig CNAME vulnerable.example.com

I got a subdomain with an interesting output:

vulnerable.example.com   CNAME   s3.amazonaws.com

This indicated that the subdomain was configured to serve content from an S3 bucket, but I needed to check whether the bucket was still in use.

Checking for an Unclaimed S3 Bucket

As usual, we need to ensure that S3 bucket takeover is possible. Since subdomain takeovers are being patched rapidly, I wanted to verify this. I visited can I takeover xyz to gather information on S3 bucket takeovers. I found the following information from there :-

1. S3 bucket takeover is possible.

2. If the bucket is vulnerable, you will get the following response while accessing the web page:

404 Not Found
Code:NoSuchBucket
Message:The specified bucket does not exist
BucketName:example_bucket

3. You can claim an unowned S3 bucket by simply creating an AWS account and then creating an S3 bucket with the same name.

I accessed the subdomain from my browser and got the following response:

Bingo! I got the response I was hoping for. This means I can take over this S3 bucket.

Taking Over the Bucket

Since the S3 bucket was unclaimed, I attempted to create a new bucket with the same name.

Once the bucket was created, I uploaded a simple HTML file to confirm control over the subdomain.

When I accessed the subdomain again, the error message was replaced with my rendered HTML file, confirming successful takeover of the S3 bucke and the subdomain.

At long last, I successfully executed my first full subdomain takeover.

Impact and Mitigation

A successful subdomain takeover can be used for phishing, defacement, or even session hijacking if the subdomain is referenced in cookies. To prevent this:

• Regularly audit DNS records and remove entries pointing to decommissioned services.
• Use wildcard DNS records cautiously, as they can increase the attack surface.
• Monitor for subdomain takeovers using tools like Subjack and Takeover.
• Implement security headers such as Content-Security-Policy (CSP) to restrict content loading.

Conclusion

Subdomain takeovers via unclaimed S3 buckets are a critical security risk that organizations must address. This experience highlights the importance of proper cloud resource management and DNS hygiene.

If you're a security researcher or bug bounty hunter, always follow responsible disclosure practices when identifying such vulnerabilities.

I reported the vulnerability to the organization. Despite their responsible disclosure policy and the fact that they offer swag for valid reports, I never received a response. I deleted the bucket on my side, allowing them to reclaim it. Eventually, they moved to hackerone and fixed the vulnerability.

Ultimately, what matters is that the issue was resolved, and I gained valuable insights from the experience. I trust this write-up has provided you with something new as well. Thank you for taking the time to follow along.