Back to blog results

January 24, 2018By Brien Posey

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.

Operational Visibility From AWS

Machine data holds hidden secrets that deliver true insights about the operational health of your AWS infrastructure. Learn more about operational visibility from AWS today!

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.

Complete visibility for DevSecOps

Reduce downtime and move from reactive to proactive monitoring.

Brien Posey

Brien Posey is a Fixate IO contributor, and a 15-time Microsoft MVP with over two decades of IT experience. Prior to going freelance, Brien was CIO for a national chain of hospitals and healthcare facilities. He also served as Lead Network Engineer for the United States Department of Defense at Fort Knox. Brien has also worked as a network administrator for some of the largest insurance companies in America. In addition to his continued work in IT, Brien has spent the last three years training as a Commercial Scientist-Astronaut Candidate for a mission to study polar mesospheric clouds from space.

More posts by Brien Posey.

People who read this also enjoyed