Magecart Impacts Hundreds of Thousands of Websites, Still Growing

[steven36]

With over two million detections to date, compromising shopping sites' resources to steal customer payment card info is a global phenomenon unlikely to end soon.

 

 

These attacks are collectively known as Magecart and there are multiple groups currently in the business, some more advanced than others.

 

They target online payment forms and steal card data at checkout, a cybercriminal activity known as web skimming. This is done by loading at checkout JavaScript code designed to copy payment data and to send it to the attackers' server.

 

Getting the code on the checkout page is possible by breaching the website directly or by compromising a web resource from a third party that is loaded on the page, such as an analytics script or a customer support widget.

Millions of Magecart instances detected

In a report released today, RiskIQ notes that the first Magecart threat they observed was on August 8, 2010. The phenomenon did not take off until last year, though, when British Airways, Ticketmaster, OXO, and Newegg were hit.

 

Since then, multiple attackers emerged creating dozens of card info skimming scripts and infecting thousands of websites. In one automated attack alone, over 960 stores were compromised.

 

RiskIQ estimates that the Magecart threat may have impacted millions of users. Their telemetry data shows a total of 2,086,529 instances of Magecart detections.

 

According to the company, supply-chain attacks account for the highest spikes in Magecart detections.

 

"Suppliers can include vendors that integrate with sites to add or improve site functionality or cloud resources from which websites pull code, such as Amazon S3 Buckets. These third-parties integrate with thousands of websites" - RiskIQ

 

Out of all Magecart groups tracked by security researchers, Group 5 is the most prolific and advanced. They focus on third-party suppliers, like website analytics providers SociaPlus and Inbenta, and skim payment details from hundreds of websites.

 

Unsecured or misconfigured Amazon S3 buckets are also among the targets, as they often store resources used by a large number of domains. One actor set sight on them and automated the discovery and compromise process to impact more than 17,000 domains.

 

Since the beginning of the campaign in early April this year, RiskIQ monitored the compromise of S3 buckets and recorded worrying statistics: over 18,000 hosts with Magecart AWS injects.

 

Attackers monitor security developements

Many of the Magecart groups that RiskIQ tracks still focus on the Magento shopping platform, which was the main target when these attacks started to multiply. OpenCart is also of particular interest to the attackers.

 

 

Attackers keep a close eye on the development of these shopping cart platforms and vulnerabilities discovered in one of them are normally followed by a spike in the number of victims.

 

The victim context is reversed when a patch is released and admins start applying it. The graph below shows how the number of victims fluctuates according to Magento security developments.

 

 

 

Taking any opportunity

While the details above clearly show how prevalent is Magecart, they do not tell the full story of the phenomenon as the threat actors are constantly looking for new ways to distribute their web skimming scripts.

 

RiskIQ observed a new set of targets as "Magecart groups are also compromising creative ad script tags to leverage digital ad networks to generate traffic to their skimmers on thousands of sites at once."

Of all malicious advertisements, the company discovered the 17% distribute the Magecart threat.

 

As for the average time of a breach, the code survives on average for 22 days. The reason is that many victims are unaware that their website loads malicious JavaScript.

 

New Magecart actors are likely to appear since Magecart has spread so widely that its infrastructure is a common occurrence. Much of it is managed by responsible security parties making sure that traffic from the victims does not reach the bad guys.

 

This is done by taking the malicious domains used to serve the web-skimming code and/or receive the card information. The bad news is that many of these domains end up being released to the public pool as the registrar takes them offline or puts them on hold.

 

Since many Magecart scripts continue to be active on victim websites, malicious actors buy the released domains and resume their activity.

 

As if all this was not enough, researchers from IBM X-Force Incident Response and Intelligence Services (IRIS) published last week a report about Magecart Group 5 testing card stealing scripts that are injected into websites through commercial routers providing WiFi in public spaces like airports, hotels, casinos or resorts.

 

One of the scripts, 'test4.html', has code to interact with commercial-grade Layer 7 routers that can provide WiFi connectivity after passing through a captive portal that sets some conditions, like paying for the service or viewing ads.

 

Another script indicates that the actor aims at infecting Swiper, an open-source JavaScript library used by about 300,000 to make websites built for desktop viewing compatible with mobile devices.

Add some safety measures

Putting an end to these incidents may not be a realistic endeavor for the moment but there are ways to reduce their frequency. Merchants can enable checks on third-party resource integrity through Content Security Policy (CSP) that allows loading JavaScript from a trusted list of domains and block the attackers' domain.

 

Another option is Subresource Integrity (SRI), which prevents loading modified JavaScript code by checking a cryptographic hash for the legitimate resource.

 

Consumers have few options to stay safe against Magecart. Using browser plugins that block loading of JavaScript helps in the case of untrusted websites but it's of no use with those already whitelisted.

 

A more technical approach, which has obvious shortcomings for the average user, is to block connections to domains and IP addresses used by the attackers.

 

Source