Anterovium - Fotolia

Another AWS data leakage due to misconfiguration

Dow Jones becomes the latest organization to be affected by an AWS cloud data leakage due to misconfiguration and user error.

A security researcher found yet another unsecured Amazon Simple Storage Service bucket, leading to more AWS data leakage incidents due to user error.

The cloud data leakage of Dow Jones & Co.'s customer data marked the latest in a line of Amazon Web Services (AWS) data leakage incidents, from the Republican National Committee, World Wrestling Entertainment, the Department of Defense and Verizon -- the last two via third-party contractors. Cybersecurity firm UpGuard, which also found and notified the other organizations listed, reported the potential cloud data leakage to Dow Jones in early June.

Dow Jones confirmed the AWS data leak included customer names, email addresses and some partial credit card numbers, but said no full credit cards or account credentials were part of the cloud data leakage. Dow Jones claimed issue affected 2.2 million customers, but UpGuard estimated the number to be "closer to 4 million."

While Dow Jones said the exposure was due to an "internal error," UpGuard gave a more detailed account, stating that any user that had an AWS account would have been able to "download the data via the repository's URL" due to the way permissions settings were configured.

"The revelation of this cloud leak speaks to the sustained danger of process error as a cause of data insecurity, with improper security settings allowing the leakage of the sensitive information of millions of Dow Jones customers," Dan O'Sullivan, cyber resilience analyst at UpGuard, based in Mountain View, Calif., wrote in a blog post. "The data exposed in this cloud leak could be exploited by malicious actors employing a number of attack vectors already known to have been successful in the past."

As with previous AWS data leakage discoveries, Chris Vickery, director of cyber risk research at UpGuard, found the exposed Amazon Simple Storage Service (S3) buckets. Experts and AWS documents said S3 buckets are private by default and require users to actively change the permissions settings. They said this kind of misconfiguration is far too common when making data shareable.

"Amazon defaults to provide, and provides, multiple security mechanisms to prevent S3 buckets from being made public accidentally. Right now, it's very easy to manage within AWS. But if you want to share data with someone outside AWS and you aren't overly familiar with AWS security, you might be tempted to just make the bucket public," Rich Mogull, analyst and CEO at Phoenix-based Securosis, told SearchSecurity. "That's what I assume happened in most or all of these situations -- someone needed to share data. They were using AWS, but weren't familiar with it and didn't look up the documentation on how to handle this securely. They took the easy way out and made the bucket public."

AWS permissions control

Scott Petry, CEO and co-founder of secure web browsing vendor Authentic8, based in Mountain View, Calif., agreed that user error was the primary cause of the AWS data leakage, because "the free-form nature of bucket creation and naming conventions make it more challenging."

"The method for managing permissions in Amazon buckets is very powerful, but perhaps not as intuitive as it could be. When you create a bucket, it defaults to private permissions, available only to the bucket creator. The only other option at the bucket level is public where the data is available to all," Petry told SearchSecurity via email. "In order to selectively provide access, you need to define identity and access management (IAM) policies. In order to manage more fine-grained access, you can create an IAM user for the person you want to share with. Then, create an access permission for that user or users. If you want a process to access data stored in a bucket, you'd create that user and then allow authorized services to access that user account, which would have access to the data in the bucket."

While Mogull agreed user error was at fault for the AWS data leak, he said Amazon may need to consider risks surrounding less-knowledgeable users.

"While users are mostly responsible for disclosures, the mechanism for writing IAM and bucket policies could be simplified for less-technical users," Mogull said. "Right now, it is really easy to make a bucket open to everyone. And although AWS warns you, setting more restrictive policies for non-AWS user access -- like sharing with a peer organization -- could be simplified."

Brian Vecci, technical evangelist at New York-based threat protection vendor Varonis, noted that "many platforms have permissions interfaces that are unintuitive and contribute to user error, but the onus is on the organization to account for that."

"There are also third-party products that scan access controls and help illuminate situations where permissions may be less than ideal or downright broken. Enterprises should make use of these tools -- especially if they're dealing with sensitive data," Vecci told SearchSecurity. "In the case of Dow Jones, they made matters worse by hosting their data at the easy-to-find subdomain 'dj-skynet.' Hackers and researchers can write scripts that programmatically try different strings. Much like brute-force password attacks, the simpler the bucket address, the simpler it is to guess."

Ben Johnson, CTO at cloud security provider Obsidian Security, based in Newport Beach, Calif., said both user error and Amazon shared blame for the series of AWS data leakage incidents.

"In the end, Amazon needs to do more. It goes back to the challenge of too many security controls makes it harder to install, configure, deploy and monitor your services and apps, and too little security controls leads to risk and vulnerability," Johnson told SearchSecurity. "Amazon needs to take a stronger look at the built-in security, but it will always be, first and foremost, the responsibility of Amazon's AWS customers to make sure their systems and data are appropriately protected."

'You may think that 'Any AWS Authenticated User' means your team, [but] it actually means any AWS authenticated user globally, regardless of if they are a different company, an individual, a bad guy, etc.,' said Ben Johnson, CTO at Obsidian Security.
'You may think that 'Any AWS Authenticated User' means your team, [but] it actually means any AWS authenticated user globally, regardless of if they are a different company, an individual, a bad guy, etc.,' said Ben Johnson, CTO at Obsidian Security.

Cloud data protection on AWS and other services

Mike Shultz, CEO of risk governance company Cybernance Corp., based in Bee Cave, Texas, said he would be surprised "if Amazon doesn't consider imposing greater restrictions and oversight on user data."

"The processes could include requiring more detailed descriptions of the data and more widespread review of the policies under which it's made available. The No. 1 action companies can take is to instill and demand effective policies, processes and behaviors of people. Over time, much of this review could be automated," Shultz told SearchSecurity. "AWS could and should develop tools and processes to help its clients make sure that they tighten up their applications and apply proper procedures. It remains in the best interests of all to be sure that data is safe from bad actors."

Mogull said he "would be shocked" if similar user errors and misconfiguration didn't exist on other cloud platforms like Microsoft Azure, Google Cloud and Dropbox.

"If the enterprise has a security team, they need to make sure people are trained at a technical level on cloud security. They also need to implement a cloud security program. I'm probably biased on these, since it's a big part of our business, but I think it's just common sense," Mogull said. "We see too many enterprises moving into cloud without a good technical cloud security program. There are multiple tools that can help reduce the risk of these kinds of exposures."

Vecci said it's "trivially easy for bad actors to get their hands on automated tools and scripts that scan for open Amazon S3 buckets or scrape the web for public Dropbox links and auto-aggregate any data they can get their hands on."

"And it's not just cloud platforms. You can go to Google search right now and type in: filetype:config inurl:web.config inurl:ftp and see tons of misconfigured FTP servers with exposed passwords," Vecci said. "Misconfigurations are nothing new, but are much more discoverable on publicly facing servers that aren't behind a corporate firewall."

UpGuard's O'Sullivan told SearchSecurity, "Ultimately, it is the responsibility of any user of a cloud-based storage service to ensure that their permission settings and accessibility configurations are appropriate to whatever servers they are administering. However, cloud storage providers should take note of any such issues and do their best to ensure default settings and user interfaces are easily formatted for securing data. If settings are sufficiently confusing to cause many administrators to make similar mistakes, perhaps such services can do more to ensure data security."

Next Steps

Learn tips on accelerating AWS Lambda functions.

Find out lessons that can be learned from the Dropbox password breach.

Get info on gaining control over multiple AWS accounts with IAM.

Dig Deeper on Data security and privacy