The attack group known as Magecart has stolen customer information and payment details from websites big and small—high-value brands as well as niche players—over the past few months. The group is continually refining and tweaking its attack methods, and its list of victims continues to grow.
Magecart, a group RiskIQ has been tracking since 2015, steals payment card information from websites by injecting card skimming code into a script or a form running on the targeted victim’s website. The shopper would enter the payment details, including name, address, and card information onto the website’s payment page, and Magecart’s malicious code would copy that information and send it to a different server under the group’s control. The checkout process proceeds normally, completes successfully, and the shopper has no idea the card details have been skimmed.
“They [Magecart] also appear to be optimizing the code used on these [victim] sites, minimizing the footprint left on the compromised domains,” researchers from Volexity’s threat research team wrote in a blog post regarding Magecart’s latest activities. “This type of refinement is sure to continue as new organizations are targeted.”
Over the past few months, Magecart has successfully skimmed payment card details from TicketMaster UK, British Airways, Philippines-based entertainment and media conglomerate ABS-CBN, and online electronics retailer Newegg. The group is getting more efficient and sophisticated with each attack. The attack code used against British Airways was 22 lines long, while the attack code used a month later against Newegg was just 15 lines.
Major websites have suffered serious breaches, not because they were hacked, but because of a compromise in a 3rd party dependency.
“RiskIQ’s automatic detections of instances of Magecart breaches pings us almost hourly,” said Yonathan Klijnsma, head of threat research at RiskIQ. “Meanwhile, we’re seeing attackers evolve and improve over time, setting their sights on breaches of large brands.”
Poisoning the Supply
Much of Magecart’s previous attacks focused on compromising third-party providers. The group would inject its malicious code into libraries and scripts provided by third-party providers, thus ensuring that any website using that provider’s code would be executing the attack code. For example, Magecart has targeted websites running outdated and unpatched versions of Magento, an open-source ecommerce platform written in PHP. Recent figures suggest that over 7,300 stores have been affected by the MagentoCore card skimming code.
TicketMaster UK was using a popular chat widget called Inbenta, an AI-powered widget for live chats, on many of its pages, including the payments page. Magecart’s attack code was able to collect all the information entered on the page while the chat window was open. RiskIQ said Magecart has breached other third-party providers, including SocialPlus, PushAssist, and Annex Cloud. Pictures posted by ZDNet’s Catalin Cimpanu on Twitter, indicate that discount department store chain Stein Mart and sports apparel retailer Title Nine became Magecart victims via Annex Cloud, a service that lets users log in to merchant websites with their credentials from other sites (such as Facebook and Amazon).
“Major websites have suffered serious breaches, not because they were hacked, but because of a compromise in a 3rd party dependency,” security researcher Scott Helme wrote in a blog post.
Just a few weeks ago, Magecart targeted Feedify, a cloud platform providing websites with a JavaScript script to add behavioral targeting capabilities to their sites. Magecart injected its attack code into one of Feedify’s libraries so that the attack code would loaded whenever customers loaded the Feedify script. By compromising Feedify’s supply chain—in this case, the library—Magecart was able to potentially target every Feedify customer.
What was egregious about the Feedify incident was that even after the developers removed the offending code from the library, Magecart was able to repeatedly inject the code back into the same script. While the actual number of affected Feedify customers remain unknown, RiskIQ saw about 500 websites using parts of Feedify, and at least 174 sites that may have been impacted during the timeframe the attack code was active.
The attackers had “some kind of write-access to the Feedify server in order to be able to modify the script on disk,” Klijnsma said.
RiskIQ’s automatic detections of instances of Magecart breaches pings us almost hourly.
Third-party code was the problem in all the above cases, so it seems logical to suggest that websites should be writing and hosting their own code. That advice misses the nature of modern web development, which relies on assembling code components from different sources. It isn’t practical to ask developers to write every functionality from scratch.
“Advice like that, which technically solves the problem, but has absolutely no chance of being followed isn't really good advice,” Helme warned.
Instead of throwing out third-party code, which is just not going to happen, Helme recommends defining the website’s content-security-policy (CSP) and verifying files with Subresource Integrity (SRI).
CSP lets website owners define a list of locations that resources can be loaded from. If the CSP says the only scripts allowed to be loaded are the ones on the domain and from the payment processor, then any attempt to load a script from a different domain would automatically fail. With SRI, website owners put a hash of the file being loaded from a third-party source in the script tag. When that file is being loaded, the browser can compare that file’s hash to what is in the tag to verify the file has not been tampered with. If the hashes don’t match, the browser blocks that file from loading.
“These steps don't necessarily need to be applied to your entire website, perhaps just really sensitive pages like those that accept credit card / bank details and your login form,” Helme said.
Website owners should also make sure that they are keeping third-party code applications updated since many of these code injects exploit vulnerable versions of the application.
An Active Threat
Magecart changed tactics against British Airways and Newegg. Instead of targeting a provider, the group injected malicious code directly into the sites’ own payment pages. With Newegg, Magecart dropped the skimming code into an ASP.NET page that was loaded as part of the site’s checkout process. The attack code waited for the payment button to be clicked (by the mouse) or tapped (on the touch screen), and then converted the contents of the form before uploading the data to a domain controlled by the group.
“The skimmer was put on the payment processing page itself, not in a script, so it would not show unless the payment page was hit,” RiskIQ researchers said. The customer would hit that page only if there was something in the shopping cart and had already entered a validated address.
Helme noted that using SRI on the site’s own assets don’t really make sense. However, an organization the size of British Airways likely has different teams hosting, operating, and maintaining different applications. If they’re different applications, SRI could still contain the compromise, since the compromise of the CMS application wouldn’t have affected the application that was handling the credit cards, Helme said.
“Taking a 'zero trust' stance, even on assets loaded from somewhere that you might control, is certainly going to help limit, or even remove, the impact of an attack like this,” Helme said.
RiskIQ’s Klijnsma also posted a suggestion on Twitter about making it harder for scripts to steal payment details. “Randomize the form and input field names/IDs. Map them back using session information on your server when you process checkout,” Klijnsma wrote.
This type of refinement is sure to continue as new organizations are targeted.
None of the published research about Magecart has identified how exactly the group is getting access to inject its attack code. There might be a clue in a recently-publicized underground Russian-speaking forum MagBo, which sells access to over 3,000 websites. While there are plenty of online forums that sell access to websites, Flashpoint found that MagBo specializes in web shells to already hacked sites. Buyers can gain access to websites that were breached via “PHP shell access, hosting control access, domain control access, File Transfer Protocol (FTP) access, Secure Socket Shell (SSH) access, admin panel access, [and] database or Structured Query Language (SQL) access,” wrote Vitali Kremez, director of research at Flashpoint. MagBo also labels the different types of access available, such as with labels such as “full access permissions,” “abilities to edit content,” and “add your content.”
While Flashpoint didn’t find definite evidence showing that Magecart bought access to sites from MagBo, there is a strong possibility the group got its access through this—or similar—forum. Magecart “likely required compromised access and the ability to manipulate site content and inject code in order to steal customer data,” Kremez wrote in reference to the attack on British Airways.
RiskIQ believes Magecart has split into three sub-groups with distinct areas of focus. The group as a whole should be considered as an active threat, and the sub-groups will continue their operations.
“[They] have continually refined their tactics and targets to maximize the return on their efforts,” Klinjsma said.
Header image from RiskIQ
