Magecart, skimming credit card information online since 2015
September 20, 2018 10:40 AM   Subscribe

Since March 2016, hundreds of thousands, if not more, credit cards and other details have been stolen during payment from dozens of online shops worldwide (ClearSky Cyber Security), due to JavaScript code injections that RiskIQ dubbed Magecart. In June 2018, Ticketmaster UK's credit card processing partner, Inbenta, was compromised and Magecart code injected (Security Week). But this was just a small part of a larger effort. As of July 2018, at least 800 e-commerce sites are said to be affected, after they included code developed by third-party companies and later altered by hackers (ZDnet).

Earlier this month, British Airways was also breached, compromising approximately 380,000 customers' data (RiskIQ), personal and payment information but not passport information. NewEgg is the latest victim of a Magecart breach (Ars Technica), impacting desktop PC and mobile site sales going back to August 16, 2018, though the attack was shut down by NewEgg on September 18. Broadcasting giant ABS-CBN was also breached on or around August 16 (Gwillem on Gitlab), allowing personal information and credit cards to be intercepted while people shop for merchandise for one of the 90+ television shows.

There are steps that online businesses can take to protect themselves from these exploits (Astra). But unfortunately for consumers, some of the standard safety tips for online shopping (Fox News) don't apply, particularly relying on SSL (secure sockets layer) encryption, as depicted with the little "lock" icon, as the hackers purchased a certificate, and it's unclear whether app-based mobile device purchases were safe, as the code impacted both desktop and mobile website, and at least in the case of British Airways, a part of the British Airways Android app built off of the same code as the compromised portion of the airline's website (Wired), meaning app-based transactions were also skimmed.

The best defense for customers is one that is a best practice for many reasons, beyond avoiding malicious use of your bank information: check your accounts frequently (USA Today). And if/where possible, Apple/Samsung/Google Pay (CNet comparison of all three, July 27, 2018) to utilize tokenization (Wikipedia) for your payments, ensuring no personal account information is used in purchases (discussed to some degree previously).

If this has you thinking about real-world credit card information theft, PC Mag has an article from February 15, 2018 about How to Spot and Avoid Credit Card Skimmers, and The Points Guy has 5 Ways to Protect Yourself from Credit Card Skimmers, which includes the suggestion to search for bluetooth devices, and a link to Sparkfun's teardown of gas pump skimmers, as well as a link to the (Android-only) Skimmer Scanner app, seen on the Blue previously.

Per a tweet by RiskIQ researcher Yonathan Klijnsma, the company is working on a report on the three or possibly four Magecart groups, which will be available in about a month.
posted by filthy light thief (17 comments total) 22 users marked this as a favorite
 
Once again, the core problem is that liability for stolen credit cards rests on the user, so there is no reason for the card issuers to really improve anything. Make issuers liable for fraudulent purchases, and things would change very quickly.
posted by NoxAeternum at 10:51 AM on September 20, 2018 [5 favorites]


man i hadn't heard about this and i sure am glad (?) i bought something on NewEgg yesterday and not...two days ago.
posted by dismas at 10:54 AM on September 20, 2018


At this point my approach is to throw up my hands and use my Amex for everything because I know from experience they are good about dealing with stolen card numbers. I anticipate having to cancel a card at least yearly going forward. I even have a list of all the recurring payees when I need to change the number.

In summation, fuck everything.
posted by selfnoise at 10:55 AM on September 20, 2018 [3 favorites]


For those sites which support it, PayPal payment also employs “tokenization” of the credit card info (link). In the BA breach, BA specifically reported that credit card information from Apple Pay and PayPal was not compromised (link), for what it’s worth.

I’ve tried to find a list of the 800 companies affected but so far no luck. Anyone find a source for this?
posted by sudogeek at 10:56 AM on September 20, 2018


Once again, the core problem is that liability for stolen credit cards rests on the user,

Huh, really? Never had this happen myself, but I've had friends and family get their cards stolen and none of them had to pay. The credit card companies asked when the cards were stolen, then removed all the charges after that point, without any question. Did something change or did my friends have nice credit card companies?
posted by malphigian at 10:57 AM on September 20, 2018 [16 favorites]


man i hadn't heard about this and i sure am glad (?) i bought something on NewEgg yesterday and not...two days ago.

Ditto - I was browsing NewEgg a week back and musing on some purchases. Seeing this news from Ars Technica was a shock, doubly so because I had never heard of Magecart, and I consider myself relatively aware of broad trends online. Clearly, that is not the case ;)
posted by filthy light thief at 10:59 AM on September 20, 2018


Huh, really? Never had this happen myself, but I've had friends and family get their cards stolen and none of them had to pay.

Debit versus credit - the liability and risk is on the account holder for debit withdrawals until the fraud team retroactively identifies the fraudulent purchases and returns the losses, but fraudulent activity on a credit account usually doesn't even hit that month's billing cycle. So if you're buying with a card that is tied to an account that you use to pay your bills, you can get kinda fucked.

I always use PayPal as the payment processor. I expect I'll get hit with something or other eventually.
posted by Kyol at 11:01 AM on September 20, 2018 [1 favorite]


