S3 Buckets: Now With Both Leak & Fill Vulnerability

Earlier this week I had the privilege of providing insight for a Bleeping Computer article about the impending time-bomb that is world-writable Amazon S3 buckets.  While S3 security is not a new topic, what gets the most attention are world-readable S3 buckets containing sensitive & confidential data.  In fact, FedEx was in the news last week for leaking sensitive passport data via S3.  However, the S3 insecurity topic this week is renewed interest in world-writable buckets.

A quick aside for folks new to the topic: S3 is a product provided through Amazon Web Services that allows anyone to create cloud-based file storage.  These so called 'buckets' are basically virtual internet accessible hard drives.  Unfortunately, they are often misconfigured and allow misuse by attackers looking to steal or manipulate data.

(Related post: Last year I did a quick analysis demonstrating that many general web servers are also misconfigured allowing public access to sensitive information, similar to S3.)

What likely got conversation going again this week was a security researcher who began placing warning messages in exposed writable S3 buckets with the filename POC.txt.  The file itself was not malicious, but warned the account owners that they are at risk to malicious attackers.

What might that risk be?  Security expert Kevin Beaumont speculated in a tweet that these exposed files may be stolen and/or encrypted by attackers looking to extort companies for ransom.  Others speculated that these open buckets are ripe targets to host cryptojacking scripts -- the latest way attackers seek to monetize data breaches.  (PS - If you want to understand the prevalence of cryptojacking, read the statistics published daily by Bad Packets Report.)

I decided myself to test the feasibility of ransomware targeting an S3 bucket.  In an experiment (using my own account), I created an S3 bucket with bad permissions and wrote a quick proof of concept script that did the following:

1. Scanned the target S3 bucket for files
2. Attempted to download one of these files
3. Scrambled the text of the file (in my script I just used an md5 sum of the contents)
4. Deleted the original file
5. Uploaded the scrambled file with the extension .enc

...and it of course worked like a charm.

To Amazon's credit they are trying hard to warn people about the dangers.  Last year they rolled out an update to their administrative console that clearly displays if an S3 bucket is public.  And when I put together my PoC earlier this week, Amazon left this big warning to me.

My best guess is that the issue mainly resides in older S3 buckets which are maybe not undergoing any type of security audit.  I also assume in the past that many folks might have set a bucket policy with read/write/delete access because they were under the impression that it was read/write/delete only within their own account.  Furthermore, due to the obtuse syntax of setting up these policies, developers may be tempted to use s3:* to pull in all S3 related API calls into the policy, essentially making the bucket a ripe target for attackers.

This for reference is the bad bucket policy I used in my PoC. I can't see many sane people doing this today, but in the past if there was a misconception of the reach or currently if someone takes a shortcut with the wildcard it can certainly still bite.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "*"
            },
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::test_bucket_name"
        },
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "*"
            },
            "Action": [
                "s3:PutObject",
                "s3:DeleteObject",
                "s3:GetObject"
            ],
            "Resource": "arn:aws:s3:::test_bucket_name/*"
        }
    ]
}

As timely providence would have it Wednesday evening, news hit that the LA Times website was serving a cryptominer via - you guessed it - a world-writable S3 bucket.

No need to theorize anymore.  The attacks are a real and happening now.  Time to log in to your AWS console and give it a check up.

Posted: Feb 23, 2018