Skim Hacks: What They Are and How to Defend Against Them
Author: Jen Stone
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.