What are Magecart and Online Skimming Attacks and How to Prevent Them?

Crisis events often attract the attention of cybercriminals, as they cause changes in consumer habits. Online shopping volumes have skyrocketed in many countries, and with this increase, online skimming attacks on credit card data have also been on the rise. According to Malwarebytes data, Magecart and online skimming attacks increased 26 percent in March 2020 compared to the previous month.

While this surge may seem like a dramatic leap, Magecart and online skimming attacks have already been on the rise, affecting many companies, and this trend is likely to continue soon. This is why the risk of exposure to online skimming attacks is higher than ever.

What Are Magecart and Online Skimming Attacks, How Do They Work?

Online skimming attacks, also known by different terms and names but becoming popular as ‘Magecart,’ steal important customer information, including credit card information, from vulnerable websites by adding a malicious Javascript code.

The Magecart attacks, which were determined as a single group’s activity in 2015, were used by different groups over time and became more widespread and have affected and threatened many large and small companies until today.

See Also: How to Protect Your POS System from POS Malware

In addition to taking advantage of vulnerable systems, attackers can add malicious code using brute force login attempts, phishing, social engineering techniques, or exploiting known software vulnerabilities. Also, attackers can add malicious code and perform Magecart and online skimming attacks by manipulating third-party external software or scripts used on websites.

Because multiple e-commerce sites often use third-party external software, malicious JavaScript code can compromise many websites’ security at the same time.

The malicious code is usually triggered when users submit their card information during checkout. Attackers can collect important information, such as billing address, name, e-mail, phone number, username, password, and card data.

Since this process takes place on the client-side, no disruption to the customer experience occurs. For this reason, it is very difficult for users and site administrators to be aware of the situation. The malicious code can store or forward the information it steals locally to a remote server controlled by the compromised server’s attackers.

Who is Targeted for Magecart and Online Skimming Attacks?

In general, any business that accepts payments online is at risk of an online skimming and Magecart attack. This threat affects e-commerce companies in the retail, entertainment, travel industries, government agencies, and third-party service providers.

It has been observed that attacks target and affect third-party companies, such as online advertising firms and web analytics providers.

How to Detect Magecart and Online Skimming Attacks?

Unlike many threats, the attack groups that use Magecart ensure that the code does not run on every site or page and hides to avoid detection. Besides, some variants can detect the presence of scanning tools and hide.

Therefore advanced variants can be challenging to see. Even if you identified the situation, a customer might have entered their credit card or personal information before you could, and the information was stolen.

Although it is difficult to detect these threats without causing any damage, it is essential. Some of the PCI DSS Requirements that can be used for detection are as follows:

• Regularly review source code (PCI DSS Requirement 6)
• Regularly scan web applications for vulnerabilities to identify web application vulnerabilities. (PCI DSS Requirement 6)
• Keep logs of all system components and security events and review them regularly to identify suspicious activity. (PCI DSS Requirement 10)
• Use file integrity monitoring (FIM) and change detection software. (PCI DSS Requirement 11)
• Regularly conduct internal and external network vulnerability scans for your critical servers, devices, and software. (PCI DSS Requirement 11)
• Perform penetration tests for your entire building to detect security vulnerabilities. (PCI DSS Requirement 11)

What Are The Ways To Avoid Magecart and Online Skimming Attacks?

As we’ve seen with other threats, there isn’t just one solution to preventing Magecart online skimming attacks. The best protection against such attacks is implementing a multi-layered defense strategy that includes operating systems and software with the latest security updates.

See Also: How to Perform Code Reviews for PCI Requirements

Control of these services and products is also essential, as attacks can again come from third-party services and products. It is recommended that these services and products be removed from the card data environment or hosted and controlled by you if possible.

Besides, it is recommended to remove or disable unnecessary, unused add-ons and services in the system. It is also vital to ensure that third-party external scripts cannot access payment pages or other sensitive areas if not required or restrict access and permissions to trusted sources.

See Also: Source Code Analysis for PCI DSS Application Security

The controls that can be applied from the PCI DSS requirements as ways of protection are as follows:

• Turn off unnecessary ports, services, and functions on servers and devices. (PCI DSS Requirement 2)
• Securely configure servers, devices, and software to industry-accepted system hardening standards. (PCI DSS Requirement 5)
• Protect against malware and keep your anti-virus software up to date. (PCI DSS Requirement 6)
• Follow safe coding development guidelines and perform code reviews. (PCI DSS Requirement 6)
• Restrict access to only required people and systems and deny all other access by default. (PCI DSS Requirement 7)
• Use strong authentication to access system components. (PCI DSS Requirement 8)
• Use IPS / IDS systems to detect and prevent attacks. (PCI DSS Requirement 11)
• Check your third-party service providers and review their services periodically. (PCI DSS Requirement 12)

