S3 Bucket Misconfigured Access Controls to Critical Vulnerability
2020-07-02 18:53:45 Author: medium.com(查看原文) 阅读量:141 收藏

Harsh Bothra

Image for post

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:

  • Create something on the bucket
  • Modify something on the bucket
  • Delete something on the bucket
  • Read some sensitive data on the bucket (case-by-case basis)

To test for the access controls of the S3 Bucket, the best way is to use, AWS CLI and default commands.

  1. Install AWS CLI
  2. Provide AWS ACCESS Key & Secret to configure AWS CLI

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.

  1. Checking for S3 Open Buckets & Finding bucket name
  2. Using AWS CLI to Check S3 Bucket Access Controls
  3. Increasing Impact by looking at all C.R.U.D (Create, Read, Update & Delete) actions.

文章来源: https://medium.com/bugbountywriteup/s3-bucket-misconfigured-access-controls-to-critical-vulnerability-6b535e3df9a5?source=rss-54fa249211d2------2
如有侵权请联系:admin#unsafe.sh