RiskIQ's security blog analyzes web skimming and breaches, including Magecart attacks on British Airways, Ticketmaster, and Newegg.
HN links it for technical details of Magecart breaches. Commenters say it lacks some detail and note a CSP might have stopped the British Airways attack.
It is unclear from any reporting as to how this technically happened, which is a shame but hopefully that will be made public in the coming days. Some other outlets[0] have an interesting statement:
> The breach also included details about where each passenger had traveled and any comments made by customer service representatives. The amount of data accessed varied among passengers.
Based on those details, and the mention of 'no passwords were compromised', chances are this breach has come from an internal helpdesk type system, or possibly CRM. If however the statement around the passwords changes, that opens up a few other possibilities.
What this doesn't sound like, are the attacks we saw on British Airways[1] and Ticketmaster[2], where javascript was injected into the payment pages to vacuum up payment details from customers.
The statement around "The company has no evidence that any personal information has been misused" is always an interesting one, and is one of the many reasons I created my startup Breach Insider[3], so that data breaches like this could be detected much sooner (not 7 months later, as we have seen here), with minimal false positive alerts, and definitive evidence if any data has been misused. By using real email addresses that are unique to each company/business, you can be sure to find out if that data ever leaks & is abused for things like spam or phishing.
[0] https://www.theverge.com/2018/10/24/18019958/cathay-pacific-airline-data-breach
[1]…
Previous attacks by this Magecart group did go through third parties:
https://www.riskiq.com/blog/labs/magecart-ticketmaster-breach/
I think the underlying problems are the same either way. In all these attacks the customer loads a page with dozens of scripts from at least a dozen servers and he or she has to trust them all.
Speaking as someone who frequently has to reload the checkout page five or more times while authorising successive waves of third party servers in Request Policy and NoScript - there is no way to tell. Any one could be the source of an attack or the destination for malicious exfiltration.
Should I do a geoip lookup on every sever on a page when shopping on-line? Baways.com looks like a perfectly plausible server for yet another piece of cruft, or analytics, or some baroque chain of payment services providers.
Since the customer has no way of telling we are depending on the suppliers noticing that the website they are serving has changed. Otherwise it's up to the banks to find the common thread in each new wave of fraudulent payments, oops.
The current sorry state of security online can only be fixed by the suppliers. I think that doing things properly will necessarily involve more respect for customers and less adtech/ spyware so that payment processes are better separated from everything else on the web </rant>
i cant find any hits for "origin" or "CDN" on the original RiskIQ article: https://www.riskiq.com/blog/labs/magecart-british-airways-breach/
the RiskIQ article identifies the location of the script as "the main website"
additionally, I'm not sure how this would solve the problem. If BA went to all the effort of putting their frontend assets on a CDN, why wouldn't their HTML, with the hashes also be on the CDN? and if the hashes are not generated by the CDN, how does the server generate the hashes without being affected by changes on the CDN? regardless of outcome, if the process is automated, does a human being need to read a diff every time any file on any CDN changes? Can't an attacker then just wait until the hashes are automatically updated?
The article on the British Airways hack goes into a bit more detail, but still not enough to slake my curiosity.
https://www.riskiq.com/blog/labs/magecart-british-airways-breach/
It seems like we just don't have enough information to know how exactly the attackers got the JS onto the page. What it looks like, though, is that some machine serving static files for the website got compromised, and the attackers replaced an innocent file with one that had some custom javascript tacked onto the end, that skimmed the credit card numbers.
For what it's worth, PCI compliance doesn't really help you keep your webservers secure, or to keep people from breaking into your servers at all, it's more about the way you permanently store credit card numbers.
Except this article and that quote are wrong. If you look at the linked report on the British Airways hack, https://www.riskiq.com/blog/labs/magecart-british-airways-breach/, you'll see that the compromised script was hosted on www.britishairways.com. It wasn't a third party CDN hack, their own CMS was simply compromised.
I kept reading this article looking for an actual decent reason to not use a third party CDN, and I never found one. In fact, the right answer is really that you should always set up your CSP and subresource integrity rules to completely prevent these kinds of attacks, whether from an unintended script injection from your own domain or a 3rd party.
> We've just shifted from "quiet, persistent threat" to "hacker announces to the world that he's in". Changing javascript on a prod website is going to trigger alarms.
While I'd like that to be true, it really isn't. There have been loads of card skimming operations injected into production sites which weren't noticed for sometimes months.[0][1][2][3]
[0]: https://blog.malwarebytes.com/hacking-2/2020/03/criminals-hack-tupperware-website-with-credit-card-skimmer/
[1]: https://www.wired.com/story/british-airways-hack-details/
[2]: https://www.riskiq.com/blog/external-threat-management/magecart-ticketmaster-breach/
[3]: https://sansec.io/research/svg-malware