BA and Newegg - How Can Friendly Site Javascript Attacks be Stopped?

Written by

Last week it was reported that the criminals behind Magecart had struck another major organization - the computer hardware and electronics retailer, Newegg. The criminal team was working through Newegg infrastructure at exactly the same time they were hacking British Airways, using the same end game technique.

As with BA, malicious JavaScript code appeared during the checkout process at Newegg, collecting data from the billing information page and sending it back to the attackers. The JavaScript found here was also very similar to that found in the British Airways hack, customized to blend in with the Newegg website, as the Magecart hack works by refining their domains for each site in order to hide within normal traffic.

The script was minimized to just eight lines of code, and displayed their trademark customization. 

It is thought that the Newegg website was compromised for over a month, with the malicious domain registered on August 13th, and not removed until September 18th.

This is the latest in a series of high profile attacks that Magecart has been behind - also responsible for the Feedify and ABS-CBN breaches - and they are expected to continue to target further organizations.

Why are attacks of this nature getting more popular?
Traditionally, criminals target the databases or the post-website internal network traffic to collect user financial data, but those methods are highly defended. The trusted third party Javascript technique makes the collection of stolen data simpler, as the theft takes place on the end-user’s side and is pushed to the criminal’s command and control center as it is collected. This method also makes detection harder, as the sites (and therefore the content they deliver) are trusted.

Furthermore, while compromising a database will give an attacker access to a bulk of data, often it’s not of great financial value. For example, sensitive information such as credit card numbers are usually encrypted, and CVVs are rarely stored at all.

By intercepting payment details at the time of use - as happens in this technique - the criminals gain access to highly valuable data in real-time.
 
Previously, this data would only have been accessible through endpoint malware infection. However, this new technique is more efficient for criminals, as it compromises servers, rather than infect individual endpoints. While servers generally require greater effort to hack than your typical home user’s computer, such intrusions pay far larger dividends because, once compromised, a centralized server can distribute malware to every user of a site.

The barrier to entry for orchestrating a JavaScript-based malware attack isn’t as high as one might think. For example, in the BA breach, the hackers didn’t have to compromise the BA website itself, they only needed to compromise one of the many third-party applications they use.

Modern websites make use of scores of third-party libraries, and each is essentially a hole that can be exploited to expose the whole website. Once attackers have infiltrated the systems controlling third-party libraries, they can insert site-specific malware into files.

For example, in the case of Newegg, it was inserted into files containing the payment functionality of the Newegg site. This method is not so much a trojan horse as a subversion of legitimate functionality. Once the malicious code is merged into the legitimate code it will be served to every visitor of the infected site.

How can you protect against this type of attack?
To date, the security community and businesses have not had the tools to address these types of attacks automatically. Defense relies on detection of changes in the third-party libraries, and an active review of those changes. However, this has little effect if the code is new - or carefully customized to the Newegg website in order to avoid detection.

Additionally, this technique is time-consuming and prone to human error, particularly with minified JavaScript.

Rather than depending on reactive detection of malicious code changes, businesses should turn the issue on its head, by stopping payment information from leaving the site. Real-time monitoring of web sessions can detect this behavior and the malware can be disabled so that it doesn’t even have access to the data.

Businesses need to consider the fact that their websites can be used to facilitate attacks on their users, and they need to be proactive about ensuring this doesn’t happen. This technique would mean that no matter the method of attack, it would be unsuccessful, and customer data would remain protected. 

In today’s digital world, it’s impossible to stop criminals from attempting to hack customers online, but if transaction sessions are protected, fraudulent activity will be unsuccessful.

What’s hot on Infosecurity Magazine?