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
'PowerSnitch' Hacks Androids via Power Banks
Kelly Jackson Higgins, Executive Editor at Dark Reading,  12/8/2018
How Well Is Your Organization Investing Its Cybersecurity Dollars?
Jack Jones, Chairman, FAIR Institute,  12/11/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
10 Best Practices That Could Reshape Your IT Security Department
This Dark Reading Tech Digest, explores ten best practices that could reshape IT security departments.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-1480
PUBLISHED: 2018-12-12
IBM BigFix Platform 9.2.0 through 9.2.14 and 9.5 through 9.5.9 does not set the 'HttpOnly' attribute on authorization tokens or session cookies. If a Cross-Site Scripting vulnerability also existed attackers may be able to get the cookie values via malicious JavaScript and then hijack the user sessi...
CVE-2018-1481
PUBLISHED: 2018-12-12
IBM BigFix Platform 9.2.0 through 9.2.14 and 9.5 through 9.5.9 stores sensitive information in URL parameters. This may lead to information disclosure if unauthorized parties have access to the URLs via server logs, referrer header or browser history. IBM X-Force ID: 140763.
CVE-2018-1484
PUBLISHED: 2018-12-12
IBM BigFix Platform 9.2.0 through 9.2.14 and 9.5 through 9.5.9 does not set the secure attribute on authorization tokens or session cookies. Attackers may be able to get the cookie values by sending a http:// link to a user or by planting this link in a site the user goes to. The cookie will be sent...
CVE-2018-1485
PUBLISHED: 2018-12-12
IBM BigFix Platform 9.2.0 through 9.2.14 and 9.5 through 9.5.9 does not renew a session variable after a successful authentication which could lead to session fixation/hijacking vulnerability. This could force a user to utilize a cookie that may be known to an attacker. IBM X-Force ID: 140970.
CVE-2018-1901
PUBLISHED: 2018-12-12
IBM WebSphere Application Server 8.5 and 9.0 could allow a remote attacker to temporarily gain elevated privileges on the system, caused by incorrect cached value being used. IBM X-Force ID: 152530.