Bailing S3 Buckets

Headlines are breaking out all over the last few weeks about high-profile data breaches caused by company databases and other information being stored in public Amazon Web Services (AWS) Simple Storage Service (S3) buckets. See here and here for two examples. The question I get most often around these breach notices is, “Why does anyone leave these buckets as public, and isn’t that AWS’s fault?” The answer is straight-forward, but comes as a bit of a shock to many – even many who work with AWS every day.

A quick refresher on S3

For those not familiar with S3 or what it is and what it does, basically S3 is an online file system of a very defined type. S3 is a cloud-based Object Storage platform. Object Storage is designed to hold un-structured collections of data; which typically are written once and read often, are overwritten in their entirety when changed, and are not time-dependent. The last one simply means that having multiple copies in multiple locations doesn’t require that they be synchronized in real-time, but rather that they can be “eventually consistent” and it won’t break whatever you’re doing with that data.

S3 organizes these objects into “buckets” – which would be the loose equivalent of a file system folder on more common operating system file systems like NTFS or EXT. Buckets contain sub-buckets and objects alike, and each level of the bucket hierarchy has security permissions associated with it that determine who can see the bucket, who can see the contents of the bucket, who can write to the bucket, and who can write to the objects. These permissions are set by S3 administrators, and can be delegated to other S3 users from the admin’s organization or other organizations/people that have authorized AWS credentials and API keys.

It’s not AWS’s fault

Let’s begin with the second half of the question. These breaches are not a failure of AWS’s security systems or of the S3 platform itself. You see, S3 buckets are *not* set to public by default. An administrator must purposely set both the bucket’s permissions to public, and also set the permissions of those objects to public – or use scripting and/or policy to make that happen. “Out of the box,” so to speak, newly created buckets can only be accessed by the owner of that bucket and those who have been granted at least read permissions on it by the owner. Since attempting to access the bucket would require those permissions and/or API keys associated with those permissions, default buckets are buttoned up and not visible to the world as a whole by default. The process to make a bucket and its objects public is also not single-step thing. You must normally designate each object as public, which is a relatively simple operation, but time consuming as it has to be done over and over. Luckily, AWS has a robust API and many different programming languages have libraries geared toward leveraging that API. This means that an administrator of a bucket can run a script that turns on the public attribute of everything within a bucket – but it still must be done as a deliberate and purposeful act.

So why make them public at all?

The first part of the question, and the most difficult to understand in many of these cases we’ve seen recently. S3 is designed to allow for the sharing of object data; either in the form of static content for websites and streaming services (think Netflix), or sharing of information between components of a cloud-based application (Box and other file sharing systems). In these instances, making the content of a bucket public (or at least visible to all users of the service) is a requirement – otherwise no one would be able to see anything or share anything. So leveraging a script to make anything that goes into a specific bucket public is not, in itself, an incorrect use of S3 and related technologies.

No, the issue here is that buckets are made public as a matter of convenience or by mistake when the data they contain should *not* be visible to the outside world. Since a non-public bucket would require explicit permissions for each and every user (be it direct end-user access or API access); there are some administrators who set buckets to public to make it easier to utilize the objects in the bucket across teams or business units. This is a huge problem, as “public” means exactly that – anyone can see and access that data no matter if they work for your organization or not.

There’s also the potential for mistakes to be made. Instead of making only certain objects in a bucket public, the administrator accidentally makes ALL objects public. They might also accidentally put non-public data in a public bucket that has a policy making objects within it visible as well. In both these cases the making of the objects public is a mistake, but the end result is the same – everyone can see the data in its entirety.

It’s important to also point out that the data from these breaches was uploaded to these public buckets in an unencrypted form. There’s lots of reasons for this, too; but encryption of data not designed for public consumption is a good design to implement – especially if you’re putting that data in the cloud. This way, even if the data is accidentally put in a public bucket, the bad actors who steal it are less likely to be able to use/sell it. Encryption isn’t foolproof and should never be used as an alternative to making sure you’re not putting sensitive information into a public bucket, but it can be used as a good safety catch should accidents happen.

No matter if the buckets were made public due to operator error or for the sake of short-sighted convenience, the fact that the buckets and their objects were made public is the prime reason for the breaches that have happened. AWS S3 sets buckets as private by default, meaning that these companies had the opportunity to just do nothing and protect the data, but for whatever reason they took the active steps required to break down the walls of security. The lesson here is to be very careful with any sensitive data that you put in a public cloud. Double-check any changes you make to security settings, limit access only to necessary users and programs by credentials and API keys, and encrypt sensitive data before uploading. Object Stores are not traditional file systems, but they still contain data that bad actors will want to get their hands on.

What is Ransomware, and how do I stop it?

I get asked this question a lot by folks from all over the tech industry and from non-tech people just as often. Ransomeware is not new, but several extremely high profile attacks (like the “NotPetya” attack in Europe earlier in 2017) have put the topic back on the front burner of most peoples’ minds. With that in mind, let’s take al look at how to answer the question “What is ransomeware, and how do I stop it?”

What is it?