liability for stolen credit cards rests on the user

That's not true. Credit card liability tops out at $50, and in practice is typically $0 because any reputable credit card company will refund it. Debit cards are more complicated but have significant liability limits for the consumer. (Even so I never use a debit card for just this reason.)

It is true that the credit card companies have decided that they'd rather just eat the cost of fraud rather than develop more secure payment systems. Often the merchants bear the real cost of it.
posted by Nelson at 11:04 AM on September 20, 2018 [15 favorites]


On a technical level, the root problem here is software being built that thinks it's OK to dynamically load 3rd party libraries at runtime from centralized sources. It's a significantly better practice to pin your dependency versions at known good / vetted versions, and use some sort of internal cache in your build system to include them (e.g. in the nodejs world, a local npm cache via Artifactory or similar). Problem is, this is also mildly inconvenient, so few people really do it.

To be clear, I'm not saying this is a silver bullet, but it reduces the attack surface considerably. It means an attack on the central repository will only affect you if you take a new version from the repository that has been compromised, and you can choose to take new versions only on a scheduled basis with enough vetting to ensure there isn't anything malicious.

But like I said: inconvenient, so people don't want to do it.
posted by tocts at 11:04 AM on September 20, 2018 [13 favorites]


This Magecart story is fascinating. I haven't seen any good reporting on how the sites got compromised in the first place, how Magecart ended up on the site. I don't think it's entirely the fault of third party distributions; my impression is NewEgg's own copy of the Javascript were compromised. Whatever the case, whoever is doing these installations sure looks like a professional skimming all the money they can.

The scary thing with NewEgg is it took over two weeks to recognize the website had been hacked. Same with British Airways: over two weeks and no one noticed. These aren't crappy little poorly run web shops, both companies have serious ops and engineering teams. It's troubling how vulnerable they are.
posted by Nelson at 11:07 AM on September 20, 2018 [2 favorites]


These aren't crappy little poorly run web shops, both companies have serious ops and engineering teams. It's troubling how vulnerable they are.

I'm pretty certain at this point that if people fully understood how much of everything digital is held together by duct-tape and twine and secured with good intentions, we'd just shut everything off and walk into the ocean.
posted by CrystalDave at 11:12 AM on September 20, 2018 [34 favorites]


Nelson: These aren't crappy little poorly run web shops, both companies have serious ops and engineering teams. It's troubling how vulnerable they are.

It looks like the entry points are 3rd party payment processing companies, which is even more frightening. And one of these 3rd party companies, Clarity Connect, which provides a CMS for company owners to create an online presence with a website or web store, sounds like they were really owned, and/or/ the Magecart hackers are really cocky:
The Magecart actors have even left a message in the compromised code: 'If you will delete my code one more time I will encrypt all your sites: you very bad admins.' It seems, suggest the researchers, "the Magecart actors have broad access that they aren't afraid to use if the administrator removes their skimmer again. Clarity Connect's customers are affected by this injected skimmer code."
So the vulnerabilities are not "simple" code injections, if such things are ever really simple.
posted by filthy light thief at 11:26 AM on September 20, 2018 [2 favorites]


I'd been avoiding ApplePay because Apple already owns enough of my life, but perhaps using a tokenization service is yet another necessary evil for surviving another day in this screwed up digital life we've built.
posted by coffee and minarets at 11:26 AM on September 20, 2018 [3 favorites]


I know a lot of people don't like PayPal, but so far they haven't screwed me over and this seems to be a compelling reason to keep using them for online shopping outside of Amazon (not to derail into that can-of-worms topic...).
posted by Greg_Ace at 11:51 AM on September 20, 2018


but so far they haven't screwed me over
:O It's like seeing a unicorn!
posted by xedrik at 1:01 PM on September 20, 2018 [9 favorites]


In general, all PayPal horror stories I've heard have been from the perspective of the vendor, not the customer. In fact, it seems like they have a strong pro-customer slant to their processes. Is there some set of issues/bugs/biases/scandals that I've missed?
posted by mosst at 1:53 PM on September 20, 2018


Ecommerce is an area of software that gets the worst of every world.

* It moves really fast - shops appear and disappear and get sold and updated constantly.
* It's very complicated - lots of moving parts and transactions
* Every instance is slightly different - it's very rare for an ecom site to be 'okay, we just want an out of the box online shop', it's all about customisation and features
* Lots of actors - shop owners, agencies, marketing people, vendors, customers, fulfilment services. Money flowing everywhere.
* High incentive for attackers - lots of money right there.
* All the code's publicly facing on the internet and easy for attackers to beat on.
* Lots of valuable personal data in the databases
* Fragmented software base - every open source shop is pretty bad in its own way
* Big plugin culture - you'll often see a site be a pretty good piece of core software but have 25 shitty custom plugins installed and not updated.

tbh I'm surprised it's not far worse
posted by xiw at 1:58 PM on September 20, 2018 [7 favorites]


« Older Farewell, Racked   |   deconstructing American Evangelical Christianity Newer »


This thread has been archived and is closed to new comments