Tools Resources

Download as PDF

The Definitive Guide to Securing AWS S3 Buckets: Best Practices and Risks Unveiled - Panoptica

Part 1: What are S3 buckets and how can you access them?

Part 2: Risks of misconfigured $3 buckets and what you can do about them

Introduction

In this eBook we will dive into:

Part 1: What are S3 buckets and how can you access them?

Part 2: The risks of misconfigured S3 buckets and what you can do about them

Cloud is complicated. And with all the new features, capabilities, etc., it’s not likely to get any less complicated with time. Sorry to be the bearers of slightly bad news. For example, did you know the AWS S3 bucket user guide is 1,515 pages long? Go ahead and check.

In the unlikely event that you plan to read all that documentation cover to cover (kudos if you do), we’re offering a “cliff notes” version of said documentation explaining what S3 buckets are and how to properly secure them.

Join us as we review the common pitfalls of using S3 buckets and as we reveal best practices for keeping your cloud environment more secure.

Let’s dive right in...

Part 1

What are S3 buckets and how can you access them?

What is an S3 bucket?

S3 stands for simple storage service, and it is AWS’s cloud storage service. S3 provides the ability to store, retrieve, access, and back up any amount of data at any time and place.

As S3 is object-based storage, this means that all data is stored as objects.

Each object has three main components:

The object’s content
The object’s unique identifier
The object’s metadata (including its name, size, URL)

An object cannot be independent, it must exist within a bucket. There can be hundreds of buckets in each Amazon account and within each bucket, there can be hundreds of objects.

How to access objects within an AWS bucket

Access to a bucket is granted in the same way as with any other AWS resource — you need an explicit ‘allow’ and no ‘denies’ to be given access.

The explicit allow can be given in three ways — bucket policy, bucket ACL, and object ACL.

S3 bucket policy

This is a resource-based AWS Identity and Access Management (IAM) policy. You can add a bucket policy to a bucket to grant other AWS accounts or IAM users access permissions to the bucket and the objects inside it. Object permissions apply only to the objects that the bucket owner creates.

S3 bucket ACL/object ACL

This is a sub-resource that is attached to every S3 bucket and object. It defines which AWS accounts or groups are granted access. If it defines access as public, that will allow everyone permissions, whereas if it defines access only to an authenticated user group, this means anyone with an AWS account will have permissions. It also defines the type of access these users have, such as read or write access.

When you create a bucket or an object, Amazon S3 creates a default ACL that grants the resource owner full control over the resource.

Bucket ACL

Object ACL

Block Public Access

Creating your own S3
bucket permissions

Amazon provides the ability to define settings for blocking access points, buckets, and accounts to help you to manage public access to Amazon S3 resources. By default, public access to new buckets, access points, and objects is not allowed.

The block public access settings consist of four options that you can apply in any combination to a bucket or to an entire AWS account. If you apply them to a whole AWS account, these settings will apply to every bucket in the account.

Here are the four options, in the same order as on the console, if you’re looking to manage and access S3 bucket using AWS cli names:

Block public Acls While set to TRUE, no new ACL definitions are allowed, but the existing ones still apply. Meaning, if there is a bucket with an ACL granting public access, the BlockPublicAcls will not affect it.
Ignore public Acls While set to TRUE , it causes Amazon S3 to ignore all public ACLs on a bucket and any objects that it contains. Meaning, all public access granted by a bucket or object ACL does not apply.
Block public policy While set to TRUE, no new policies can be attached to the bucket, but existing ones still apply. Meaning, if there is a bucket policy that grants public access, the BlockPublicPolicy will not affect it.
Restrict public buckets While set to TRUE, if there is a policy that allows public access, the access is restricted only to AWS service principals and authorized users within the bucket owner’s account.

AWS bucket access

AWS evaluates the access scope for each bucket and presents this in the management console.

There are four access options:

Public
Objects can be public
Only authorized users of this account
Bucket and objects not public

These are the only potential outcomes of any access settings applied.

We have created the following diagram to better explain how AWS evaluates the access:

The problem with AWS’s evaluation

As you can see, these four access options don’t necessarily allow you to provide definitive answers to whether your objects are public or not, and which buckets are secure. While ‘Public’ is a black and white outcome, and so is ‘Bucket and objects not public,’ the other two are more open ended and could lead to some confusion. In particular, the outcome of ‘Objects can be public’ leaves your security teams none the wiser about whether items are accessible or not.

Let’s break it down with an S3 bucket example

Let us assume we have a developer who works with a bucket, and in it, they put a folder with objects, using its ACL to make it publicly accessible. At some point, they want to store some sensitive information in the same folder, so they need to make it non-public.

To do so, they use the block public access settings, specifically IgnorePublicACL, and the bucket and everything in it, is no longer public. The official status is ‘Bucket and objects not public.’

Time goes by, our developer leaves the company, and a new developer joins the team and takes over their role.

