Cloud

7/17/2017
10:30 AM
Rob Enns
Rob Enns
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

AWS S3 Breaches: What to Do & Why

Although basic operations in Amazon's Simple Storage Services are (as the name implies) - simple - things can get complicated with access control and permissions.

Since its launch in 2006, Amazon’s Simple Storage Service — S3 — has spread like wildfire. Used worldwide for storing everything from personal photo libraries to government personnel data, S3 underlies numerous other cloud services offered by AWS, and integrates with many third-party hardware and software products. If S3 comes up in security news more often than other cloud service provider offerings, that's merely a testament to its success.

At the root of S3's appeal is its simplicity. By abstracting data access to reading and writing "objects" (an object is a simplified version of what are normally called files), S3 makes it easy to drop software and services data into named "buckets" in the cloud. S3 has spread so far and so fast that enterprises may not even realize their data is stored in the cloud, when in fact their backup system or file-sharing service uses S3 as a building block. 

While basic operations remain simple, things get complicated with S3 access control and permissions. While every S3 object defaults to private, once developers start configuring the baroque access controls of AWS, mistakes are easy to make.

Within the last month, two high-profile data breaches became public. An open S3 bucket belonging to a defense contractor exposed 60,000 files, including sensitive US government data. Following that incident, the records for 198 million US voters were exposed when a bucket belonging to a data analytics firm was left unprotected. Most recently, 6 million Verizon customer account PINs were leaked, along with names and phone numbers.

These incidents are not unique. In fact, S3 breaches are common enough that an industry has sprung up around discovering and exploiting them. Actors can regularly scan S3 for accessible objects using publicly available tools and harvest AWS credentials along with other sensitive data.

Black Hat USA returns to the fabulous Mandalay Bay in Las Vegas, Nevada, July 22-27, 2017. Click for information on the conference schedule and to register.

 

With S3 data loss so commonplace, what can you do to protect your data?

First, do not assume that S3 bucket names are invisible or un-guessable. Every S3 bucket requires a globally unique name, and S3 users create their own bucket names. However, unscrupulous S3 hackers will try to guess these names to retrieve the objects within buckets. As an example, the bucket "music-rob-enns-us-west-2" is globally unique, but even a moderately creative hacker would be able to guess it. Numerous breaches have been tied to guessed bucket names, and it's important to remember that security through obscurity has never been effective. The security of S3 data must not be tied to secret bucket names; instead, use access control and encryption to protect data.

Second, make sure enterprise data management policies extend to S3 and other cloud services, and review the access control implementation for each cloud provider. Cloud access control systems are powerful and complex, and a common source of data breaches includes unintentionally weakened or disabled access controls during application development, deployment, and upgrade. If safeguarding precious data depends on developers following best practices, you are at risk. Consider introducing a separation of duties between application developers and data security.

Third, always encrypt data. S3 provides numerous encryption methods. Configured and used properly, encryption protects data effectively — once data is encrypted, it cannot be read without the corresponding key. At enterprise scale, effective encryption also raises requirements for key management that need to be addressed.

Finally, maintain visibility into changes in the encryption and access control configuration on cloud deployments. Log all configuration changes using AWS CloudTrail, and configure your SIEM to send an alert anytime an S3 bucket is made public or if encryption settings are changed across accounts.

AWS S3 is a powerful and ubiquitous cloud service. Developers ranging from Silicon Valley startups to Fortune 500 companies use S3 as a key building block. As S3 usage scales across applications and teams, access control will become increasingly complex. Following sound policies early in S3 deployment will reduce the chance of a catastrophic data breach down the road.

Related Content:

 

Rob Enns joined Bracket Computing from VMware, where he was vice president of engineering in their networking and security business unit. Before joining VMware, Rob was vice president of engineering at Nicira, which was acquired by VMware in 2012. Previously he spent 11 years ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
White House Cybersecurity Strategy at a Crossroads
Kelly Jackson Higgins, Executive Editor at Dark Reading,  7/17/2018
The Fundamental Flaw in Security Awareness Programs
Ira Winkler, CISSP, President, Secure Mentem,  7/19/2018
Number of Retailers Impacted by Breaches Doubles
Ericka Chickowski, Contributing Writer, Dark Reading,  7/19/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-14512
PUBLISHED: 2018-07-23
An XSS vulnerability was discovered in WUZHI CMS 4.1.0. There is persistent XSS that allows remote attackers to inject arbitrary web script or HTML via the form[nickname] parameter to the index.php?m=core&f=set&v=sendmail URI. When the administrator accesses the "system settings - mail ...
CVE-2018-14513
PUBLISHED: 2018-07-23
An XSS vulnerability was discovered in WUZHI CMS 4.1.0. There is persistent XSS that allows remote attackers to inject arbitrary web script or HTML via the form[content] parameter to the index.php?m=feedback&f=index&v=contact URI.
CVE-2018-14514
PUBLISHED: 2018-07-23
An SSRF vulnerability was discovered in idreamsoft iCMS V7.0.9 that allows attackers to read sensitive files, access an intranet, or possibly have unspecified other impact.
CVE-2018-14515
PUBLISHED: 2018-07-23
A SQL injection was discovered in WUZHI CMS 4.1.0 that allows remote attackers to inject a malicious SQL statement via the index.php?m=promote&f=index&v=search keywords parameter.
CVE-2018-14517
PUBLISHED: 2018-07-23
SeaCMS 6.61 has two XSS issues in the admin_config.php file via certain form fields.