On September 18th, a series of incidents of credit card skimming attack came to light, as first reported by TrendMicro. Magecart was used to hit two booking websites belonging to two different hotel chains.
Both hotel chains operate approximately 100 properties each, in 14 countries. The report described the attacks in great detail, which I thoroughly enjoyed. From the conclusions, it seemed like the compromised websites could not have done anything to prevent the incidents.
Let’s take some time to explain exactly what the hackers did, and why they did it. I will also discuss some of the mitigation options available and explain why traditional methods will NOT work with this type of attack. Ultimately, we’ll discuss the only solution that could have prevented these incidents.
The attack recap and reasons behind what the hackers did:
Who is Magecart?
Magecart is the name given to a malicious group of hackers targeting eCommerce and retail customers. This specific major hacking group plants JavaScript malware which is typically hosted by a 3rd party, with the intention of skimming credit card data and personal information from innocent internet users as they interact with websites. Even though websites normally do not store users’ full payment information (such as CVV security code), the malicious script doesn’t need to break into the website’s database but instead watches as the information is being entered by customers who check out.
How Did they Do it…in 5 Steps
- The Magecart hackers managed to infiltrate JavaScript code developed by Roomleader, a Spanish company that helps hotels build their online booking websites, but the hackers could have used any third party code employed by the websites, as long as it’s JavaScript. This includes analytics, ad servers, chats, reviews, comments and essentially any other 3rd party vendor code out there.
- When the JavaScript code was delivered to a PC, or when the developer tools were open, it didn’t contain the call to the malicious code. But when it was delivered to a mobile device, the request to the malicious code was there. There’s a reason for that – the hackers wanted to avoid detection, and PCs have better ways of detecting malicious code.
- The actual malicious code was delivered by the hackers’ Google Tag Manager account. We can assume that the reason for using the Google Tag Manager was to avoid any CSP or SRI protection on the site. In many cases, we see CSP wrongly mentioned as a solution for Magecart and Formjacking attacks. This simple solution of using a whitelisted domain such as Google, Facebook or any other 3rd party domain is employed by hackers to overcome this obstacle. An SRI would also not work here since the code from Roomleader was legit. Since tag managers are dynamic in nature, even if an SRI was used it wouldn’t be effective.
** Another benefit, from the hackers perspective, of using Google Tag Manager is its ability to send code according to a specific visitor’s profile. Which means, they could have used its native ability to send the malicious code only to visitors from a mobile device instead of writing the system themselves. - When the malicious code was activated on the visitor’s browser, it replaced the credit card HTML form with an HTML form of its own. The hackers prepared that form in 8 different languages so it would look authentic to the visitor. This was done in order to remove any protection the credit card form might have had, such as JavaScript proxy protection or a foreign iFrame of one of the payment companies such as PayPal. Using this simple method, it is possible that the hackers removed the iFrame and put their own code.
- Upon submission, the JS encrypted the credit card information and sent it to the hackers’ drop servers. Don’t think for a second that the hackers encrypt the data because they are worried about our own security – they use it to avoid JavaScript proxy protection that uses RegEx to find and replace credit card information before it is sent.
Beware of Future Threats
The next evolution of this code can remove the need for the drop server, and uses legitimate whitelisted tools to capture credit card information. For example, using Google Analytics to capture data by sending it as a page view, or using Facebook to publish a comment with the data on the hacker’s Facebook account.
Hackers are constantly trying to thwart detection and another method they may utilize is pushing their code every few thousand page views just to avoid bot detection. The variance can be just random enough that traditional methods won’t establish sufficient protection.
Quick Summary
This artful attack was built to avoid detection. This means that some common recommendations for using CSP, SRI, Foreign iFrame, or JavaScript proxies would not be effective and could not have prevented it.
The domains ware whitelisted, so CSP never would have caught it; JavaScript Proxies could not have prevented the creation of the form or detect that the credit card information was taken, since the data was encrypted.
Even SRI would not be effective since the Roomleader code was legitimate and simply called the tag manager; it would have been sealed by the SRI, since the tag manager is dynamic in nature.
So, what could have been the solution?
Real-time JavaScript sandboxing technology would have been an effective solution. In this case, the third-party could be isolated inside a virtual page, which managed the level of access that each third-party has to the content of the page based on policies. This means that any interaction between the visitor and the website is isolated from the third party, and that every third-party action is monitored and controlled seamlessly in real-time.
If a 3rd party is compromised, the virtual page will isolate this behavior and refuse to present it to the visitor. This is actual, real-time prevention where we cut out the 3rd party’s ability to interact directly and maliciously with the page. It prevents data leakage of any kind and allows website owners to gain back control over their users’ website experience.
A dedicated solution for this attack is really the only prevention method. At Source Defense, we’ve spent the past four years developing a 3rd party JavaScript security solution that prevents attacks in real-time, using machine learning and AI technology. It works in the background, without affecting user experience, and automatically adapts to new threats.
Glossary:
CSP – Content Security Policy (CSP) is an added layer of security that helps detect and mitigate certain types of attacks, including Cross-Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft through site defacement to the distribution of malware.
SRI – Subresource Integrity (SRI) is a security feature that enables browsers to verify that the resources they fetch (for example, from a CDN) are delivered without unexpected manipulation. It works by allowing you to provide a cryptographic hash that must match the fetched resource.
JavaScript Proxy – A method used to control the actions of native JavaScript functions by overwriting the native prototype of the function and replacing it with your own code. For example, you can overwrite the prototype of getting an element’s value and replace it with a function that checks the value prior to providing it against a RegEx of a credit card number and if it matches, returns a redacted value.
Drop server – the hacker server to which visitors’ information is sent.
Learn more about Magecart attacks.
Learn more on Hadar Blutrich
CTO of Source Defense
About Source Defense: Source Defense provides a unique website security solution focused on preventing malicious activity originating in website supply chain vendors. Using a first-of-its-kind technology based on machine learning and industry best practices, Source Defense provides a fully automated and dynamic set of rules and policies that control access and permissions of all Javascript-based 3rd party tools operating on any website. Visit www.sourcedefense.com for more information.
PCI DSS 4.0 makes client-side security a priority.
Source Defense delivers a solution for 6.4.3 and 11.6.1 without adding a burden to your security teams.