This new developer wants to create a new public folder in the same bucket for the company’s website, so he changes the IgnorePublicACL back to false, and grants public access to the new folder using its ACL. The bucket status has now changed and is now ‘Objects can be public.’ This new developer is not aware that their actions have changed the status of other information inside the bucket, as they do not receive an alert about the old developer’s folder with the sensitive information that has now become public again following their actions.

The question is… what can we do about it?

How can we be sure that we know what objects are public, and which are not? In the next section, we will be discussing the specific risks of misconfigured S3 buckets and human error (as described above), and we will dive into our own Panoptica research that uncovered a cross-account attack path you should know about.

Part 2

Risks of misconfigured S3 buckets, and what you can do about them?

Risks involving misconfigured buckets

Amazon S3 comes from simple storage service — three words
beginning with the letter “S,”— and S3 was born!

There are two main risks when considering misconfigurations on AWS buckets, read and write access permissions.

First, a misconfigured S3 bucket that allows public read access can lead to a customer data breach.
Second, a misconfigured S3 bucket allowing public write access can be used to serve or control malware, damage a website hosted on a cloud storage service, store any amount of data at your expense, and even encrypt your files for the purposes of demanding a ransom.

Suddenly nothing so “simple storage service” about it, eh?

Real life examples of these kinds of S3 bucket security issues

There are several high-profile examples of access management issues or customer data breaches and security incidents that occur from misconfigured S3 buckets.

Booz Allen Hamilton is a leading U.S. government contractor, famous for a data breach that involved misconfigured buckets. Booz Allen Hamilton left sensitive data on AWS S3, publicly accessible, exposing 60,000 files related to the Department of Defense. In a case like this, the baseline expectation is that there would at least be default encryption, but a huge amount of data in the S3 bucket was stored with no encryption at all. The company claimed that they had no need to encrypt data as the data itself was not classified, but it included credentials to sensitive government systems, credentials belonging to senior engineers at Booz Allen, and more.

Another example is Verizon, an American wireless network operator, who failed to secure their security controls or bucket policies. This company suffered from two data breaches only a few months apart, exposing more than 6 million customer accounts. That’s a huge amount of data!

Both breaches were caused by S3 misconfigurations.

60,000

files exposed related to the Department of Defense

Booz Allen Hamilton is a leading U.S. government contractor, famous for a data breach that involved misconfigured buckets.

Researching the current status of AWS buckets

To understand the scope of the issue, we started by searching a few AWS customer environments to examine their public S3 buckets, and their “objects can be public” S3 buckets. (See part one for a list of definitions).

The results were quite interesting. The average amount of public buckets stands at almost 4% per company, and the average amount of “objects can be public” is around 42%.

This means that almost 50% of a company’s buckets could potentially be misconfigured!

To describe our research in more detail, here is what we tried to accomplish:

We wanted to get a hermetic image of the possible outcomes of using the block public settings. We simulated every combination, trying to access the bucket and objects, and then documented every result.

The most interesting cases were when AWS evaluated the bucket status as “objects can be public,” and as mentioned in part 1. That’s not surprising because this is the most confusing definition.

It’s clear that because AWS evaluation is happening at the bucket level, and it does not take into consideration the objects’ ACLs, this will invariably open companies up to risk as this is the key for understanding where they might be vulnerable.

Current status of AWS buckets

We started by searching a few AWS customer environments to examine their public S3 buckets, and their “objects can be public” S3 buckets.

4%

Average amount of public buckets

42%

Average amount of “objects can be public”

50%

Average amount of buckets that could potentially be misconfigured

Panoptica’s Python research

As our research indicates, the “object can by public” status is very common. This nearly 50% occurrence prompted us to build a solution that could help to mitigate this issue.

An unexpected find!

Cross-account attack on S3 buckets

While performing our research, we spent a significant amount of time analyzing bucket policy examples, so that we could fully understand which ones allow public access.

It was then that we came across an interesting case, where the policy grants AWS Config and CloudTrail service access to a bucket. These two services use S3 Buckets to store their output, and while setting them, the user must choose whether to create a new bucket, to use an existing one from their own account, or to use an existing one from another account.

CloudTrail example

Config example

Many users can ease the process of specifying several different accounts as a list by creating a general path instead.

A general path can be:

