Are you pulling files from an S3 bucket that was abandoned and then rigged by bad guys to deliver malicious payloads?

This is a spin on an existing attack commonly done on abandoned domains. It just has been brought back into the spotlight. It still is worth checking out.

Example:

Let's say I run a popular open-source software and host it on explodeme.com.

You, being the diligent dev you are, write a script that automatically checks my website to see if there is a new build of the software, automatically downloads it, and updates anywhere on your system you might be running the software.

After a while I get bored and decide I don’t want to host this any more so I stop paying for the domain.

Some malicious parties decide to buy the domain then point it at their servers. They then make it so the exact URI that was used to download my old legitimate opensource updates now points to a new set of files that they wrote. Files that include all sorts of evil goodies.

That is how it is done with domains, but let's examine how it works with S3.

Enter S3:

With S3, each bucket needs a globally unique namespace. That means no two global S3 buckets can have the same name regardless of whose AWS account they are in.

For example when I was in my new On Demand Course for O'Reilly(Coming soon) I tried registering my-test-bucket and it wouldn’t allow me to do that because someone I had never met before on an AWS account I will never log into had already registered a bucket with that exact name.

The way this attack works is similar to the domain attack. Here is an example:

1. I host my open-source project on S3.
2. You automatically pull my code from S3 to keep up to date.
3. Eventually, I stop paying to host it.
4. AWS shuts it down because I stopped paying.
5. Bad guys register an S3 bucket with the same name and put their malicious code at the exact same path where I used to keep my latest build.
6. Your scripts pull down their malicious payload, and bad things happen.

Cost implications:

What makes this even worse than the domain attack is that this is even cheaper to run. You have to pay at minimum $13 dollars to register a domain. You can easily register an S3 bucket while inside the free tier.

Preventative Measures:

The hosting party can’t do a lot here, I suppose use long unique names but if you publicly link to or reference these buckets bad guys are going to find them.

As for the downloading party you need to be really careful. Have eyes on these types of updates. Even if you do an MD5 check of the source code you are downloading you need to ask “Where am I getting that MD5?”. If the MD5 is in a text file stored in the same S3 bucket it won’t do a bit of good.

The good news is back in 2020, AWS released a new feature called the “Bucket Owner Condition” that allows you to confirm the ownership of a bucket before performing S3 operations.

You simply pass a numeric AWS Account ID to any of the S3 Bucket or Object APIs using the expectedBucketOwner parameter or the x-amz-expected-bucket-owner HTTP header. The ID indicates the AWS Account that you believe owns the subject bucket. If there’s a match, then the request will proceed as normal. If not, it will fail with a 403 status code.

Wrapping It Up:

Let me know if you want to hear more about these devious S3 attacks. I do enjoy diving deep into this type of hackery. ~Cheers