Amazon S3 (Simple Storage Service) is one of the popular and widely used storage services. Many companies are using S3 buckets to store their assets such as user profile pictures, static resources, and anything as per their business logic and needs. However, if the buckets are not configured properly, or are unclaimed, an attacker can probably perform some mischievous actions such as S3 Bucket Takeover or S3 Content Takeover.
Hi Fellow Hackers & Enthusiasts, In this article, I will be talking about one of the recent encounters where a misconfigured S3 Bucket allowed me to perform any of the CRUD operations resulting in a critical vulnerability.
You can read more about Amazon S3 here.
The application I was testing had a huge scope. The finding is related to one of the subsidiaries of the program. Let’s call the subsidiary “subtarget.com”.
I started with subdomain enumeration and resolving unique subdomains with the following command:
subfinder -d subtarget.com -silent | httpx -follow-redirects -status-code -vhost -threads 300 -silent | sort -u | grep “[200]” | cut -d [ -f1 > resolved.txt
From there, I found a subdomain named: “https://qa-assets-us.subtarget.com” while navigating to this, I observed that the Bucket is Open and I am presented with the “ListBucketResult”
Now, the bucket is being used for static resources so there is no point to report this because sometimes the buckets are open intentionally (at least that’s what they say).
Next step was to look at the following entry which provided the name of S3 Bucket:
<Name>some-name-here</Name>
Now, the next process is to test for the access controls of the S3 Bucket. Usually, the bucket shall not provide an unauthorized user following permissions:
To test for the access controls of the S3 Bucket, the best way is to use, AWS CLI and default commands.
Now, use the following commands to check if we have access to upload (create) something on the S3 Bucket:
aws s3 cp yourtestfile.txt s3://bucketname
Upon success, you should see something like this:
upload: ./yourtestfile.txt to s3://bucketname/yourtestfile.txt
Similarly, in this case, I was successfully able to upload the file to the bucket.
But, wait, let’s check for more permissions to increase the impact, let’s delete the file we uploaded and see if it works. use following command to do so:
aws s3 rm s3://bucketname/yourtestfile.txt
and we were able to successfully remove the file.
Now, the impact increases because I can delete the original resource and upload a new attacker defined resource with the same name. Wherever the application is referencing that resource, it will now show attacker defined resources.