Introduction
In 2017, a Verizon Wireless partner unintentionally misconfigured access controls for an Amazon S3 service, exposing an approximate 6 million records containing customer names, contact information, home addresses, account financials, and even account pins. Verizon was privately informed of the exposure on June 13th, 2017, and the misconfiguration was remediated on the 22nd. While the service remained misconfigured, anyone with an Internet connection could easily view part or all of this data.
In the age of massive adoption of cloud storage solutions, unfortunately, we see exposures like this all too often. Cloud services appear simple to configure, but a small error can expose entire datasets on the public Internet. You may manage many storage buckets with different access levels for internal and external use, and it can quickly become difficult to manage your configurations. Cloud storage exposures are particularly troublesome as it’s easy for an attacker to access or modify data while a storage bucket remains misconfigured. High-profile breaches of S3 buckets and other cloud storage assets have now occurred at the US Department of Defense, Dow Jones & Co, and Booz Allen Hamilton.
This blog explores how an S3 bucket misconfiguration can lead to a breach through a step by step analysis:
- Creating a new Amazon S3 storage bucket
- Configuring the access control list (ACL) for this Amazon S3 bucket
- Common attacker vectors to access data once the bucket’s permissions are configured
- How to check for potential unintentional exposure of Amazon S3 buckets using the Censys ASM Platform
Analysis
To demonstrate the complexity of cloud storage access configuration, consider Amazon’s ‘Authenticated User’ access group for buckets. This might not sound so scary at first, right? However, in Amazon nomenclature, an ‘Authenticated User’ is anyone with at least a free-tier AWS account. In other words, if your S3 bucket is configured with ‘Authenticated User’ group access, anyone willing to sign up for an AWS account has full access to your data. There have been documented, large-scale exposures related to a practitioner misconfiguring a storage bucket using this access group.
To illustrate how an attacker might compromise and exfiltrate data from a storage bucket, we’ll walk through an example using the AWS CLI tool.
Using a private account, we’ll create a new storage bucket.
Now, it’s time to configure the ACL policy for this bucket. We’ll give the ‘Authenticated users group’ read access, as we want our colleagues to be able to view any documents stored inside the bucket.
With our bucket created, it’s time to upload some data. `ohno.txt` is the file that we want our colleagues with AWS accounts to be able to read.
Let’s pretend that a few weeks have passed, and our internal team has been using this bucket with great success.
Unfortunately, an attacker has discovered that our company uses `my-exposed-bucket` as a project name, and wants to leverage this to uncover potentially exposed data in our storage bucket. They note that hitting `https://my-exposed-bucket.s3.us-east-2.amazonaws.com/` in their browser returns an `AccessDenied` error code, informing them that a storage bucket exists under this name.
The attacker now knows that they can potentially view this information. They configure their personal AWS CLI tool, and try to list the bucket using the `ls` command. They find that the bucket is exposed, and contains a `txt` file named `ohno`.
To access exposed data, the attacker uses the `cp` command to copy contents to a directory on their personal machine. Here, we copy `ohno.txt` to `./Desktop`.
The information from the bucket is now on the attacker’s personal machine. Thankfully, our exposed document is benign in content!
Of all the storage buckets managed by Censys ASM, ~8.5% are exposed as publicly readable, writable, or with editable configuration settings. Across all of your cloud storage providers, this can amount to a sizable portion of your storage buckets being misconfigured and can lead to attacks as illustrated above.
What Can I Do?
The good news is that bucket misconfiguration is a solvable problem. By implementing best practices within your team and introducing automated solutions for uncovering risks, you can better protect yourself from exposures.
- Ensure that your cloud storage services have appropriate IAM policies configured.
- Create and communicate strong security policies within your team. NIST provides comprehensive security guidelines for storage infrustructures.
- Consider implementing an automated ASM solution for identifying cloud storage misconfigurations. Censys is the only ASM vendor that finds risks associated with the storage buckets that you own, and automatically leverages your data to uncover unknown storage buckets that may impact your security posture.
- Current Censys ASM customers can navigate to the storage buckets list page to view an up-to-date collection of their storage buckets and any associated risks. Not a Censys ASM customer? Get in touch via the Censys contact page!
——
