Magecart is a credit card skimming type of malware that steals the credit card data from your customers during checkout. Criminals will exploit vulnerabilities on web pages accepting credit card payments to inject Javascript. This script is made to be difficult to detect by security scanners, and will send a copy of the payment data to the criminals. You should protect your customers against Magecart. Modern web browsers can provide an important layer of security through content security policy (CSP) headers and subresource integrity (SRI).

How to use subresource integrity to avoid being compromised by a supply chain attack.

This type of credit card fraud is common and even very well-known brands have been compromised in this way.

Here are some examples:

Magecart infected e-commerce retailer Páramo for almost 8 months inspite of PCI security scans (The Register, 2020)

British airways fined £183 million over credit card skimming malware on their webpage (BBC, 2019)

Ticketmaster claiming they were not at fault for Magecart attack in 2018 (The Register, 2018)

Today we also heard about EasyJet being hacked in a “sophisticated cyber attack”, leading to theft of 2000 credit cards and access to personal data of 9 million customers. We don’t know if this was also a Magecart attack but this could certainly be the case.

Retailers must protect against magecart skimming attacks to safeguard the financial data of their customers.
Online shoppers do not notice Magecart malware stealing their credit card data during a checkout – it only becomes visible when the card is abused by the scammers.

How hackers get their Magecart code into the target web page

To steal the credit cards of customers of e-commerce sites, hackers need to get the scripts into the web sites. There are many ways they can do this:

  • Compromise the web server and change the source code, or change the source of third-party JavaScript being loaded
  • Compromise a third-party content delivery network and change the JavaScript files served from the CDN
  • Exploit cross-site scripting vulnerabilities on the payment page to inject their own scripts
  • Compromise an open source library such as a popular npm package to inject the malicious code

There are many others too, but let us consider how a website owner can try to protect the customers against attacks like the above.

Protecting customers against Magecart

Web servers can be compromised most easily by hijacking administrator accounts. The most common ways to do this is through phishing, or password based attacks. Protecting access to administration interfaces and code repositories with strong passwords and two-factor authentication can greatly reduce this risk.

Most websites today will use third-party sources for delivering media and static assets. Using content delivery networks (CDN’s) make sense as it lowers bandwidth requirements and make web pages faster. The downside is that you need to trust the security of the CDN supplier. To protect against someone altering the code on the CDN side, you can use “subresource integrity” or SRI. Then you add a hash of the script file to the script tag pulling it in. If someone changes the content of the file pulled the hash will no longer match, and the code delivered will not be executed in the browser. This is an effective defence against this type of supply chain attack.

Cross-site scripting vulnerabilities are still quite common. These occur when it is possible for an adversary to inject JavaScript that will be executed on the page. The vulnerability can occur directly on the webpage, or through a third-party library like jQuery or Bootstrap. An effective defence against cross-site scripting consists of training developers to actively sanitise and escape all user input, verifying that third-party components do not have known vulnerabilities, and applying a content security policy to control what code can run on the web page.

Malicious software packages can be very hard to defend against. Attackers have two common tactics to use popular open source repositories to inject malicious code in products; create a name that looks very similar to a real package, or compromise an actual package. Recent research has shown that less than 10% of npm.org developer accounts have two-factor authentication enabled. To help protect against malicious third-party packages, developers should try to reduce the number of dependencies, not use libraries that have few users and contributors. If the packages are used for frontend dependencies, using a CDN with subresource integrity may be a better solution.

Summary of anti-magecart practices

Many e-commerce sites are built on platforms like WordPress and Drupal with plugins. In such cases, the most important defence is to always apply updates as fast as possible for both the base technology and all plugins.

The same applies to third-party components in code; they should be kept up to date. The number of dependencies in modern projects is usually high, using a tool to keep track of dependencies and the vulnerabilities they can have is necessary. Good open source options include OWASP Dependency Check and Retire.js. Note that such systems will not be able of detecting compromised packages where the code has been altered by adversaries; this is in essence a zeroday in the supply chain.

Developers writing code, whether for backend or frontend, should get training in secure development practices covering threat modeling, writing security requirements, secure coding patterns and running security oriented tests.

Cybehave provides developer training – email us at info@cybehave.com if you want to set up a call to discuss or get more information about this.

Make sure to use content security policies (CSP) and subresource integrity (SRI) to make injection attacks much harder.

Finally, regularly test your payment pages from a client perspective; check if there are any unexpected network requests during registration and checkout.

Leave a Reply