The Amazon AWS S3 honeypot

Amazon AWS S3 Honeypot

In my previous post on this subject, I looked at how easy it was to both find and harvest data from unintentionally exposed public S3 buckets. It’s here if you’d like to read it.

At the end of that article, I talked about setting up a honeypot to measure the level of unauthorised activity public buckets typically receive.

I set up a public bucket, it was called ‘accuse’ and could be found at accuse.s3.amazonaws.com. The name came straight out of the dictionary. I wanted something that appeared near the top of wordlists that assailants might be used to brute force bucket names.

I enabled S3’s logging facility, filled it with some juicy bait, sat back and waited for the requests to come flooding in.

Amazon AWS S3 Honeypot Files

S3 Logs

The logs came flooding in, after just a day I had almost 100 log files sat in my bucket. Unfortunately, however, on further inspection, none of these represented any malicious activity at all. Initially, the log files logged my activity in setting up the bucket and filling it with bait. I then realised the log files were self-perpetuating, logging the creation of the previous log file in the next. Along with this my actions when checking the log files were all being recorded and muddying the water.

I turned back to my good old friend NodeJS and knocked up a quick S3 log file parser. I could now eliminate all the noise and parse the log files quickly. After parsing the logs, I deleted them from the bucket, as I was worried they would deter a would be bucket thief. The log files appeared at the top of any request to list the contents of the bucket and buried my bait files.

Then I waited…

And waited some more. After several days I decided I needed to step this up a notch. Perhaps my bizarre bucket name choice wasn’t interesting enough.

I decided to work my way through Alexa’s list of top websites in the UK (https://www.alexa.com/topsites/countries/GB) and would call my bucket after the first available name.

In a discovery that represents nothing short a national scandal, the first available bucket name, representing site number 11 on the list of most popular sites in the UK, was ‘ladbible.com’. Now, I’m not particularly au fait with the inner workings of Alexa, to be honest, I remember it as browser plugin from the early 2000’s and have no idea how it works today. I have to assume that Ladbible.com scoring 11th on the list of most popular websites in the UK has something to do with Facebook and the endless stream of trash that fills most peoples feeds on a daily basis (part of the reason you won’t find me on Facebook).

Nevertheless, I set up my Ladbible bucket and began the waiting game all over again…

I appreciate the true art of a stakeout is waiting, but I’ve got this blog post to write and a podcast to record. I honestly thought we would see some instant results but again after 3 days of waiting, there was not a single request to my bucket that wasn’t either me or AWS itself. Even if I leave the bucket online for a year or more and then assess the logs, it doesn’t really reflect the ruthless assault on public S3 buckets that perhaps I thought we might see.

Conclusion

It’s very hard to draw any conclusive results from this test. Perhaps there simply isn’t quite the appetite for public buckets that I perhaps first thought there might have been?

I suppose this is a good thing? My earlier experiments have shown data that could be leveraged by bad actors is just sitting in public buckets as a free download. The fact nobody is looking for it quite as thoroughly as I’d anticipated does surprise me, this is relatively old news after all. Maybe system admins and businesses have still got time to get their act together after all.

What now?

Well needless to say, I’m not done yet. There are two more interesting strands to this story:

1. Fuzzing private buckets for public files

When I asked @VickerySec at UpGaurd to look over my first post, he suggested that his success in unearthing some of the most embarrassing bucket finds to date relied on him searching for public files within private buckets. This means there is no nice file list to work from, but rather we need to keep guessing object keys until we find something that exists.

I’ve got a good strategy on how to implement and experiment with this approach, which will probably form part three of this series in a week or so.

2. Public writable buckets

Yes, unfortunately this is a thing. I honestly can’t think of a use case for this, surely you would want any write access to be available to authorised users only, anything else would be carnage?

Again, in many cases, publically writable buckets exist simply because it’s been overlooked by developers or accidentally/temporarily enabled and then forgotten about.

How long before we see some form of S3 ransom/blackmail ware?