Misconfiguration

Introduction

Never attribute to malice that which is adequately explained by misconfiguration.
— Zabicki’s Razor (with apologies to Hanlon)

Attackers are opportunistic. They won’t bother with a sophisticated attack where a simple one will do, and seeking out and exploiting misconfigured systems is one of the simplest attacks there is.

We need to develop the capabilities for ongoing monitoring of our systems to make sure we haven’t made the kinds of configuration mistakes that will open the door for easy attacks. The specifics of how you do this will vary significantly depending on the exact technologies you use in your organization. We’ll take a look at some of the most common misconfigurations and some tools to detect them. Even if you don’t use these specific tools, these examples should give you an idea of the kinds of mistakes you’ll want to be able to find.

Open S3 buckets

Amazon offers a popular storage service called Simple Storage Service, or S3 for short. S3 is a large-scale key-value storage service that lets users store file-like “objects” inside of “buckets.” A bucket can hold an arbitrary number of objects, and an object can range in size up to 5TB. Behind the scenes, S3 is a highly durable storage service that automatically distributes data across multiple physical facilities. Amazon offers a lot of tools as well, including tools for big data analysis that integrate natively with S3.

It’s really neat. It also seems to be really easy to misconfigure.

A quick Google search for “S3 breach” will show many high-profile instances of misconfigured S3 buckets that left sensitive data open for the world to see. No need for fancy attacks or cryptographic breakthroughs if the data isn’t protected in the first place.

One particularly easy S3 mistake to make involves something called the Authenticated Users group. AWS permissions are based on group membership. So, when setting up permissions, an administrator will typically create groups that represent the organization and assign permissions to those groups. The Authenticated Users group is a predefined group in AWS. It would be easy to look at the name and think that it describes the group of people that are authenticated users of one’s own organization. That is not what that group means, however. Anyone who is logged into AWS as a part of any organization is automatically a member of the Authenticated Users group. If we look at the relevant documentation we’ll see this:

When you grant access to the Authenticated Users group, any AWS-authenticated user in the world can access your resource.

And just below that, we see another predefined group called the All Users group. Amazon’s documentation has this to say about the All Users group:

Access permission to this group gives anyone in the world access to the resource. The requests can be signed (authenticated) or unsigned (anonymous).

So, if you give the Authenticated Users group read access to your S3 buckets, you are giving read access to everyone in the world who has an AWS account. And any access you give to the All Users group is access that you are also giving to everyone in the world, regardless of whether or not they have an AWS account.

The Authenticated Users and All Users group misconfigurations are a great example of the kind of misconfiguration we need to be able to detect. It’s easy to see how they could be misused. It’s easy to see the impact this could have. It’s easy to see how their misuse could happen at any point in the life of an online system. It’s easy to see how attackers could automate the detection of this kind of misconfiguration and find this flaw in your system, even if they never had any reason to seek you out specifically.

A problem like this calls for automation. One tool that can help with finding misconfigurations like this is Scout2. Scout2 is an open-source tool designed to look for a wide range of AWS misconfigurations, not just overly permissive S3 buckets. Installation and usage is outlined on the GitHub page and is fairly straightforward. Scout2 works by using AWS credentials that you provide to query the extensive AWS APIs to find common misconfigurations. It then takes the results of these queries and creates a report that summarizes its findings. At the time of this writing, it’s still under active development with new misconfiguration searches being added periodically.

It only takes a couple of minutes to install and run Scout2. So, if you use AWS, it’s probably worthwhile to run it right now and see if you have anything pressing to fix before continuing on with this chapter.

I’ll wait.

Now that you’ve run Scout2, it’s worthwhile to budget some time to automate the regular generation of a Scout2 report. Even if everything is locked down perfectly today, mistakes could be introduced tomorrow. And if bad things happen in the future, it can be helpful to look back on a record of when things changed.

---

In the next lesson, we’ll study the problems that using default passwords can create.