arn:aws:s3:::{bucket-name}/*
arn:aws:s3:::{bucket-name}/AWSLogs/*
arn:aws:s3:::{bucket-name}/AWSLogs/*/ Config/*

This case is common when using the AWS Organizations and Control Tower, which creates a dedicated account for logging and auditing. When you have only a few accounts, that can work with a bucket policy with several resources for the other accounts. However, when you have 100 or 1,000 accounts, wildcards are mostly in use, which can open you up to risk.

The tricky thing in this case is that since the principal is the AWS service, the source account is evaluated from the resource, as opposed to normal bucket policies.

Each one of the general resource path patterns above will enable any AWS account to define the bucket as their Config bucket, and by doing that, use it to store their data at your expense. It does not allow them to read objects that are stored in the bucket, only to write new ones, making it the second category of risk we discussed above.

This configuration opens your bucket to unauthorized writes from any Amazon Web Services account.

**Note: In our research, we tested AWS CloudTrail and Config but this issue may be valid for other AWS Services that use S3 Buckets to store their data by default. In other cases, the permission may also be a read permission that can lead to a serious data breach.**

Securing your S3 buckets

You wouldn’t ignore your physical security risk, and this is no different. Here are the top tips for staying informed and proactive of file storage in Amazon S3 buckets and S3 bucket misconfigurations and access management.

Stay alert. Continuously assess the S3 bucket states in your account and your access control lists — you can use config rules or AWS “Access Analyzer for S3” for that. Notice that the “Access Analyzer for S3” does not cover the two main cases we discussed — the cross-account attack and the bucket with “objects can be public” status that has publicly accessible objects.

Don’t assume. Never assume that buckets are private. To deny public access, it is preferable to use the block public access, and not a deny policy.
Avoid wildcards. Your buckets and objects are your responsibility. Try to make your policies as specific as you can.

Conclusion

With any cloud service, there are associated risks and possible vulnerabilities. Amazon’s S3 is no exception. This is a widely used service and due to human error or simple out of the box default settings, your cloud environment or organizational data could be at risk. As with any service, it is essential to conduct due diligence and ensure a deep understanding of how services handle access rights and privileges to put best practices in place.

As part of enjoying the services provided by AWS and other cloud service providers, there is shared responsibility to ensure proper access and authentication occurs to keep your data safe and secure. While AWS certainly works hard on their side to ensure they implement the highest levels of protection, we have highlighted in this eBook, that even the best of services can suffer from common misconfigurations that lead to unintended risks.

To ensure you are doing your part, an initial step is leveraging a tool that provides as much visibility as possible across your cloud environment.

The Way Forward

A single, comprehensive platform to meet dynamic shifts in cloud security requirements

With rapid changes to the cloud occurring on a constant basis, a complete cloud security platform is required to protect and secure your cloud stack and business assets, from build to runtime. At its core, best practices indicate that organizations, to minimize unintended risks, including those connected to misconfigured S3 buckets, should partner with vendors who offer:

Through a unified platform that provides all aspects of cloud security under the umbrella of a singular, integrated platform — improve your ability to proactively protect your most valuable assets while reducing the effort required from your team.

Graph-based technology at the heart of the system: Gain complete visibility of the entire cloud stack across cloud providers and better understand all potential areas vulnerable to attack.
Proactive cloud security research: Preemptively deep dive into cloud security issues, staying one step ahead of security trends and potential attackers.
Prioritization: Examine a variety of layers within multicloud environments to build the story behind each disparate security finding and better understand the relevant context between findings to surface what risks really matter.
Remediation: Out of the box remediation to reduce the time it takes for your Sec/DevOps teams to better secure any discovered vulns. Dynamic deny guardrails can be tailored to your organization’s specific requirements, meaning no one size fits all. Instead, a customized solve for your specific risks.

Panoptica is Outshift by Cisco’s cloud native application protection platform (CNAPP) that uncovers and remediates vulnerabilities during development through to production, ensuring your applications and cloud environments are secure and compliant. Through graph-based technology, the platform is able to unlock visual insights, critical attack paths, and speed up remediation to safeguard your modern apps across multiple hybrid cloud platforms.

To learn more visit: https://www.panoptica.app/

Schedule Demo

Get Started

Solutions

The Definitive Guide to Securing AWS S3 Buckets: Best Practices and Risks Unveiled - Panoptica

Table of Contents

Introduction

Part 1: What are S3 buckets and how can you access them?

Part 2: Risks of misconfigured $3 buckets and what you can do about them

Conclusion

About Panoptica

Introduction

In this eBook we will dive into:

What are S3 buckets and how can you access them?

What is an S3 bucket?

Each object has three main components:

How to access objects within an AWS bucket

S3 bucket policy

S3 bucket ACL/object ACL

Bucket ACL

Object ACL

Block Public Access

Creating your own S3 bucket permissions

AWS bucket access

There are four access options:

We have created the following diagram to better explain how AWS evaluates the access:

The problem with AWS’s evaluation

Let’s break it down with an S3 bucket example

Risks of misconfigured S3 buckets, and what you can do about them?

Risks involving misconfigured buckets

Amazon S3 comes from simple storage service — three words beginning with the letter “S,”— and S3 was born!

Real life examples of these kinds of S3 bucket security issues

60,000

Booz Allen Hamilton is a leading U.S. government contractor, famous for a data breach that involved misconfigured buckets.

Researching the current status of AWS buckets

This means that almost 50% of a company’s buckets could potentially be misconfigured!

Current status of AWS buckets

4%

42%

50%

Panoptica’s Python research

Cross-account attack on S3 buckets

CloudTrail example

Config example

Securing your S3 buckets

Conclusion

The Way Forward

Creating your own S3
bucket permissions

Amazon S3 comes from simple storage service — three words
beginning with the letter “S,”— and S3 was born!