S3 Amazon public content in danger of being hacked

All S3 Amazon account holders should be aware that there are hacker scripts around that scan for public content in S3 buckets. Amazon has warned all account holders if they have public buckets.  Reading public content is quite easy since public files are readable to everyone. But what does that actually imply and what can you do about it?

What are those hackers doing?

It means that hackers may be able to place links to your public content on any site or peer-to-peer network and you pay for the bandwidth.  This can add up very quickly if you are unlucky.  So far, the use of public videos and audios was convenient to show content you do not mind sharing freely.  But with this new situation, this is no longer a good idea.  So, for videos that are meant to be public, I would move them to YouTube if they are not too lengthy.  Audios is another matter, so I would make them private from now on, even if you want visitors to be able to download them.

Testing with policies

I don’t think there is a big problem with images, as long as they are not too big, but any rich media should be set to private.  As it is is nearly impossible to trace where all my videos are published over various websites, I have been experimenting with Amazon  policies so that I do not need to use expiring URLs for every public video when I make the buckets private.
What I actually mean is this: I set a bucket and its content to private. So, from then on, it cannot be accessed by anyone, unless via an expiring URL.  But instead of using an expiring URL, I create a policy that lets me access private files only on the sites I determine.

A policy is a script with which you can control access to your files and it can do a couple of other things as well, but I’m not going to go deeper into that.

Below I show a policy that works for regular content:

{
  "Version":"2008-10-17",
  "Id":"http referer policy example",
  "Statement":[
    {
      "Sid":"Allow get requests referred by www.raboo.info and raboo.info",
      "Effect":"Allow",
      "Principal":"*",
      "Action":"s3:GetObject",
      "Resource":"arn:aws:s3:::rudolfboogerman/*",
      "Condition":{
        "StringLike":{
          "aws:Referer":[
            " http://www.raboo.info/*",
            " http://raboo.info/*"
          ]
        }
      }
    }
  ]
}

In this policy, I grant the website raboo.info access to the bucket rudolfboogerman.
Although this works for regular content distributed via the S3 bucket, it does not work for CloudFront distributions, so streaming video and audio or anything that is linked to via a CloudFront distribution cannot be unlocked using this policy.

Bottom line:  use expiring URLs for everything that is distributed via a CloudFront distribution. Generally, you will want to use CloudFront distributions for rich media like audio and video.  Images, PDFs, zip files and so on, can be distributed via the regular S3 bucket.  Visitors downloading content will hardly notice the difference in downloading time and you do not incur the extra cost of CloudFront distributions, although that cost is marginal.

Expiring URLs

This is not so easy to accomplish. Generally, you will want to work with a plugin or extension that provides this kind of functionality. The unbeaten champion in terms of features and support is our very own S3Media Stream™, available for both WordPress and Joomla.  If you want to protect your video and audio via S3 Amazon, check it out on either www.joomla21century.com or www.wp21century.com.