Americas

  • United States

Asia

Oceania

lconstantin
CSO Senior Writer

Target releases web skimming detection tool Merry Maker as open source

Feature
Feb 03, 20229 mins
Fraud Protection and Detection SoftwareMalware

The open-source tool simulates online browsing and shopping to identify malicious code meant to steal payment card information on retailers' websites.

credit card theft / credit card fraud / credit card hack
Credit: Jariyawat Thinsandee / Getty Images

Web skimming has been a major scourge for online shops over the past several years with attacks ranging from simple script injections into payment forms to sophisticated compromises of legitimate third-party scripts and services. Sometimes referred to as Magecart attacks, they have become the leading cause of card-not-present (CNP) fraud and have impacted small and big brands alike, as well as different types of ecommerce platforms.

As one of the top online retailers, Target started looking for solutions a few years ago to combat this threat and keep its own customers protected while shopping on its platform. Since there were no ready-made detection tools for such attacks at the time, two of the company’s security engineers decided to develop their own. After being in active use on Target.com for over three years, the company’s client-side scanner has now been released as an open-source project dubbed Merry Maker.

“Merry Maker continually simulates online browsing and completes test transactions to scan for the presence of malicious code,” the company said in a blog post. “Merry Maker acts like a guest on Target.com by completing several typical activities including online purchases. While doing so, the tool gathers and analyzes a variety of information including network requests, JavaScript files, and browser activity to determine if there’s any type of unwanted activity.”

What is card skimming?

Card skimming is a type of attack where a malicious device or mechanism is inserted at the point of a legitimate transaction to capture card details. It is a man-in-the-middle attack. In the physical world, skimming devices are attached to the card slot of ATMs or gas pump payment terminals to capture the data encoded on the card’s magnetic stripe. They are typically accompanied by small cameras or PIN pad overlays to capture the PIN numbers inserted by users as well. The transition to chip-based cards that use encryption along with other transaction authentication and validation features is meant to combat such card-present attacks.

Web skimming or digital skimming attacks follow a similar principle but use malicious code injected into the payment pages of online shopping sites with the goal of capturing and siphoning off the card details and other payment information inserted by users into forms. These malicious skimming scripts end up on websites in several ways: by using weak or stolen administrative credentials, by exploiting vulnerabilities in web applications that allow attackers to upload unauthorized code on web servers, or by compromising third-party services such as web analytics whose legitimate scripts are already loaded into the payment pages.

Web skimming groups use sophisticated techniques to make their keylogging code hard to detect. The code can be heavily obfuscated and added to existing JavaScript files or even stored in other types of resources such like CSS or even embedded into images or it can be hosted on third-party domains that have similar names to those used by legitimate services or on content delivery networks with only a small import function in the actual website.

Merry Maker uses client-side detection

Website owners can use different technologies on web servers to detect the unauthorized modification of script files. However, websites can be highly complex, using dynamically generated code based on information stored in databases that is then served to users on the fly. Because of this, a proper defense strategy also requires scans performed with client-side crawlers that can capture the full rendered code that a regular user’s browser would receive. That’s exactly how Target’s Merry Maker was designed to work.

“Merry Maker is built to mimic the behavior of real users as they navigate a site: searching for a product, adding it to the cart, entering payment details, and submitting the order,” the Target engineers said in another blog post. “All client-side code that runs during those steps can only be fully executed in a real browser.”

The framework has two components: an administration dashboard where defenders can define detection rules and review alerts and the client-side scanner itself which is implemented using Headless Chrome — a programmatically controlled version of the popular browser. Since its launch in 2018, the scanner has completed over a million scans on Target.com.

For automating the headless browser, Merry Maker relies on a Node.js component called Puppeteer that provides an API to control the browser through the DevTools protocol by using instructions written in JavaScript. To complement this, the Target engineers developed a tool called JS Scope that enumerates javascript requests and hooks the browser’s native function calls.

“JS Scope gives us a better understanding into the behavior of client-side code beyond static analysis,” the engineers said. “Every hooked function call, web request, response, cookie and other relevant calls are captured and analyzed in near real-time.”

