S3 Security and Privacy: What is Old Is New Again

There is a lot of buzz around S3 security lately. The news is riddled with headlines that say something to the effect of “Massive Data Breach Due to Insecure S3 Bucket.”  What is going on with S3 with regards to data security and privacy?!  Why can Amazon not fix this?  Let me start out by saying there is nothing wrong with S3 security and privacy in itself. Now when you read the title of the article and saw S3 you may have just assumed that S3 is synonymous with Amazon however that is not totally correct. Corporations can run S3 compatible servers on their LAN Networks and even in cloud providers other than Amazon.

S3 stands for Simple Storage Service and is a protocol for data storage, transmission and retrieval that is easy to implement.  S3 allows developers, via scripts and other methods, to utilize virtual unlimited storage and capabilities across traditional clouds as well as hybrids.  S3 can be run on S3 compatible servers on premises or in the cloud as a service. Once data is in S3 it can be moved around very quickly to other resources and made available to a variety of applications such as web browsers and natively in almost every flavor of coding language.  An example of this is that a simple site can ingest pictures and documents and store them in S3.  Then other resources can access the same S3 data and process it and move them to other applications and servers.

Now that you know a little about S3, I will explain my opinion on S3 Security and data privacy issues. Statements that we hear in the news talk about massive data leakage from “Open S3 Bucket.”  What is a “Open S3 Bucket” you might ask.  An open S3 Bucket is simply a storage location that has not been locked down to deny public or unauthenticated users to access it. Many times, the permissions on the bucket are set to allow the public to read its contents. Kind of like an open file folder share for years past.  The good news is that back then most of the times these open file folders were on a corporate LAN where access was inertly limited.  S3 Buckets are often found on the Internet, so an Open S3 Bucket is inertly opened to the world.

How might you find these “Open S3 Buckets” on the Internet?  That is simple also.  There are a few ways the location of buckets becomes known.  First, there are search engines that are starting to become popular that discover S3 buckets and then index their contents and make them searchable.  A popular search engine site is http(s)://buckets.grayhatwarfare.com. They have a free search available and users can upgrade their account to a paid version to unlock advanced features.

Another popular way for someone to target a company directly looking for Open S3 Buckets is clone their website which means to crawl the company’s website and copy every page to a hackers local disk.  After the hacker has the site downloaded they can start looking though the code on the site for links to documents and other resources that are hosted on S3 servers.  An example of this would be a link to s3.cyberia.cb/Marketing.docx.  A hacker would simply browse to that locations root and see if they saw other files.  A more advanced technique would be to start a “Brute Force” attack on the S3 buckets looking for directories that are exposed.  A simple example of a “Brute Force” attack is when you go to the site with a forward slash and a name.  At Brute Force may try thousands or more directories. This may look like s3.cyberia.cb/doc, s3.cberia.cb/config, etc.

Now that we know what S3 is and a few tools and techniques that hackers use to find open S3 Buckets how do we ensure we are not in the headlines?

Follow these simple steps to help lower your company’s victim potential.  As you read these you will quickly see that what is old is new again.

1. S3 has two parts an Access Key and Secret Key combo.  Make sure that you issue the key combos with the least amount of privileges necessary to perform the S3 task at hand.
    
2. Use extra caution and fully test and understand when using scripts to make directories and change resource permissions.  Using poorly written scripts can inadvertently expose sensitive buckets and resources by moving those resources to open buckets or changing opening up permissions on a bucket.
    
3. Use the bucket only for what it was created for.  If it is an open bucket that is supposed to be for publicly accessible documents, make sure it is never used for some other task or role. Likewise, if the bucket was locked down but now you want to open it to the world it is best to move the content to a newly created bucket.  This will keep someone from not realizing the bucket is now public.
    
4. Use caution when uploading web or any other type of code to data repositories that interact with S3 buckets.  If someone were to see what your companies naming schema is they could modify their Brute Force scripts to target your company closer.  Example if the code says to take you company domain and add /s3Bucket_(directory) an attacker can append that to their script to look for buckets.  An example of this would be /s3Bucket_userdata.
    
5. Last, remember you can always encrypt before sending data to S3 just how you would any other file.  If you use data encryption and password protection of files then you have added an extra line of security in the event that the files become public accessible.

Past lessons learned with regards to data and privacy protection are still applicable today.  By slowing down and taking a methodical approach you can help ensure that you nor your company are in the headlines for leaking data via S3.