Widespread credit card hijacking discovered

Criminals have secretly rewired 3,500 online stores to continuously harvest credit card numbers. The fraud can be traced back as far as May 12th, so if you have bought something at one of these stores in the last 6 months, your credit card is likely compromised.

We received reports of suspicious Javascript code through MageReport and have ran a scan on all known shops globally. To our horror, we discovered thousands of credit card hijacking shops.

There are multiple versions found in the wild, but they work the same. The malware is embedded in the header or footer of every page. Once an unsuspecting shopper submits a form that contains anything resembling a credit card number, the whole form is transparently copied, using AJAX, to a remote location.

This is a sample found in the wild (which sends credit card data to http://ownsafety.org/opp.php):

We have found other collector servers as well, in order of frequency:

Disturbing in several ways

First, the malware went unnoticed for more than 6 months. It runs in the browser and is stored in the database of the CMS. This makes it hard to discover on a server level. Server measures like a periodic git status or a read-only filesystem will not help.

Second, with this new attack, credit card numbers are captured as soon as an unsuspecting shopper types them in their browser. Until now, credit card thieves mainly targeted (transaction) servers, where payment data is generally encrypted and thus hard to extract. With this new attack, credit cards are captured before they can be encrypted.

And finally, the high number of compromised stores implies extensive automation in discovery and exploitation. This is not the work of script kiddies. (By the way, none of our own customers were compromised, as we filter most suspicious behavior).

Recommendations

We urge merchants and developers to verify the safety of their shop at MageReport, where we have added a specific check for Credit Card Hijacking and removal instructions. But please take a close look at the other results as well.

Meanwhile, we are working with the Dutch Cyber Security Center to get the collector servers down ASAP. Fixing all the stores involved will take a little longer, but Google will block these shops in the browser shortly.

Background: going back in time

To determine the first occurrence of this attack, the historical archives at scans.io are a great resource. The University of Michigan provides bi-weekly snapshots for HTTP frontpages for every IPv4 on the planet, going back two years. With some computing power and time, we parsed all the archives until no more traces of the malware could be found (code here). So the first malware was implemented between April 28th and May 12th. It gives interesting insights in its lifecycle, as the malware started by posting to its own address. Later on, likely because more shops were involved, the code switched to central reporting.