Magento Shoplift Vulnerability and Payment Data Risks

Much has been made of the Magento Shoplift vulnerability and we have certainly seen a notable uplift in Magento related investigations on the back of it. A trend that we have observed involves a variation to the Shoplift attacks, designed to steal payment card data from outsourced payment models - such as iframes as provided by all major payment processors.

Protect Your eCommerce Site from Magento Shoplift Attacks

For those unfamiliar with the concept of outsourced payment models, it's the adoption and implementation of eCommerce payment services from commercial payment service providers, rather than merchants handling the payments themselves.

You've probably experienced this yourself when you suddenly get whisked off to a different site to present your payment details and then reverted back to the eCommerce website once payment has been made. The idea being to make sure payment details pass directly from the consumer to the payment service provider who has had their operational security reviewed and certified as PCI DSS Compliant. 

How does this malware work?

The basics are pretty straight forward and follow this process:

1. An attacker exploits the Magento Shoplift vulnerability to gain access to the website.
2. This access permits them to insert data or code directly into the site's database.  Magento also has the ability to render content directly from the database and this situation means attackers can push malicious code into an eCommerce website that never actually "touches the disk" directly. As such, normal attempts to detect the compromise would be found lacking — the analysis *has* to consider the database content.
3. Client side attacks - an additional twist in the scenario above affecting eCommerce websites with fully outsourced payment models, is that we are starting to see an increase in the number of situations where client side code is being pushed into the database. Generally JavaScript, this is executable code that would run in the consumer's browser and as such would be able to "see" the payment card details even though the don't go anywhere near the compromised merchant's site.

Samples that we have seen follow a similar approach in that they monitor the checkout process and attempt to copy each form field to a serialised variable. Certain malware samples then perform a very simplistic regular expression validation against the string of form data, checking if one of the fields might be a card number. In at least one family of malware injections we've seen, the regular expression is simplistic to the point that it would not steal payment details when presented in a format that includes dashes or spaces (as in xxxx xxxx xxxx xxxx or xxxx-xxxxxx-xxxxx) but this is not to say all versions have the same flaw.

Once the malware is content that it might be in possession of payment card information, a session is opened to the attacker's drop site using the XMLHttpRequest() method and the details POSTed. You might notice from the screen shot above, that the malicious code actually tags the uploads with the details of the site the information came from. This means the chances are it's a much more widely spread problem than a few forensic/incident response cases in the UK (which is where we have seen the samples).

What can you do?

Reviewing of database content is strongly advised and any instances of the following basic search patterns should be carefully reviewed:

    XMLHttpRequest

    setRequestHeader

    querySelectorAll

Finding one of these patterns in your database certainly does not mean you're compromised, but it should be treated with caution. 

Check your website security

Use our free scanner, WebScan, to check your website's external security status.