At least 2.2 million Dow Jones & Co. clients had their information exposed because an AWS configuration error on their cloud-based file repository with Amazon Web Services. The big-name financial publishing firm unwittingly allowed unauthorized people access to customers’ personal and financial details because of a misconfigured S3 bucket.
According to Dow Jones, 2.2 million customers were affected by the AWS configuration error. But UpGuard, the cybersecurity firm that caught the mistake, calculates that the number is actually almost 4 million.
This data affected millions of subscribers to Dow Jones publications, such as The Wall Street Journal and Barron’s. It included the names, address, account information, email addresses, and last four digits of credit card numbers of these subscribers. Although the full credit card information wasn’t exposed, this leak is nothing to scoff at.
According to UpGuard, even more, “1.6 million entries in a suite of databases known as Dow Jones Risk and Compliance, a set of subscription-only corporate intelligence programs used largely by financial institutions for compliance with anti-money laundering regulations” were exposed.
How did this AWS configuration error happen?
The exposed data repository was an AWS configuration error in the Simple Storage Service (S3) bucket. A common mistake, the bucket’s permission settings were set “to allow any AWS ‘Authenticated Users’ to download the data via the repository’s URL.”
The problem is that an Authenticated User doesn’t mean authorized user, but “any user that has an Amazon AWS account.” As there are over a million users and registering for this account is free, this clearly isn’t very secure.
This simple AWS configuration error led to the exposure of information of millions of different customers, which could have easily been exploited, for example, through a phishing scheme that used personal information to fool users.
Another large mistake is that Dow Jones apparently had a “sluggish” response, adverse to notifying affected customers about this breach of data. Because of this, customers were less likely to be more suspicious of phishing schemes or to act to protect their information. Dow Jones told The Hill it didn’t inform customers because “the information was not sensitive enough to require it.”
This Dow Jones exposure isn’t the first AWS leaking incident, “from the Republican National Committee, World Wrestling Entertainment, the Department of Defense, and Verizon.” With Verizon, anywhere between 6 million and 14 million customers were left defenseless on an unprotected server that belonged to the telecommunication firm’s partner.
World Wrestling Entertainment, instead, left the data of 3 million fans exposed. Each of these was found to be exposed an S3 bucket by Chris Vickery, director of cyber risk research at UpGuard.
Although the S3 buckets are set to private by default and users must manually change the permissions settings, it’s typical that the data will have to be shared with another user. However, according to UpGuard, “this kind of misconfiguration is far too common when making data shareable.”
This isn’t always the problem that leaves users’ data exposed, but many of the leaks are attributed to common errors when configuring access controls for the S3 bucks.
Right now, Amazon does provide many different security mechanisms to make sure that an S3 bucket doesn’t become public accidentally. This is the default setting and relatively easy to manage.
However, those who don’t know much about security, or AWS security specifically, might not see a problem with making this information publicly available in order to share the data with someone outside AWS. As we know, though, making the bucket public or available to all AWS account-holders is not secure.
“That’s what I assume happened in most or all of these situations — someone needed to share data,” explains Rich Mogull, analyst and CEO at Phoenix-based Securosis. “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.”
Detectify released a report elaborating on the fact that many network administrators don’t put in the proper time to understand how to safely and securely configure AWS’ Access Control Lists (ACL), with clearly harmful results.
According to their security adviser, Frans Rosén, Detectify was able to “suddenly control, monitor, and break high-end websites due to weak configurations of the bucket and object ACLs.”
If these buckets are misconfigured, there’s a very large potential problem related to naming. According to Rosén, if attackers identify the name of the S3 bucket, they can use it in combination with an AWS Command Line tool to communicate with Amazon’s API.
Then, the attacker has the possibility of gaining access to the S3’s list and read files, as well as writing and uploading files to the bucket or changing access writes. “All this can be done…without the S3 hosting company ever noticing.”
The reason this is possible is that, as you can expect, a misconfiguration of the S3’s Access Control Lists leads to too much access permission being granted. The Detectify researchers came to the same conclusion as previous researchers: too many access controls were set to “Authenticated User.” This is likely because, in Rosén’s opinion, “people accidentally confuse Authenticated with Authorized when seeing this access control option.”
So, once this misconfiguration takes place, the only thing that’s needed to gain access to the bucket is its name. Then, the attacker could query AWS and ask for the AWS command line interface.
While some S3 bucket names are easy to guess or brute-force, others can be more difficult to find. According to Detectify, there are a few different options to find the name and the company that they’re associated with.
One of these is “looking at the HTTP-response for a server-header that reads ‘AmazonS3,’” and according to Amazon, this is not a mistake. Instead, it demonstrates that the AWS server can leak data if not properly configured and that “it was not likely to mitigate against user errors.”
While it isn’t clear if some of the other leaks, like Verizon, came from this exact problem, Detectify researchers were able to find 40 different companies that had problems related to access control and misconfigurations of buckets.
Another Rhino Labs study tested 10,000 AWS S3 buckets used by Alexa top 10,000 sites and found a large 1.1 percent, or 107 buckets, were misconfigured. Being that these sites were popular rather than fringe blogs or other websites, this represents a large problem.
How to avoid this error
The solution this AWS configuration error is two-fold. First, administrators need to be better educated on access control for S3 buckets, making security a top priority. Second, Amazon could change the way permissions are managed, giving more options than just private and public permissions and making it simpler to add certain authorized users.
Amazon could, and should, offer more security options and simpler control for administrators. However, these leaks come into play because of user error and require the companies to take their security more seriously to protect the privacy of customers.
Photo credit: Shutterstock