Ransomware is a form of malware – software that is not wanted on your computer and does something detrimental to your machine or the data it holds. This particular form of malware is nastier than most, however. While many virus, trojan, and other types of malware will delete data; ransomware encrypts data on your disk, meaning the data is still there, but totally unusable by you until you decrypt it. The creator of the ransomware is effectively holding your data hostage for money.

Tech Note – Encryption:

Encryption is the process of manipulating the binary data of your files using a cypher of some form to make the data useless to anyone who cannot decrypt it with the appropriate key. Much like converting orders into code before sending them in a war zone, you can encrypt data to make it useless to anyone who doesn’t have the key. This technology lets us safely bank online, save data in the cloud, etc. and is not natively a bad thing to have.

Ransomware arrives as an email attachment, a “drive-by” download from a website (where you visit a website and are prompted to download an executable file), and sometimes it acts as a true worm which infects any computers near one which has fallen victim to the malicious code. Once the infection takes hold on a computer, the malware will look for certain types of files (most often documents, spreadsheets, database files, text files, and photos); and will then encrypt these files in such a way that they are unusable by anyone until the malware author provides you with the decryption key.

The malware creator will offer to send you the key if you pay them the amount of money they are demanding – typically via the crypto-currency Bitcoin. They’ll also provide handy information on how to obtain Bitcoin, and the current exchange rates between the Bitcoin currency and your local currency. These malware authors are of course not going to provide just the helpful information. Along with that info comes a warning that if you don’t pay them by a certain date, your data will become permanently un-decryptable and lost forever. You seem to have only two choices: Pay the ransom or lose your data.

What do you do?

First, don’t panic. The malware creators of the world rely on people getting freaked out and doing anything they say in order to make the problem go away. Take a deep breath, step away from the computer for a moment, and then let’s deal with things.

1 – DO NOT PAY THE RANSOM! I can’t stress this enough, and there are very good reasons why you should never pay the ransom no matter how tempting it might be. First, there is at least a very good chance that the malware creators won’t ever give you the decryption key. It’s depressingly common for malware authors to use ransomware as a tool to steal money; and once the malware is known about, internet service providers and security researchers take steps to remove the ability for them to actually get paid or send you the key anyway. Secondly, negotiating with bad actors only results in more bad actors. If an author of ransomware gets a ton of money from their victims, then other authors will see the money available and write more ransomware to get in on the act.

2 – Check online to see if the ransomware has already been broken. Especially for the older variants of ransomware, there is a chance a security research group has figured out what the decryption key is. Check with your anti-virus/anti-malware provider (Symantec, Sophos, etc.) and legitimate tech sites to see if the key has already been found and made available; and to get instructions on how to decrypt your files with it.

3 – If a decryption key isn’t available, then you will need to restore your data from backups AFTER you clean the malware off your system. Check with your anti-virus/anti-malware vendor or your company’s IT department to find out how to get your system cleaned up; and with your backup provider or IT team to get the last known good version of your files back.

How do we stop it?

Stopping ransomware is not easy, as a successful attack can gain the malware authors quite a bit of money. New variants are popping up often, and some of them can spread themselves from machine to machine once the first few machines are infected via email attachments, etc. So how can you help stop ransomware and make it less profitable for the authors?

1 – DO NOT PAY THE RANSOM! Seriously, this cannot be said often enough. Each time someone pays the ransom, another author sees that they can make money by creating their own ransomware and spreading it around the internet. The first step in stopping the spread of this malware is to make sure there is nothing for the criminals who create it to gain.

2 – Keep your Operating System (OS), anti-virus, and anti-malware software up to date. No matter what OS you use (Windows, Mac, Linux, etc.) you are susceptible to malware of various kinds – including ransomware. Make sure you are regularly updating any desktops, laptops, tablets, and smartphones with OS updates and app updates as they are available. Even if you don’t feel comfortable having the OS keep itself updated automatically, be sure you are manually updating on a weekly basis at least. If you don’t have an anti-malware tool (such as those from Sophos, Computer Associates, etc.), then go download one and get it installed. Keep it updated – either via the tool’s own auto-update feature or just manually checking for updates at least daily. While anti-malware tools cannot catch every single variant of every malware package, they can catch a large number of them and keep you safer than not having one at all.

3 – Back up regularly. Use a tool that stores multiple versions of your files when they change – like Carbonite (disclosure: I’m a Carbonite subscriber and used to work for one of their family of products) or other such tools. This way, if you do get hit with ransomware, you can clean your system and restore last-known-good versions of files that were lost.

4 – Practice common sense internet safety. Don’t open attachments in email messages unless you know exactly what they are, who sent them, AND that they are legitimate. If you’re not sure of all three things, don’t open it – get confirmation from the sender first. Don’t click links in email. Instead, go to the website in question manually in your web browser and then navigate to the information you need. NEVER accept or open any files that automatically download when you load a website. If you didn’t click on it, don’t accept it. Along with that, always go to the vendor page to get new software. For example, if a site says you need a new version of Flash Player, then go to http://get.adobe.com/flashplayer and check for yourself instead of clicking on the link or button.

Protect yourself from ransomware as best as you can by following common-sense internet safety rules, and keeping your system backed up. Never pay the criminals who are holding your data for ransom. Finally, spread the word that ransomware can be stopped if we all work together and take the right precautions!