In this article, I will write about a security vulnerability I found in a private program associated with the HackerOne platform and highlight the key points we need to focus on. Let's call the company XYZ.
In the XYZ company, the scope was extended to include all subdomains of xyz.com (*.xyz.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 250 subdomains.
Our next step is to examine each of these sites in detail. I use a that can open all the domains I've found at once, and I start checking all the subdomains. Later, on the subdomain abc.xyz.com, we notice that an AWS S3 bucket is running. When we see that read permissions are not restricted, meaning it is public, we consider the possibility of sensitive information leakage and immediately start looking at the files inside. After running the following command on AWS CLI, we confirm that the bucket is public. Not only “ls” and also I tried other things too.
aws s3 ls abc.xyz.com
Later, when I looked under the “samples” folder, I found around 20 test projects. These were different web applications where login and some tokens were being tested.
aws s3 ls abc.xyz.com/samples/
After I started browsing through them one by one, a block of code in the JavaScript code found in the page source of one project caught my attention.
A bucket inside another bucket! The developer forgot the name of the bucket while using it in the JavaScript code and also referenced it in the code. Let's call the name of this bucket “def”. When I visited this bucket, i.e., def.s3.amazonaws.com, the response I received was;
The specified bucket does not exist
This means we can takeover this bucket. (You can see which products contain this vulnerability and under which circumstances it can be exploited in this project: )
In fact, using and deleting the bucket mentioned in the code is not an issue. From the outside, this doesn't look like a security vulnerability, but everything starts when we takeover the bucket. Suddenly, when we visit the page where we discovered the code block, I noticed that logs were starting to drop into the bucket we took control of (the one referenced in the code). Since these logs contained the IP address and HTTP request information, the exploitation phase didn't progress further, and it ended there. Here, much more critical information could have been sent insecurely to the backend API or, as we saw in this case, to the cloud.
The bounty for this security vulnerability was $1000.
