5 Vulnerable S3 Bucket Takeovers That Earned Me Swag from Sony
During one of my recent security assessments, I discovered five misconfigured Amazon S3 buckets associated with Sony. These vulnerabilities, if left unaddressed, could have led to sensitive data exposure, website defacement, or other major security risks.
This write-up highlights the finding, the approach I took, and the outcome.
🛠️ The Approach:
In the Sony company, the scope was extended to include all subdomains of sony.com (*.sony.com). The first step here will be to find all subdomains. There are many tools available for this purpose, and I used the subfinder tool to find approximately 10429 subdomains.
subfinder -dL domainList.txt | httpx | tee live.txt
After enumerating all possible subdomains related to Sony’s assets, I used Subzy to scan for potential subdomain takeovers. However, the scan didn’t yield any vulnerable subdomains at this stage.
subzy -r --targets live.txt
While Subzy initially flagged several subdomains as potentially vulnerable, a manual verification revealed that they were all false positives. None of the flagged domains were actually pointing to unclaimed or misconfigured services.
Our next step is to examine each of these sites in detail. I use a Chrome extension that can open all the domains I’ve found at once, and I start checking all the subdomains. I landed on a subdomain of interest: abc.xyz.com. This particular page displayed a raw error response, indicating that it was tied to an AWS S3 bucket. The error message was as follows:
Error
CodeNotFound/Code
MessageThe resource you requested does not exist/Message
RequestIdAKFKS7AN2CBM2667/RequestId
HostId5zzD9y7nGDL3S54rT0eLqxoS0orLWiy92ey5UsViQP5/C9BxG8vNQAYwGmZZ0Q+9xJIwvS+M2EY=
/HostId
/Error
This response strongly suggested that the site was attempting to serve content from an S3 bucket that no longer exists or is not properly configured — a common indicator of a potential S3 bucket takeover opportunity.
After identifying that the subdomain abc.xyz.com was pointing to an AWS S3 bucket with an error indicating missing resources, I proceeded to check if I could exploit this misconfiguration.
To take advantage of the misconfiguration, I created a new S3 bucket with the same name as the original one — abc.xyz.com—on my AWS account. This step was crucial because, due to the global uniqueness requirement for S3 bucket names, I could confirm that the previous bucket might have been unclaimed or improperly configured.
After successfully creating the bucket, I uploaded a test file and noticed that the URL for the bucket had changed to the default AWS S3 endpoint format:
abc.xyz.com.s3.ap-south-1.amazonaws.com
This was the URL for my newly created S3 bucket, and it now hosted the content I uploaded, demonstrating that the original subdomain was pointing to my newly created bucket.
Once I had successfully confirmed the S3 bucket takeover, the next logical step was to responsibly disclose the issue. I submitted a detailed report through HackerOne, outlining the vulnerability I had discovered, including the steps to reproduce the issue and the potential security risks it posed.
The Outcome:
About a day later, my bug was triggered, and the company (Sony) acknowledged the vulnerability. This led to the fix being rolled out, and I was rewarded with a Sony swag for my efforts. It was incredibly satisfying to see how my findings contributed to improving the security of their systems.
This is my first write-up on a security vulnerability, and I’m excited to share my experience. It’s been a great learning journey, and I’m looking forward to more discoveries and challenges ahead!
Tags :
