E-Commerce Skimming Attacks Evolve Into iFrame InjectionFinding Shows Risk To Sites That Use External Payment Processors
Criminal gangs have been hitting e-commerce sites hard lately by injecting their malicious code to "skim" customers' payment card details.
Security firm RiskIQ says it's tracking more than a half-dozen groups that employ "digital skimmer" attack techniques that it classifies as being "Magecart." Such groups typically target Magento e-commerce software and plant malicious code inside victims' websites (see New Skimmer Attack Steals Data From Over 100 E-Commerce Sites).
Magecart groups' code can be stealthy: Consumers may never be aware that their payment card details have been compromised via a legitimate site. Oftentimes, breached e-commerce sites don't discover that they've been hacked, but rather get notified by security firms such as RiskIQ, which continually conduct internet-wide scans, looking for sites that display known signs of Magecart attacks.
Recently, Malwarebytes has spotted a new twist in attackers' skimming tactics. In one case, attackers infected an e-commerce site with code that causes it to pop up a malicious iFrame at payment time.
The use of injected overlays is nothing new in either skimming or phishing attacks, says Jérôme Segura, a Malwarebytes security researcher. But it poses a special risk for any e-commerce site that may think it's better isolated against Magecart attacks thanks to using an external payment service provider, or PSP.
"To me the main takeaway was that even sites that do not take payment themselves can still be abused with those tricks," Segura tells ISMG. "It really shows that any e-commerce site is fair game."
Data Goes to Russia
Malwarebytes didn't name which Magento-powered e-commerce site got hit by the iFrame attack, although Segura says it is a clothing portal that serves the Asia-Pacific region.
He says that when users of the site come to the payment screen, the iFrame suddenly gets injected into the page. Normally, however, a person would be redirected to the PSP.
"What we notice are new fields to enter credit card data that did not exist on the left (untampered form)," Segura writes in a blog post. By itself, this may not be out of the ordinary since online merchants do use such forms - including iFrame - as part of their checkout pages."
Essentially, the iFrame jumps ahead in line. Although all PHP pages within the e-commerce site were infected, Segura says that the iFrame would only be triggered "if the current URL in the address bar is the shopping cart checkout page (onestepcheckout)." Apparently to help the malicious code avoid detection, "some extra checks (screen dimensions and presence of a web debugger) are also performed before continuing."
Finally, after that occurs, the user does get directed to the proper PSP, where they can pay.
Hiding in Plain Sight
Last November, RiskIQ published a joint report with Flashpoint that covered a variety of Magecart actors, including group 4, which had developed an extensive infrastructure for skimming payment cards.
Magecart 4 is also notable for its ability to "[blend] in with its victims' sites to hide in plain sight and employs methods to avoid detection," RiskIQ says.
Now, by using an iFrame, the attackers can capture payment card data before the customer is directed to the PSP.
But Klijnsma says the attack was a bit clunky. "The skimmer here puts its own payment form in so the user inserts it," he says. "The funny thing is that this method breaks the checkout process because if you iFrame instead of redirect, the user has to enter payment data twice, which might tip them off."
While this user interface anomaly might raise customers' suspicions, however, by the time they see the second payment screen, their data would already have been compromised.