Digital Skimming and Magecart

Misconfiguration Errors Are A Magecart Delight

by

As Originally published in Forbes

Magecart Attacks & Digital Skimming

Ido Safruti is the Founder and CTO at PerimeterX, a provider of behavior-based threat protection for the web, cloud and mobile.

Harried SREs and DevOps teams are tasked with managing increasingly complex web applications. This means, more and more, a growing thicket of cloud services, third-party software and third-party libraries, all of which must be configured or managed to some degree. So it's no surprise that Verizon's 2020 DBIR highlighted misconfiguration errors as the fastest-growing source of data breaches.

This trend has been duly noted by multiple Magecart gangs, in particular with regard to Amazon S3 storage buckets. In truth, though, S3 is but one of many types of shared resources that Magecart gangs could potentially target in future attacks. More broadly, shared resources within an organization are becoming premium targets for bad actors seeking to do damage to more than one web application and leverage internal efficiency efforts at app companies for broader economies of scale in Magecart attacks. These attacks on shared resources can scale widely (some of the S3 attacks have been "spray and pray") and result in millions of dollars in damages per instance of compromise.

Why Magecart Gangs Target S3 And Other Common Services

Magecart gangs are a loose collection of malicious hacker groups that compromise front-end code on websites and insert malicious code specifically to skim valuable and sensitive data from site visitors (also called formjacking). That data could be credit card or bank account numbers, or it could be email and password combinations. Magecart includes two types of attacks. The first is by directly altering code on a website or cloud service that provides code to a website. The second is by attacking third-party JavaScript libraries and services that website operators embed on their websites to add functionality.

The name "Magecart" originates from the first attacks of this type, perpetrated against the Magento e-commerce platform, but Magecart attacks are no longer limited to Magento.

Magecart attacks may insert fields into a page that were not originally there or may even inject fake iframes in place of iframes from PCI-compliant payment providers. Website owners usually don't realize their site code has been changed until the damage is done. Already on the rise before the pandemic, Magecart attackers have stepped up efforts as more and more of the world has moved economic activities online.

During March 2020, when e-commerce spiked due to Covid-19 and stay-at-home orders, Magecart watchers observed a 30% growth in the volume of attacks. Over the last year, poorly secured and misconfigured Amazon S3 storage buckets have become a Magecart focal point.

While Amazon provides security for S3 buckets by default, maintaining properly configured storage for buckets accessed by multiple domains is challenging. S3 buckets are favored Magecart targets because they allow hackers to insert malicious code into a trusted environment that often undergoes little scrutiny. Websites use these trusted buckets to pull in commonly used JavaScript. This common usage makes it easier for DevOps teams by allowing them to update and maintain capabilities across multiple web applications from a single S3 bucket, The dark side is that this same shared usage model allows Magecarters to compromise one bucket yet spread their attack to multiple web properties, skimming data from a greater number of unsuspecting customers.

All External Services Requires Proper Configuration

Misconfigured S3 buckets are only one of the ways that e-commerce operators and website owners are exposing their front-end code to growing risks of shared services. Magecart gangs have also mimicked domains from other popular external services, including prominent CDNs. Similar to sharing S3, operators of multiple sites often share the same CDN networks and expose their sites to the same vulnerabilities.

Sometimes the risk comes from failing to upgrade to a newer version of outdated software. Adobe, the owner of Magento, announced months ago that it would stop supporting patching and security updates for the 1.x versions of the shopping site package. As of late June 2020, over 100,000 sites were still using those early versions of Magento. This kicked off a series of stern warnings from Adobe, Visa and Mastercard that those site owners needed to migrate ASAP or risk falling out of compliance with PCI DSS standards that are required to process transactions through the networks.

Assume Misconfigurations Will Happen And Monitor For Anomalies

The reality is that nearly all websites rely heavily on cloud services and third-party services or libraries. Almost any external service, such as Amazon S3, that allows direct access to front-end code requires some degree of configuration. What's more, almost any third-party service or library not controlled by a website operations team still requires proper configuration by the company that runs that service. The growing complexity of the front-end landscape almost guarantees that misconfiguration problems will continue to grow.

The best solution, then, is a two-pronged approach. SREs and website operations teams should minimize the human factor by adopting DevOps and infrastructure-as-code concepts that make website code and service changes programmatic, versioned and tightly monitored for unauthorized changes. In parallel, security teams for websites should deploy technology that can monitor front-end code for anomalous behavior indicative of exploits that result from misconfigurations.

Looking for anomalies assumes the inevitable — code compromises will happen. Rather than focus on finding the compromise, advanced analysis of behavior patterns of website code can spot the injected unauthorized form, the iframe that behaves a little differently or the sites pulling JavaScript from S3 buckets that began to skim user information.

A few steps readers could take when it comes to currently preparing for a transition to an automated code analysis system include:

  • Integrating the testing or analysis to your build and deploy tools. Some of the commercial tools come with "out-of-the-box" integrations to your code management system and to your CI/CD tools.
  • Integrating the tools to your development processes. For example, if you manage your tasks on Jira, build integration to create a Jira ticket to the relevant developer when a test fails.
  • Looking for solutions that monitor and can analyze the application in run-time, as web applications' dependency and third-party code may change after you deployed it and as new vulnerabilities may be discovered after you deployed your code.

Even the best web teams will misconfigure something in such a complex code environment. The smartest security is to minimize this reliance on human perfection and automate detection by letting machines do what they do best — use machine learning to spot patterns and antipatterns that human eyes cannot readily recognize.

PerimeterX is Named as a Leader in Bot Manangement by Forrester

Download Report
© PerimeterX, Inc. All rights reserved.