Biggest AWS Security Breaches of 2017

Early on, one of the most common reasons cited for not taking advantage of public cloud computing was security concerns. In general, that is no longer true. Today, a properly managed cloud environment is just as secure as any other type of well-maintained environment.

Yet no security operation is perfect. Even the best-managed cloud environment is at risk of security failures—particularly if security is undermined at the tenant level by cloud tenants who fail to properly secure the cloud resources that they are using.

In this article, I take a look at subscribers to Amazon Web Services (AWS) who suffered security breaches in 2017 as a result of improper configurations. The goal is not to embarrass these organizations (the mistakes they made could easily have been made by anyone), but rather to highlight easy-to-make errors that can have very big security repercussions.

Accenture

Fig. 1. The Manage Public Permissions setting should be set to Do Not Grant Public Read Access to This Bucket.

Accenture, a corporate consulting and management firm, accidentally configured four AWS S3 buckets to be accessible to the public. As such, anyone who could figure out one of the bucket’s URLs would have been able to download the bucket’s contents.

Although it does not appear that the data was accessed by anyone with malicious intent, this particular incident is concerning because of the nature of the data that was left unprotected. The S3 buckets collectively contained hundreds of gigabytes of data, including thousands of passwords, many of which were stored in plain text. The buckets also contained Accenture’s private signing keys.

AWS subscribers can avoid similar problems by taking the time to review bucket permissions when creating new buckets. When new buckets are created using the GUI, the Set Permissions screen contains a Manage Public Permissions setting, which you can see below. In most cases, this setting should be set to Do Not Grant Public Read Access to This Bucket.

For existing S3 buckets, AWS admins can open the S3 GUI interface, click on a bucket, and then select the Permissions tab from the resulting screen. This tab, which is shown below, allows you to review the bucket’s access control list, and to make permissions changes if necessary.

Time Warner Cable

A misconfiguration caused about four million Time Warner Cable customers to have their personal information exposed to the Internet. In this case, however, it does not seem as though the records were actually accessed by anyone who had malicious intent.

The incident was discovered by security researchers who were investigating an unrelated breach of World Wrestling Entertainment. During the investigation, researchers found that two Amazon S3 buckets, put into place by an outside contractor, had been configured to allow public access. These AWS S3 buckets possessed SQL databases containing things like customer billing addresses and phone numbers, although it does not seem that any credit card numbers were exposed.

As was the case with Accenture, this particular issue could have been avoided by reviewing the permissions that had been applied to the S3 buckets. Because Time Warner Cable had been using the buckets in question to store an SQL database, it would have been possible to further enhance security by setting database permissions within the SQL server. The exact method for doing so varies widely, depending on which type of SQL server was being used. In the case of a Microsoft SQL Server, for example, permissions can be applied through the SQL Server Management Studio.

Uber

One security breach receiving extra attention this year was that of Uber. The reason why the Uber incident became so infamous was not so much because of the nature of the hack—It was Uber’s handling of the incident. Rather than notifying the 57 million customers and drivers whose information was compromised, Uber bribed the hackers with a $100,000 payment to keep the incident quiet.

The Uber breach occurred when two hackers gained access to Uber’s private GetHub account. Upon gaining access to Uber’s GetHub data, the hackers were able to extract the company’s AWS credentials.

In the case of the Uber incident, the problem was not related to any sort of AWS configuration issue, but instead was related to a leaked password. The most obvious way to prevent the problem would have been for Uber to use stronger protection for its GetHub account, and avoid storing its AWS passwords within GetHub.

Another way of preventing this type of security breach would have been for Uber to utilize multi-factor authentication for AWS. Amazon provides a variety of multi-factor authentication options.