{"id":15362,"date":"2019-05-21T08:10:09","date_gmt":"2019-05-21T16:10:09","guid":{"rendered":"http:\/\/www.palada.net\/index.php\/2019\/05\/21\/news-9111\/"},"modified":"2019-05-21T08:10:09","modified_gmt":"2019-05-21T16:10:09","slug":"news-9111","status":"publish","type":"post","link":"http:\/\/www.palada.net\/index.php\/2019\/05\/21\/news-9111\/","title":{"rendered":"Skimmer acts as payment service provider via rogue iframe"},"content":{"rendered":"

Credit to Author: J\u00e9r\u00f4me Segura| Date: Tue, 21 May 2019 15:38:42 +0000<\/strong><\/p>\n

Criminals continue to target online stores to steal payment details from unaware customers at a rapid pace. There are many different ways to go about it, from hacking the shopping site itself, to compromising its supply-chain.<\/p>\n

A number of online merchants externalize the payment process to a payment service provider (PSP) for various reasons, including peace of mind that transactions will be handled securely. Since some stores will not process payments on their own site, one might think that even if they were compromised, attackers wouldn’t be able to steal customers’ credit card data.<\/p>\n

But this isn’t always true. RiskIQ previously detailed<\/a> how Magecart’s Group 4 was using an overlay technique that would search for the active payment form on the page and replace it with one prepped for skimming. <\/p>\n

The one we are looking at today adds a bogus iframe that asks unsuspecting customers to enter their credit card information. The irony here is that the shopping site itself wouldn’t even ask for it, since visitors are normally redirected to the external PSP.<\/p>\n

Skimmer injects its own credit card fields<\/h3>\n

Small and large online retailers must adhere to security requirements from Payment Card Industry Data Security<\/a> (PCI-DSS) that go well beyond using SSL for their payment forms. Failing to do so can lead to large fines and even the cancellation of their accounts.<\/p>\n

One of the most popular e-commerce platforms, Magento, can help merchants be PCI compliant<\/a> via its Magento Commerce<\/a> cloud product or integrated payment gateways and hosted forms without sensitive data flowing through or stored on the Magento application server itself.<\/p>\n

During one of our web crawls, we spotted suspicious activity from a Magento site and decided to investigate further. The following image depicts two slightly different checkout pages based on the same platform, with the one on the right being the suspicious site we had identified.<\/p>\n

\n
\"\"<\/a>
On the left, the expected payment form; on the right the one with a rogue iframe.<\/figcaption><\/figure>\n<\/div>\n

What we notice are new fields to enter credit card data that did no exist on the left (untampered form). By itself, this may not be out of the ordinary since online merchants do use such forms (including iframes) as part of their checkout pages.<\/p>\n

But there are some things that just don’t add up here. For example, right below the credit card field is text that says, “Then you will be redirected to PayuCheckout website when you place an order.<\/em>” Why would a merchant want to get their customers to type in their credit card again and hurt their conversion rate?<\/p>\n

And indeed the unsuspecting shopper will then be taken to another\u2014 legitimate this time\u2014payment form to re-enter their credit card details. This should be an immediate red flag if you have to type in your information twice. This is the kind of scenario we typically see with phishing sites as well.<\/p>\n

\n
\"\"<\/a>
The legitimate (external) payment form<\/figcaption><\/figure>\n<\/div>\n

At this point, we know that this e-commerce site is yet another victim that fell into the hands of one the Magecart groups. In the following section, we look into at how this attack works.<\/p>\n

A three-step exfiltration process<\/h3>\n

The Magento site has been hacked and malicious code injected into all of its pages. However, the most important one that we are going to look at is the actual checkout page.<\/p>\n

The crooks first load their own innocuous iframe to collect the credit card data, which is then validated before being exfiltrated.<\/p>\n

\n
\"\"<\/a>
Traffic capture showing the steps involved in credit card theft<\/figcaption><\/figure>\n<\/div>\n

As we mentioned, injected code is present in all the PHP pages of that site, but it will only trigger if the current URL in the address bar is the shopping cart checkout page (onestepcheckout<\/em>). Some extra checks (screen dimensions and presence of a web debugger) are also performed before continuing.<\/p>\n

\n
\"\"<\/a>
Injected snippet that checks for certain elements before loading the full skimmer<\/figcaption><\/figure>\n<\/div>\n

If the right conditions are met, an external piece of JavaScript is loaded from thatispersonal[.]com<\/em>, a domain registered with REGISTRAR OF DOMAIN NAMES REG.RU LLC and hosted in Russia.<\/p>\n

It’s worth noting that directly browsing to this URL without the correct referer (one of the hacked Magento sites) will return a decoy script instead. The complete script is largely obfuscated and creates the iframe-box we saw above for harvesting credit card details at the right place on screen.<\/p>\n

\n
\"\"<\/a>
The rogue, previously non-existent credit card fields<\/figcaption><\/figure>\n<\/div>\n

It also loads another long and yet again obfuscated script ([hackedsite]_iframe.js<\/em>) where “hackedsite” is the name of the e-commerce site that was hacked. Its job is to process, validate, and then exfiltrate the user data.<\/p>\n

\n
\"\"<\/a>
A familiar sight, with data elements to be scraped and exiltrated<\/figcaption><\/figure>\n<\/div>\n

That data is sent via a POST request to the same malicious domain in a custom encoded format.<\/p>\n

\n
\"\"<\/a>
The network request that exfiltrates the stolen data<\/figcaption><\/figure>\n<\/div>\n

The diversity of skimmers and attacks<\/h3>\n

This particular skimmer evolved slightly over time and wasn’t always used for the rogue iframe technique. Historical scans archived on urlscan.io show some changes with obfuscation going from a hex encoded array<\/a> to string manipulation<\/a> using split and join methods.<\/p>\n

Criminals have many different ways of stealing data from online shoppers with web skimmers. While supply-chain attacks are the most damaging because they usually affect a larger number of stores, they are also more difficult to pull off.<\/p>\n

Compromising vulnerable e-commerce sites via automated attacks is the most common approach. Once the skimmer is injected into the payment page, it can steal any data that is entered and immediately send it to the crooks. As we have seen in this article, even e-commerce sites that do not collect payment data themselves can be affected when the attackers inject previously non-existent credit card fields into the checkout page.<\/p>\n

For online shoppers, this trick will be difficult to spot early on and perhaps only after being prompted for the same information again will they become suspicious.<\/p>\n

While it is important for e-commerce sites to get remediated in order to prevent further theft, we know this process can be delayed for one reason or another. This is why we focus on the exfiltration gates to protect our customers in the event that they happen to be shopping on a compromised store.<\/p>\n

Further reading<\/h3>\n