Although it does not provide complete protection for all data spoofing attacks, you can use the ‘Content Security Policy’ header and the ‘Subresource Integrity’ feature to limit attack activities and make the situation more difficult for attackers.

In case attackers place malicious javascript code on your page with attack methods such as XSS, you can use the CSP principle with the script-src directive as the primary defense against the running of the malicious code. If you do not need to have inline JavaScript code on your web page, you can prevent any cruel script execution by adding the following header.

Content-Security-Policy: script-src 'self'

This ensures that only external JavaScript files are referenced from the same host as the policy and prevents inline malicious JavaScript code from being executed.

If your web page contains inline JavaScript code that cannot be externalized, you can also use the “nonce” feature.

Thus, any JavaScript code referenced both inline and externally must contain a ‘nonce’ attribute that matches the URL in the CSP script-src source list. By adding a “nonce” resource to the script-src directive, you can prevent the execution of malicious inline JS code while allowing the approved inline JavaScript code to run.

Content-Security-Policy: script-src

'nonce-1182b04d9fA988GGd3ecD336EEfbe'

Although this method is an additional security measure, JavaScript content will only be run without validation.

You can select the hash option for script-src when you want to allow and verify exactly which code to run.

Content-Security-Policy: script-src

'sha256-qbkLHiRG75A4WIrn2wzgrem8OiHCb80Vs2pjF5o ='

Hash validation will provide a significant security advantage for the implementation, but will also add administrative overhead. For this reason, its use only on essential pages such as payment pages will provide convenience in terms of management.

Only inline javascript code is not used in Magecart or online skimming attacks. These attacks can also be carried out with JavaScript code referenced from a third party external domain. For this reason, you must specify all allowed domain names to receive JavaScript files for your pages.

Once you’ve identified all the permissible third-party script locations you use, you can edit your CSP header as follows.

Content-Security-Policy: script-src 'self'

www.google-analytics.com

In the example above, we’ve identified authorized domains for third-party external JavaScript and added it to the whitelist. This method would be a good first step to prevent JavaScript skimmer attacks, but it may be possible for the attacker to add a different or malicious script to a 3rd party domain you whitelisted.

In this case, you can further tighten the CSP policy by specifying the script resources down to the file level.

Content-Security-Policy: script-src 'self'

https://ajax.googleapis.com/ajax/libs/jquery/1.8.3/jquery.min.js

In this way, instead of adding the full domain name of ajax.googleapis.com to the whitelist, you only allow the relevant js file to be loaded over HTTPS.

If you do not want to protect all script-controlled resources in your CSP header by whitelisting, you can use the ‘nonce’ value, as discussed in the previous section.

When trying to whitelist third-party JavaScript resources, you may encounter the issue of other files being called as well. The impact of file interdependencies can make it challenging to manage the CSP whitelist. For this reason, you can also use the strict-dynamic feature that comes with CSP v3.

Content-Security-Policy: script-src 'nonce-1182b04dhv7854773fD332EEfbe' 'strict-dynamic'

If you want to verify the actual content of external JavaScript files, you must use the Subresource Integrity (SRI) web browser feature. SRI allows you to validate remote script content by specifying an integrity property to your script calls.

However, you need to calculate the hash of the file content before using this feature.

<script src = "https://ajax.googleapis.com/ajax/libs/jquery/1.8.3/jquery.min.js" integrity = "sha384 lifoBlbdwizTl4rtR612uhI3AcOam / QtWkozF7SuiACaf8HgJl5reOYuCH4" crossword ""

When SRI is enabled for this external JavaScript resource, the browser will prevent it from running if the content of the file changes.

SRI is an excellent way to verify the integrity of file contents, but attackers may find a different way to add new JavaScript code to a page that does not have the SRI integrity specified. In this case, we can combine CSP and SRI properties with a new CSP directive called ‘require-Sri-for.’

Content-Security-Policy: script-src 'self' https://ajax.googleapis.com/ajax/libs/jquery/1.8.3/jquery.min.js; require-sri-for script

You can use this feature to enforce all scripts on the page by SRI, but although most modern browsers support this feature, it is not yet available in browsers and needs to be activated by the user.

There are many distinct views on the efficacy of CSP in preventing data leakage. Instead of considering CSP and other techniques as a complete and effective method for all data leakage attacks, it would be appropriate to limit attack activities and make the situation more difficult for attackers.

Magecart and online skimming attacks do not seem to be eliminated shortly. On the contrary, when we look at the data obtained, it is noted that such attacks are increasing and affecting many organizations, regardless of whether small or large.

You can avoid these attacks as much as possible by applying the techniques and PCI DSS requirements mentioned above. A multi-layered security understanding and tight control of third party services will help protect you from such attacks.

For detailed information, you can check the blog post “The Threat to Check Payment Security Online“.