Customer service records from 14 million Verizon customers were found unsecured on a misconfigured Amazon S3 server, according to a report in ZDNet Wednesday. Chris Vickery, a security researcher at UpGuard, found the unprotected cache of data in June, according to a post on his company’s blog. Many of the customer records found included customers’ PIN numbers. These PINs allow Verizon customer service to verify a caller as a valid account holder.
Amazon Web Services (AWS) is the go to service for storing data in the cloud, particularly by enterprise companies. In the Verizon case, the data had been shared with an Israel-based company called Nice Systems, which provides analysis services for contacts with a company’s customers. Misconfigured AWS buckets (as a company’s stache of data is called) have become an all too common source of released customer data.
Even if an AWS bucket doesn’t store personal information inside it, using the wrong settings could allow a smart attacker to get their hands on personal information anyway.
Stockholm-based Detectify published a blog post today about common misconfigurations of AWS S3 buckets.
“Setting up access control of AWS S3 consists of multiple levels each with its own unique risk of misconfiguration,” Detectify’s Frans Rosén wrote in the post. “By identifying a number of different misconfigurations we discovered that we could suddenly control, monitor and break high end websites due to weak configurations.”
In other words, outsiders could make good websites do bad.
During its investigations, Detectify was able to find vulnerable buckets serving content to various high profile websites, including those used for gaming, password management, health tracking and more. Detectify declined to identify the companies involved, but all were notified prior to publication.
Why is this so bad?
Here’s one case: a major cybersecurity issue we’ve all discussed in the last year is phishing, sending emails with malicious links in order to install malware or harvest passwords and other sensitive data from users. When John Podesta got phished, he was tricked because the attacker made a website that very convincingly looked like it was Google.
The URL was not Google’s, though.
Savvy internet users know to glance at the URL quickly and make sure it’s right. For example, is it “spotify.com” or “spottify.com”?
So let’s say that Spotify had a misconfigured AWS bucket (we have no reason to believe that it does) that allowed an attacker to upload a file. They could write a webpage that sent data off site or copied it to a text file on the same server that they could actually read. By uploading such a page onto a server that Spotify reads from, it would have the correct URL, giving the attacker’s trick far more credibility.
With certain misconfigurations, an attacker might even simply load a script onto a site’s actual sign-in page that copied any data users entered as they signed in, Rosén explained in an email to the Observer.
SEE ALSO: The great Google Chrome cookie harvest.
This problem is not new
Previously, Rhino Labs scanned the top 10,000 Alexa sites in the world and found 107 had misconfigured S3 servers that exposed at least some data to malicious hackers. Some of mistakes only let attackers see data that is probably already exposed on the web anyway, such as image files. Others, though, go much further. They may have complete databases backed up and ready for download. Some even permitted anonymous or unconnected users to add files to a bucket.
In fact, as Rhino ran its tests this spring, it found evidence of prior, related testing in November. It repeatedly found a file called “textupload.txt.” It appeared to be a test by some other researcher (or potential attacker) checking to see if the server permitted them to add files.
Both Detectify and Rhino reported following responsible disclosure protocols before publishing.
Detectify details part of the approaches it used to determine whether or not an attacker could gain access to an S3 bucket, but did not detail all of its approaches. The first challenge is to figure out whether or not the site has any or all of its data hosted on an S3 bucket. This could be as simple as scanning a website’s code, but smarter IT teams will obfuscate the places where some or all of its data lives.
“We have identified multiple ways to make an S3 bucket actually reveal itself independent of proxies in front of it. We have notified AWS about these methods and chosen not mention them above,” Rosén writes.
Next, an attacker needs to determine the name of the bucket. Many times it has the exact same name as the website. Failing that, Amazon has four different results it gives for bucketnames tested, including one—”NoSuchBucket”—that confirms a specific name doesn’t belong to anyone. This could help attackers with the process of elimination. “ListBucketResult” and “AccessDenied” confirms it’s real. “AllAccessDisabled” confirms it once existed, but it is no longer used.
Amazon has a lot of different levels at which permissions can be set, which gives developers a lot of flexibility, but it might almost be too easy to mess up. It appears that many users are confused about the different permissions.
For example, Detectify points out that permissions can be set to authenticated users. Authenticated users means anyone who has sucessfully logged into AWS. It doesn’t necessarily mean that that user has any relationship to the company that owns the bucket.
Further, buckets can permit users access to not only upload or download files, but also to change files. This is a dangerous permission that should only be set to specific users. Detectify details a number of steps that companies can take to insure that their permissions are not too liberal.
“Amazon does explain these issues, and they are trying to make it harder nowadays in their new S3-console to accidentally give it too wide access. However, in a lot of cases, companies are using APIs or software to create buckets and objects, which is one reason this happens,” Rosén wrote the Observer in an email. Additionally, he explained that some commonly used third party software makes misconfigurations a bit too easy.
Amazon did not respond to a request for comment for this story. An AWS clients’ failure to correctly configure permissions to their buckets is not Amazon’s mistake, but Detectify believes the company could take more steps in the public interest.
“I would recommend that they at least notify companies when they have bucket settings set giving anyone access to the objects or to modify the contents in the bucket,” Rosén emailed. “That option is most likely 95 percent of the cases not setup on purpose.”
The fourth largest company in the world probably has more bandwidth it could direct at persuading its customers to straighten up, for everyone’s own good.
