Researchers have discovered another big database containing millions of European customer records left unsecured on Amazon Web Services (AWS) for anyone to find using a search engine.
A total of eight million records were involved, collected via marketplace and payment system APIs belonging to companies including Amazon, eBay, Shopify, PayPal, and Stripe.
Discovered by Comparitech’s noted breach hunter Bob Diachenko, the AWS instance containing the MongoDB database became visible on 3 February, where it remained indexable by search engines for five days.
Data in the records included names, shipping addresses, email addresses, phone numbers, items purchased, payments, order IDs, links to Stripe and Shopify invoices, and partially redacted credit cards.
Also included were thousands of Amazon Marketplace Web Services (MWS) queries, an MWS authentication token, and an AWS access key ID.
Because a single customer might generate multiple records, Comparitech wasn’t able to estimate how many customers might be affected.
About half of the customers whose records were leaked are from the UK; as far as we can tell, most if not all of the rest are from elsewhere in Europe.
How did this happen?
According to Comparitech, the unnamed company involved was a third party conducting cross-border value-added tax (VAT) analysis.
That is, a company none of the affected customers would have heard of or have any relationship with:
This exposure exemplifies how, when handing over personal and payment details to a company online, that info often passes through the hands of various third parties contracted to process, organize, and analyze it. Rarely are such tasks handled solely in house.
Amazon queries could be used to query the MWS API, Comparitech said, potentially allowing an attacker to request records from sales databases. For that reason, it recommended that the companies involved should immediately change their passwords and keys.
Amazon began investigating the breach on the day it was disclosed to them with the third-party company involved shutting down the database on 8 February.
While there is no evidence anyone accessed the data during the days it was left unsecured it is impossible to be sure of that.
It’s simply the latest example of how easy it is to leave sensitive data sitting in an unsecured state on cloud storage platforms.
Previous examples discovered by Comparitech and Diachenko include:
- A total of 250 million Microsoft customer support records dating back to 2005 left exposed on Elasticsearch.
- A database containing 267 million Facebook user IDs, phone numbers and names left exposed on Elasticsearch.
- An email database of 5 million Adobe Creative Cloud customers left exposed in an Elasticsearch server (October 2019).
- The personal details of 57 million Americans left on a marketing database on Elasticsearch.
The number of these breaches seems to be growing in scope and number in the last year. The current defence against them right now is simply that researchers publicise them before the criminals do. That needs to change before real damage is done.
LEARN MORE – WATCH NOW ON OUR YOUTUBE CHANNEL
(Watch directly on YouTube if the video won’t play here.)
Latest Naked Security podcast
LISTEN NOW
Click-and-drag on the soundwaves below to skip to any point in the podcast. You can also listen directly on Soundcloud.
John Hawkins
What hope is there for the rest of us if these huge companies can’t even manage to keep themselves secure, given, presumably, their vast security departments?
John E Dunn
Worse, even companies that make strenuous efforts to secure data can’t be sure their supply chains and partners will be as careful.
Bryan
Hello,
You have reached the former security department. We were all let go to create more marketing budget. You may leave a message, but no one will listen to it. Thank you for calling–goodbye.
Paul Ducklin
As bad as this incident might be, it’s not quite that bad. The many big retailers and merchants involved weren’t directly broken into, so the damage is limited to what was shared with the tax company, which is a small and known subset of the data held by the merchants. Also, it seems that the company concerned was contacted, did listen, and did take remedial action.
Bryan
You’re right of course. Was mostly having fun with @JohnHawkins’s comment.
I won’t even claim to have never made an oversight which (under exposure on the order of millions) might yield the same egregious results–fairly certain we all have at some point.
Still, sarcasm is fun–and addictive–so I won’t promise to stop either.
:,)
Karl
This was a big deal. Today on April 2nd an order was placed on my Wayfair account for $900 which included a top of the line Dyson vacuum. I called them and they said they were not breached. I went to my google account and checked the security on my passwords and it alerted me that my amazon account had been recently breached. They clearly got my Amex card and email from this amazon breach. I was spammed 1800 emails in a two hour period in an attempt to clearly cover up that some automated system was purchasing things. it was happening so fast it was clearly robot and not some single hacker so now this makes sense. This is why I prefer guest checkout and will never leave my credit card on file with amazon again.
Paul Ducklin
You say that the crooks “clearly got [your] Amex card from this Amazon breach”, but in my opinion the evidence here suggests that this is not the breach that led to your Amex compromise this time. It’s tempting to look for a *possible* cause and to accept it as the *actual* cause, but do remember that if you are wrong, you will still be at risk – but you will think you are not and have “closed the case”.
The reason I say this is that the data in this breach only had the last 4 digits of your card (which you need to consider “non-private” because those digits are regularly used in emails, on receipts and so forth), and did not include the CVV (short security code on the card).
If you’re determined to figure out where the crooks got your full card+expiry+CVV to rip off your account, I’d urge you to consider additional possibilities – not to excuse this particular breach, but it doesn’t sound like the explanation in this case. And if it is not, then the real explanation (the one that would give you the best advice for avoiding this in future) is still out there.