The scanner can execute multiple detection rules to the events and content grabbed by the headless chrome in real time. The scanner supports YARA rules — a mechanism for classifying and identifying malware samples — and can take in publicly available rulesets that other defenders have written or custom made ones to detect specific types of data or strings. In addition, it supports detection rules based on known indicators of compromise (IOCs) such as digital skimming domains that can be ingested from public lists or a security intelligence vendor.

Writing more complex detection rules is also supported via Typescript, a programming language developed by Microsoft that builds on top of JavaScript and extends its syntax. There are also more generic detections for unknown domain names, which takes a white-list approach where requests to any domain that hasn’t been white-listed is flagged as potentially suspicious.

The alerts generated by the scanner can be received in three ways: through the Merry Maker dashboard; through Kafka, an open-source distributed event streaming platform; or through GoAlert, another open-source Target project that supports on-call scheduling, automated escalations and notifications via SMS or voice calls.

Merry Maker can be deployed as a Docker container, which means it can easily be deployed on cloud infrastructure around the world to mimic the geographic diversity of real users. Some skimmers trigger their malicious code only to visitors from certain locations or from certain browsers with certain language settings. All these visitor profiles can be mimicked with Merry Maker.

Skimmers are evolving and detection needs to keep up

Detection tools and techniques are never a silver bullet. They need to be complemented with active preventive measures such as keeping all third-party scripts, add-ons, frameworks and plug-ins that make up a site up to date, static and dynamic vulnerability scans, internal and external code security audits, proper credentials management and two-factor authentication, removing unnecessary code from critical pages such as payment forms and leveraging browser-based security mechanisms such as Content Security Policy (CSP) and Subresource Integrity (SRI). While none of these alone offer perfect protection, when used together they significantly lower the chance of a skimmer infection.

CSP is a mechanism through which a website can tell browsers the trusted external domain names from which executable scripts can be loaded into its context. If the browser encounters a script that is not from one of the domains white-listed in the CSP policy, it should refuse to load it. While it can be a great defensive mechanism, CSP does not address the cases where a trusted third-party service that has been white-listed is compromised and the malicious injection occurs on their end.

SRI comes to complement CSP because it allows websites to specify a cryptographic hash for the external resources they fetch, for example from a CDN. The browser will validate that the external resource, such as a script, has the hash specified by the website that tries to import it and will refuse to load it if the hash value doesn’t match. This is meant to protect against malicious manipulation of external resources. The problem with SRI is that it’s not easy to maintain, especially on very large websites with a lot of external resources and dynamic code.

“There are no easy answers to this problem,” Chris Carlson, senior director cybersecurity and one of the Merry Maker developers, tells CSO. “SRI can be a challenge if third-party resources are heavily relied upon by an organization for telemetry/analytics. For Target, a key first step to enhancing website security has been helping the teams who decide on third-party content to understand the risks. We’ve removed all the third-party content served on sensitive pages that we can and are working towards using SRI on first-party scripts.” The other Target staff who created Merry Maker are Principal Engineer Eric Brandel and Distinguished Engineer Caleb Walch.

In a presentation at Black Hat Europe in 2021, researchers from security firm Cyberpion presented various detection evasion techniques that skimmers can use to evade client-based detection, including a so-called “scriptless” injections where a legitimate third-party script uses a fourth-party service to store other sources of data that affect a script’s behavior and which can be loaded into the script’s context via Ajax requests. Compromising these fourth-party sources of data can also provide attackers with an avenue of attack while the code of the third-party script itself remains clean. This is an example of a digital supply-chain attack where the attack is moved higher up in the chain.

“Merry Maker can detect first- or third-party (or for that matter, fourth-party) compromises because it’s examining all the JavaScript code (not its origin) and all the network traffic generated for indicators of malicious intent,” the Target engineers tell CSO. “Regardless of source, Merry Maker detects indicators.”

That said, there are techniques and even open-source libraries out there designed to detect the use of headless browsers and distinguish them from real active visitors. Skimmers could make use of such methods to avoid displaying their malicious code to automated scanners like Merry Maker.

“​​As with much in cybersecurity, it’s a matter of keeping pace with evolving threats,” the Target engineers say. “We have countermeasures in place to try and mitigate the likeliness of this impacting detection and fortunately Puppeteer has a growing community of libraries to combat these types of techniques.”