S3 buckets are a way of storing files on Amazon Web Services (AWS). These are continually making the news for being found with sensitive information in them that have been made public. There are legitimate reasons to make S3 buckets public, such as hosting the content for a public website.
However, many of these incidents appear to be unintentional. There are many reasons why this might be the case, but we decided to investigate one hypothesis, that perhaps one or more third-party tools used to work with S3 buckets are contributing to this problem.
There are a handful of tools people use to work with S3 buckets that were not developed by Amazon. Our hypothesis was that perhaps one or more of these tools are automatically making these S3 buckets public, or perhaps contain wording for an action that is misleading and results in the bucket being made public. We determined that these tools are not a contributing factor to this problem.
In summary, we found:
- None of the tools reviewed made S3 buckets public without intentional actions by the user.
- One third-party tool was using unencrypted HTTP by default.
Unencrypted HTTP and Authenticated Users
In our audit, we found one tool that was using unencrypted HTTP by default, and after requesting they change this, they're now using HTTPS by default.
We looked at the following tools:
Most people interact with S3 buckets either through the web console, the CLI developed by AWS, custom code that uses one of the AWS SDKs, or one of those tools.
None of the tools automatically marks a bucket as public. The three tools do have the ability to mark an S3 bucket as public, but the wording in these tools is similar to the AWS web console. Like the AWS console, these tools use the word "Everyone" to mean a bucket is public.
Until a few months ago, the web console also included the option to easily grant access to "Authenticated users," which was misleading as this meant any authenticated user to any AWS account, and not just the users within one's own account.
AWS has since removed this option and more proactively adds warnings around this option in the documentation for this service. The S3 tools that we looked at are still using the phrase "Authenticated users" as an option for granting access, with S3 Browser recently clarifying the wording to read "Any AWS Users."
Making a bucket public in CyberDuck
Making a bucket public in CloudBerry
Making a bucket public in S3 Browser
Encrypted Communications by Default
While performing this research, we noticed that one tool, S3 Browser, did not use encrypted communication by default. All traffic was sent and received over unencrypted HTTP with S3 Browser unless a box was checked on configuration. We reported this to the creators of S3 Browser who quickly put out a new release that changes this default setting. This change was made in S3 Browser version 7.6.9.
For older versions, ensure you check the box for "Use secure transfer." Additionally, you can enforce SSL for accessing an S3 bucket by using the the condition "aws:SecureTransport" in your AWS policies. We recommend users of S3 Browser consider upgrading to the latest version to take advantage of encrypted transport.
S3 Browser <7.6.2 did not use encrypted communications by default.
None of the tools we looked at are automatically making S3 buckets public. Unfortunately, users are doing this themselves. Users of S3 Browser have, by default, been accessing S3 buckets over unencrypted HTTP, so if you use that application, we recommend you upgrade to a newer version and ensure you are using SSL/TLS when accessing S3 buckets.
We also believe there continues to be opportunities for AWS, tool maintainers, and security practitioners to communicate the potential risk of unsafe configurations. AWS has made excellent UI changes in the past few months to more clearly identify when an S3 bucket has been made public.
Stay in Touch!
If you're interested in protecting the public by identifying and fixing vulnerabilities on a broad scale, apply to join the Duo Labs team at https://duo.com/about/careers.