Author: Jen Stone
With so much critical information available online, malicious actors have found increasingly insidious (and automated) ways to steal it. One method is the skim hack, such as JavaScript skimming or formjacking. This is also sometimes referred to as Magecart, although that is more accurately the name of the group that is known for practicing this type of theft.
Skim hacks siphon off information as it is transmitted to a legitimate site. For example, if you make a purchase online, attackers will try to capture your card data as it is entered. Your purchase will go through without interruption, but the information you entered will also be skimmed off for illegitimate uses, without giving any indication to the user that the information was stolen.
Shopping carts make good targets for skim hacks because the code is readily available, making it easy for attackers to look for exploits. They often have a larger attack surface than other publicly available webservers because they incorporate a lot of third-party code, such as webpage analytics.
Even innocuous-seeming websites can be poised to steal your information. Think of a site where you use login credentials but don’t consider any of the information you share on that site to be sensitive. Do you use those credentials on another site, just to make things easy to remember? A lot of people do. If a skim hack can successfully grab your account credentials from a seemingly low-risk site, the attackers will take those credentials and try them against other sites where you might have stored valuable information.
How a skim hack is executed
The goal of the attacker is to insert a piece of code that skims data. How and where the code is inserted varies widely. An attacker might exploit vulnerabilities in the webserver operating system, payment application, or other software with public exposure. They might compromise admin credentials through brute force or phishing attacks, giving them full access to the webserver.
Most e-commerce sites pull code from third-party libraries, making them vulnerable to supply chain attacks. Shared libraries are a juicy target because they offer the potential to share malicious scripts with multiple websites.
The full malicious script can be stored on the compromised webserver, or a small script tag can refer to the larger script hosted elsewhere. It can be added to legitimate script libraries or inserted anywhere into the HTML.
A pernicious variation is to dynamically add the script to the document object model (DOM), making it particularly difficult to detect, since it won’t appear until the page executing the malicious software is built. This dynamic state change means that typical vulnerability scanning methods won’t see the script at all. As a matter of fact, scanning methods that are able to build the full DOM and scan all states are currently prohibited by the PCI ASV methodology, due to their potential negative impact to the website’s functionality.
Scripts are obfuscated in various ways. Symantec put out an excellent report on formjacking that describes types of obfuscation in detail. I’ll include a link to that paper at the end of this article, along with links to other useful references on skim hacks. For now, just understand that you can’t expect to look at the code on an e-commerce site and pick out malicious scripts.
Once inserted, scripts can be written to execute on all types of triggers. They might execute based on time, on a key press or mouse event, when a form is submitted, or when a change happens to a page. One of the sneakier triggers I’ve seen was a script that executed when the user entered a CVC code into a payment page and then left that field. The payment didn’t need to be completed before the attacker skimmed the credit card data.
Data can then be exfiltrated using various methods, sending data to external servers to be used in various malicious ways. The data can even be encrypted on exfiltration in ways that gets it past data loss prevention (DLP) tools.
How to protect against skim hacks
It’s not all bad news. There are ways to detect and defend against skim hacking, but there isn’t an easy button. From the website visitor’s perspective, they’re going to have a difficult time detecting this type of attack. However, the purchaser can assume compromises abound and implement two-factor authentication on their payment card, keep their credit frozen (not always easy), and subscribe to a service that watches for indicators of compromise of the user’s PII and card data.
Mitigating against skim hacks requires a multi-layered effort on the part of the website owner, starting with the defense-in-depth approach described by the PCI DSS and other security standards. Critical requirements include change control, system hardening, intrusion detection, and file integrity monitoring (FIM).
Additional critical protections include the following:
Implement a robust, ongoing, automated vulnerability scanning program.
Undergo third party penetration testing on a regular basis.
Use HTTP Content- Security-Policy (CSP) and Subresource Integrity (SRI) to gain more control of scripts.
Remove any externally loaded, third party scripts that are not critical to functionality (sorry Marketing).
Many organizations with e-commerce websites are too small to handle all the necessary security controls and should consider engaging a third-party security service provider.
To read more about skim hacks and how to prevent them, see these articles:
About the Author: Jen Stone is a Principal Security Analyst at Security Metrics. With over 20 years working in IT and holding numerous certifications, she brings a breadth of experience to her work performing audits. Jen also hosts two cybersecurity podcasts and is a prolific writer and speaker.