Here’s How Easy It Is To Find And Access Misconfigured Amazon S3 Instances
There have been an increasing number of reported breaches and leaks that have occurred through ‘misconfigured’ Amazon S3 buckets. In reality what this means is someone fired up an instance, didn’t know how to lock it down, and left it in ‘Public’ mode. That means every file placed in that S3 bucket is freely accessible to anyone that has the address.
An assumption that people make is that since my bucket name is ‘unique’ and I don’t tell anyone what the address is, no one will find it. Wrong. So wrong. In fact it’s dangerous to ever assume that anything will be obscured if you keep the name to yourself. If it’s on the Internet, live and talking, it will be found.
This post will break down how security researchers and malicious agents are finding these buckets. Like most things it’s far simpler than you realize and all you need to know is where to look.
Amazon S3 Buckets
An S3 Bucket is a web server that can be spun up in about 15 minutes and all you need is a credit card. When you setup an S3 bucket and don’t understand or don’t know how to do it, they can be left wide open without you realizing it. Amazon has put more warnings in place to alert you but the misconfiguration is still in place on older, legacy or forgotten about instances.
All Amazon buckets follow a predictable naming convention, which doesn’t help the situation either.
The buckets are named as such: http://s3.amazonaws.com/[bucket_name]/ or http://[bucket_name].s3.amazonaws.com/ – that’s it.
How To Find Them
Being that hitting an URL is all you need a simple script will set you on your way to hunt for S3 buckets. There any many scripts out there but the most popular and basic one is from a security developer and it’s simply called Bucket Finder, you can get it here. The Bucket Finder is a Ruby script and uses a Word List for its search.
A Word List is a text file with thousands, or millions, of words. The script simply goes through the Word List and tries to see if it’s a live S3 Bucket. There are websites dedicated for different kinds of Word Lists, based on specific subjects, complexity, specifically built for whatever targets you are working on, etc…
As the script traverses the list it will create a log file of the results. You will see if the S3 Bucket exists or not, if it’s accessible if it does exist and one step further it will list out the first 1,000 files and whether those are Public or Private.
It takes the next word on the list and hits the URL with the bucket name in the address.
Here’s an example of how easy it is to find S3 Buckets.
Bucket found but access denied: officer
Bucket found but access denied: old
Bucket does not exist: old-timer
Bucket found but access denied: older
Bucket found but access denied: one
Bucket does not exist: opponent
Bucket found but access denied: organ
Bucket does not exist: originators
Bucket found but access denied: other
Bucket Found: outxxx ( http://s3.amazonaws.com/outxxx )
As you can see above, each Bucket name is just a word from the Word List. A few were found that exists but they are locked down from Public view. It found one that is live (I obscured the name) and is open to the Public and listed all the files within. From looking at the list I assume this is unintentional. There are no HTML files to tell me this is a web portal or has a UI for the files and the file names look like basic file use. It’s a repository, external storage… and every file is available for download. I just have to cut and paste the URL of the file and I can get it.
It’s that easy.
Researchers, criminals and curious security professionals are continuously searching for open Buckets. That’s how these breaches are being discovered. They aren’t leaked or phished, they are found through this method. Probing the open Internet. Real pros are using Word List creation tools to create variations in names to stumble across naming conventions and obscure labels.
As an example take the recent Verizon S3 leak. In semi-defense of Verizon this bucket was not Verizon owned. Rather an employee, or now former employee, of Verizon spun up an S3 bucket for their own use for Verizon work.
I will be writing another post about the new Shadow IT Cloud threat for companies.
The engineer that opened the Bucket placed proprietary Verizon files in it but didn’t lock it down. How was it found? It could have been a simple name or a researcher built a Word List targeting Verizon and came up with VerMN01 as the name (as an example, I don’t know). Point is, they probably got lucky and stumbled on it. Saw the files called Verizon_Confidential and it went downhill from there.
A Word List generator can take 100 words and generate 100,000+ unique labels to try. Target 100 relative words to a target and it’s only a matter of time.
Cloud Doesn’t Absolve You From Security Responsibility
I despise ‘Cloud’ as a term. Cloud services are just someone else’s computers. Amazon services provides you the infrastructure and will secure it from the outside. However, you can leave your world wide open if you don’t know what you are doing. More and more breaches are showing that this is the case. Through naivety, arrogance that they know best or people just don’t know, there are thousands of Public Buckets exposed that may not be intended to be.
It’s not a matter of IF but WHEN they will be found.
All the hackers have to do is setup a few lines of a script and sit back and let the results come in.
End of Line.