Honey Buckets — Find out who is snooping through your Amazon S3 buckets.

Earlier this month we started working on a little side project after being notified of an interesting conversation on Twitter. The basic concept was using Amazon AWS S3 buckets as honey pots, which would identify when someone is doing reconnaissance against your brand or infrastructure. This seemed like quite a fun and novel idea we could turnaround in a short space of time, so we started fleshing it out.

Fast—forward a couple of weeks and we were able to come up with a rudimentary web application that folks could start to play with.

The general concept is as follows:

• The user supplies an S3 bucket name which is tempting to an adversary, and hopefully related to their business (such as reddit-db-backup).
• We register this bucket, setting the permissions to allow public listing & enable detailed logging. We originally used the access logs supplied free of charge by AWS, but found them to be too slow (minimum of an hour after the request).
• These detailed logs are processed by AWS and dropped into another S3 bucket, triggering an event & kicking off a lambda function we have created.
• This lambda function parses the logs, anything of interest is captured and sent off to breachinsider.com to be stored & subsequently allows us to alert the person who registered this honey bucket with us.

Overall there is roughly a 5 minute delay between someone visiting (or making an API call against) the honey bucket, and an email being dropped into the owners specified email inbox. Pretty good going — with the majority of the delay being down to how AWS batch process their logging events.

As mentioned, by using the advanced logging of the S3 buckets, we are able to retrieve detailed events for both HTTP requests & API calls. This is especially useful as scanning and identifying vulnerable S3 buckets does not just rely on whether they have public access enabled or not — many will do multiple checks against a bucket to see if it is insecure to different groups of users:

1. Public access — Essentially anonymous access, and leads to a directory listing type page when visited in a web browser.
2. Authenticated access — Here we need to be authenticated against AWS using valid credentials to be able to use the S3 APIs. Note: We don’t need to be authenticated against the bucket, only the AWS platform!

Those latter checks, whereby the scanner is authenticated (using AWS credentials), they are able to check if they can again read/list bucket contents, but can also query the bucket ACL (access control list). This can tell the scanner what permissions, if any, have been granted.

For example, you may be the owner of reddit-db-backup, and have ensured that none of the public access permissions have been enabled — perfect! But, you’ve accidentally allowed the Authenticated Users Group to have read/write access to the buckets ACL permissions. This allows anyone with valid AWS credentials to write their own access into the bucket, giving them full access if they so wish.

This type of attack isn’t detected via the standard web access logs that AWS supply, and therefore isn’t something we would have been able to trigger on. Fortunately, all API calls get logged when the detailed logging feature is enabled, so all of our Honey Buckets can & will alert of these advanced scans.

Why not try them out today, and find out who is scanning for your brand or infrastructure on AWS — Sign up for free.