Insecure S3 Buckets

You wouldn't park your Lamborghini in a garage with an open door to the public. Why would you do the same with your company/team's precious data and resources?

Many companies host their assets on Amazon S3 buckets. It's a lost cost and effective method to store and backup files and resources. It can be used for public-facing assets and private/internal assets. Internal development teams may utilize S3 buckets on a regular basis as a place to store their project files. ‌

Amazon S3

S3, which stands for Simple Storage Service, is a service provided by Amazon Web Services (AWS) which allows users to store data and assets. Extremely useful for a number of reasons. It allows storage for public sites, such as javascript files, images etc. These stores are called buckets.

What is a bucket?

A bucket is simply the storage that the AWS user has created. A place they can put their files. They can choose to create these buckets in different geographical regions, (AWS have servers hosted all around the world) often chosen based on latency levels and costs.

As an admin, you can modify your bucket to suit your needs. Permissions, IAM, policies and Access Control Lists to name a few.

This is where the issue lies. Amazon S3 buckets are quick to set up however due to many factors (misconfiguration, 'leaving on the backburner') these S3 buckets can be left insecure and open for anyone to access.

Insecure S3 buckets

A lot of buckets have been found, exposed to the public. These S3 buckets would contain customer PII, databases, passwords etc. Because of this, a large number of companies have reported some high-level data breaches (Ford and Netflix just to name a few) This website tracks a list of major data breaches from S3 bucket leaks (https://github.com/nagwww/s3-leaks)‌

‌‌

LightSpin - A cloud security service provider ran some in-depth research into 40,000 AWS buckets and their cloud storage permissions found that 46% of AWS S3 buckets could be misconfigured and should therefore be considered unsafe

It's also worth noting that a misconfigured bucket doesn't just mean access to a bucket. It also means modifying the contents and permissions of its contents. This creates a larger more malicious attack vector. An attacker can introduce malicious content/files in order to damage a website or download database backups. Or even run the insecure bucket as a Command Control server for a malware campaign.

Cases

July 2020 - Twilio

Someone broke into one of their 'unprotected, world writeable S3 buckets and attempted to upload an SDK that was accessible by Twilio's customers. It was deemed 'non-malicious after analysis however, the ability to write to a critical S3 bucket made Twilio aware of their malpractice with S3 buckets.

Mitigation

Buckets are often accessed through the browser. Below I've listed the standard URL format for S3 buckets.

• http://[bucket_name].s3.amazonaws.com/
• http://s3.amazonaws.com/[bucket_name]/

A publicly accessible bucket will immediately list its contents in XML format.‌

‌

So what are some possible practical options to secure an S3 bucket? Below are a few important practices to consider when configuring one.

First and most important, remove public access from the bucket! (or buckets if there are multiple). Unless it is needed and doesn't contain any private information. This also includes all the contents within the bucket. Disabling public access to the files within will ensure that it meets the same conditions the bucket is following.

Permissions are the next one. The principle of least access is key here. Making the permissions as granular as possible. Don't provide every user with 'god-mode' permissions to read/write/execute on everything! Run a quick audit of the roles needed and ensure that the necessary permissions are set for those roles. Having an admin that manages to whitelist and blacklist will drastically increase the posture of the bucket.

Amazon has a whole page on the best security practices of S3 buckets which you can check out here (https://docs.aws.amazon.com/AmazonS3/latest/userguide/security-best-practices.html)

One interesting point to make a note of is a bucket was publicly-accessible at one point, it's likely cached or archived.

Final Thoughts

These points won't act as a fix for all S3 problems as there may be a deeper issue at hand regarding the security of a companies assets and security practices. One major practice that is seemingly prominent in the industry is the education of a companies employees. Having a deeper understanding of security practices in place as opposed to an instruction guide will always be a stronger longer-lasting solution.