This type of credit card fraud is common and even very well-known brands have been compromised in this way.
Here are some examples:
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.
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:
- 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.
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 email@example.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.