S3 buckets: straightforward example of misconfiguration

One of the most common cloud resources is AWS’s Super Simple Storage (S3). This is a scalable storage infrastructure that can be used for applications, backup, disaster recovery, data lakes, and more. S3 is widely used across every industry by millions of organizations.

Given they are so widely used, it should come as no surprise that misconfigured S3 buckets are the cause of many incidents. Even though object storage may seem like a simple concept, even S3 has over 70 configuration settings that can be changed. Many of these deal with access: who should be able to access which bucket.

Although S3 buckets were always private by default, many parameters exist that can control them accessible to the public: Block Public Access, Access Control Lists (ACLs), access points, IAM, transferring ownership, and more. Misconfiguring any of these parameters can result in impactful breaches. We’ll cover some recent incidents caused by S3 configuration issues below.

Incidents caused by unsecured S3 buckets

Twilio

In 2020, Twilio had a malicious version of their TaskRouter SDK uploaded to an S3 bucket that they owned. This S3 bucket, which served public content from the domain twiliocdn.com, had a misconfigured access policy.

The S3 bucket specifically had the following access policy in place, which allowed for anyone on the public internet to read and write to this path.‍

‍Using Resourcely, a guardrail like the below would have prevented this configuration from ever being applied.‍

‍The purpose of this malicious SDK was to inject malicious advertising into the Twilio networking, resulting in stolen data, malware, and other fraudulent activity..

Securitas

In 2021, it was found that Securitas had left an Amazon S3 bucket open without any authentication required - exposing 1.5M files equating to about 3TB of data. This included a variety of PII from four airports in South America:

• Photos of ID cards exposing PII
• Photos of planes
• Photos of employees

These ID cards could have been used by malicious actors to gain access to secure airport areas, or for use in frauds & scams targeting employees whose PII was exposed.

Colombian and Peruvian authorities could impose fines of up to $400,000, with Swedish authorities (where Securitas is based) possibly sanctioning other fines as well.

THSuite

Cannabis point-of-sale software company THSuit leaked government and employee IDs of over 30,000 individuals because of a misconfigured S3 bucket. Discovered on Christmas Eve of 2019, the bucket was left exposed for over 2 weeks until it was secured.

Leaked data included names, contact information, and medical data of customers, revenue information for individual dispensaries, and employee information including hours worked and salary information.

A publicly accessible S3 bucket may have the s3:GetObject permission granted to everyone, with something like this:‍

‍Using Resourcely, a guardrail identical to the Twilio case would have prevented this bucket from being publicly available.

India’s National Logistics Portal

Last year, a security researcher using Trufflehog identified publicly accessible S3 buckets with hardcoded credentials in them. This exposed the PII of crew members of ships that visited Indian ports, as well as invoices, shipping orders, and bills of lading for those vessels.

This exposure was caused by unsecured S3 buckets that had been misconfigured upon their creation.

Misconfiguration causes incidents

Deploying cloud resources can be a complex endeavor: especially in a world of DevSecOps where developers are expected to make security and infrastructure decisions. Writing Infrastructure as Code like Terraform or OpenTofu can be a daunting task, resulting in many developers and ops teams defaulting to widely available templates such as Terraform modules.

The problem with inexperienced, overworked developers and commodity templates is that they can be poorly understood. This often results in S3 access parameters being incorrectly configured.

Too often, organizations have no policies in place that would have prevented misconfiguration after the fact. This happens because configuration policy languages used today are too difficult to write and maintain. See an example of this in action here.

Preventing misconfiguration with Resourcely

Resourcely is a configuration engine that helps prevent costly incidents like those described above. With Resourcely blueprints, developers can customize templates for configuring cloud resources - from relatively simple configuration with S3 to complex, multi-resource blueprints.

One of the easiest ways to prevent incidents caused by S3 misconfiguration is implementing Resourcely guardrails. With Resourcely’s Really infra policy language, creating and maintaining cloud guardrails that prevent simple errors like S3 public access is easy to implement. When using Resourcely’s configuration engine, PRs that would violate cloud guardrails are surfaced ahead of time - so that issues can be addressed at development time, instead of waiting for the PR to fail.

Give Resourcely a try today to make sure your organization isn’t making a simple mistake that could end up costing a fortune.

‍