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
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.
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.
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.