The Chum Bucket: Thoughts About S3 Buckets From an Attackers Perspective

For a long time now, S3 buckets have become a staple for almost any organization that has gotten into the cloud computing environment. These buckets are abstract and can be used for many purposes. The variability of these buckets’ ranges from static images for a website’s web home page to files that contain extremely sensitive customer information or credentials. As such, in recent years, searching for vulnerabilities and common misconfigurations on the AWS environment has become popular among the security community and of course potential threat actors.

Whilst AWS has implemented more than just a few mechanisms to protect users from misconfiguring their S3 buckets, mistakes still happen. It is therefore not uncommon to find that some security-matured organizations have that one “small” misconfiguration in a bucket that later proves to be detrimental.

Many noteworthy examples can be mentioned, a specific one to note however, is Twilio. This case involved the public exposure of Write permissions over an S3 bucket. No authentication was required, which ultimately enabled anyone on the internet to access the contained files.

Some techniques used for detecting S3 buckets without access to the target AWS account you should be aware of include:

• Grayhatwarfare — This platform contains (among other resources) many public S3 buckets. These buckets and their files can be searched by their names and/ or content in order to find related buckets.
• Dictionary Attack — As every S3 bucket has a unique name, we can try to guess the names of buckets which may have been created by the target organization. For example, if our target is “ExampleCorp”, we can try to access buckets such as “ExampleCorp-assets” or “ExampleCorp-prod”.
• Search Engines Dorking — Using search engines with S3 related queries can help us detect buckets that were indexed by them. For example, searching google with queries such as:

site: <Target> -*.s3.amazonaws.com

site: *- <Target>.s3.amazonaws.com

site: *- <Target> -*.s3.amazonaws.com

site: s3.amazonaws.com intitle: <Target>

site: s3.amazonaws.com inurl:<Target >

site: s3.amazonaws.com “<Target>”

Website externally loaded resources, for example:

• CSP Headers — The Content-Security-Policy header is an HTTP response header that is used to control which resources are allowed to be loaded to the page. As S3 buckets are commonly used to store resources for web pages, finding those buckets at the CSP header is not uncommon.
• S3 buckets can also be found in the resource’s “SRC” parameter. Searching the web page source can therefore lead to the finding of new buckets.
• Educated guess — If we already know the name of a bucket, it may be possible to find more buckets with a similar name. For example, if we found the bucket “Target-prod”, it is possible that other buckets such as “Target-dev”, “Target-staging” and “Target-test” exist as well.

After identifying the target’s buckets, we try to find access control misconfigurations. Such misconfigurations usually contain permissive Read or Write permissions over the buckets. If we find a bucket with a public Read permission, we then try to understand the type of stored data and search for leads to compromise other assets of the target. Such data may be API keys certificates and other credentials that are stored in config files. In addition to this, the data leak itself may be devastating to the target depending on the data.

Overly permissive read permissions on a bucket can include:

• Public list-bucket permission — This allows everyone to view directories and file names that are stored in the bucket. Even the names of the files themselves may be a significant issue to the target as they may disclose interesting technical or other sensitive information, such as the target’s clients.
• Public get-object permissions — This allows everyone to read the files’ content from the bucket given that they know the file name. In such cases, we can fuzz for file names or, if we know the name of files that exist in the bucket we can try and calculate the names of other files.
• Both list and get permissions — This allows us to see which files exist in the bucket and read their content.

It is worth noting that identifying a listable bucket or readable file can be used to identify the AWS account ID that the bucket belongs to. This can be used to focus our efforts on the specific account, and in the case that the account ID of the target is known, we can validate that the bucket belongs to the target. In addition to all of this, the account ID can also be used to enumerate roles and users within it.

Global Write Permissions may allow everyone to upload files to the bucket and alter the existing files. Exploitations of such cases can have many effects. One example of such exploitation was responsibly disclosed by Twilio almost two years ago. The policy of a S3 bucket called “media.twiliocdn.com” was changed to:

Twilio’s Policy Change

This policy stated that anyone could read files from and upload files to the “TaskRouter” directory in the bucket. This directory was used to store resources for the TaskRouter JavaScript SDK which interacts with Twilio’s TaskRouter service. The issue was found by a malicious actor that uploaded a new version of a JS file that related to the Magecart hacking group.

So, based on all the above-mentioned, what can be done to mitigate this issue and prevent future S3 buckets misconfigurations?

• Map your environment — Check the buckets under your control. Understand what they are used for and what specific permissions they need to fulfil their tasks successfully.
• The principle of Least Privileges — Beware of the wild card. Remove any unnecessary access permission. If only a few files in the bucket are supposed to be public, then there is no need to give access to all the files in the bucket.
• Assessments and monitoring — Continuously test your environments for unneeded access.

Itay Saraf is a cyber security expert in CYE’s services teams. Itay primarily focuses on conducting multiple assessments on the different cloud environments with a specific emphasis on AWS.