Notes from the Field • 6 MIN READ

Security 101: Compromised AWS S3 Buckets

by Nikhil Mohanlal, Eleanor Barlow • Sep 2021

S3 is a service provided by Amazon Web Services (AWS), it stands for Simple Storage Service and allows users to store data and assets.

It is useful in that it allows storage for public sites, such as JavaScript files, images, and more. These stores are called Buckets. Many companies host their assets on Amazon S3 Buckets, which is an effective method to store and backup files and resources and can be used for public facing and private/internal assets. Internal development teams may utilise S3 Buckets on a regular basis as a place to store their files, such as automation scripts or programs which are used on a regular basis.

What is a Bucket and How Can it Be Used?

A Bucket is simply a place that the AWS user has created to store their files. As AWS has servers hosted all around the world, the user can choose to create these Buckets in different geographical regions. These servers are often chosen based on latency levels and costs.

As an admin, you can modify your Bucket to suit your requirements- Permissions, Identify & Access Management (IAM), policies and Access Control Lists, to name a few.

But this is also where a key issue lies. Amazon S3 Buckets are quick to set up, which can also mean that security measures can be left misconfigured. And if they’re not dealt with soon, the S3 Bucket can be left open for anyone to access, including malicious attackers.

Insecure S3 Buckets Examples

Numerous public Buckets have been reported as exposed, many of which contain customer details, Personally Identifiable Information (PII), databases, passwords and more. Because of this, there has been a growth in the number of companies that have reported high-level data breaches.

Amidst the list of those reporting such breaches, include corporate giants such as Ford and Netflix.

Infact ‘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.’

Below is a screenshot of a leaked S3 Bucket from Netflix containing database credentials.

Leaked S3 Bucket from Netflix containing database credentials.

It is also worth noting that a misconfigured Bucket does not only mean access to a Bucket. It also means the ability to modify content and the permissions of the content. This creates a larger more malicious attack vector. An attacker can introduce malicious content/files to damage a website or download database backups. Or even run the insecure Bucket as a Command Control server for a malware campaign.

An interesting point to make a note of is that if a Bucket was publicly accessible at one point, it is likely already cached or archived.

Twilio Breach

In July 2020 Twilio, a cloud communications platform-as-a-service (CPaaS), became compromised as a bad actor broke into one of their unprotected, world-writeable S3 Buckets and attempted to upload an SDK which 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 and the possible implications and damage a bad actor could inflict if they desired.

Premier Diagnostics Patient Data Breach

In a more recent breach, of March 2021, over 50, 000 patient records stored on two publicly accessible AWS S3 Buckets for Utah-based COVID-19 testing service Premier Diagnostics, were the cause of a damaging security misconfiguration. Both Buckets were without password protection or authentication. The security team at AWS were alerted, along with the Bucket owners, but the data had already been exposed. Including ‘medical insurance information, patient information, private test sample IDs, among other PII, and sensitive information. One of the exposed Buckets, titled patient-images, contained more than 200,000 images. Each patient had four files uploaded – front and back images of medical insurance and ID cards (including driver’s licenses and passports). The second Bucket, named paper-records, contained names, dates of birth, and test sample IDs. The loss of this crown jewel data is quite significant not just in volume but also in terms of its highly sensitive nature.’ – SecurityBoulevard

What Does an S3 Bucket Look Like?

Buckets are often accessed through the browser. Below is 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 the contents of it in XML format.

Standard URL format for S3 Buckets.

What To Do Next

There are some practical options to secure an S3 Bucket. Often, such misconfigurations are caused by a lack of Cloud Security and/or coupled with human error. Which is why it is crucial to stay educated on how to protect your data. Below are a few important practices to consider when configuring one.

  1. First, and most importantly, remove public access from the Bucket/Buckets! 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 that the Bucket is following.
  • Second, control the permissions by following the principle of Least Privilege. The less access granted the better in this case. Making the permissions as granular as possible. Run an audit of the roles needed and ensure that the necessary permissions are set for those roles. Having an admin that manages whitelisting and blacklisting will drastically increase the posture of the Bucket.
  • One major practice that is seemingly prominent in the industry is security education. Having a deeper understanding of security practices in place as opposed to an instruction guide will always be a stronger long-lasting solution. Watch this webinar for tips to educate and protect staff from security threats.

For more information on how to secure your systems, people, and processes, speak with a SecurityHQ expert. Or, if you suspect an incident, report it here.