Application Protection Report 2019, Episode 3: Web Injection Attacks Get Meaner

Introduction

F5 Labs published the first annual Application Protection Report in July 2018. For 2019, we are releasing our conclusions in shorter pieces that focus on specific trends and conclusions instead of a single 100-page report released late in the summer. Over the last few weeks we have published our first episode, which is focused on PHP reconnaissance campaigns, and our second, which is focused on public data breach reports and industry breach trends.

For the third episode we are diving into the details of one of the big patterns in the breach trends we identified in the previous episode. Not to give away the ending, but that old vulnerability type, injection, has taken on new significance as a result of accelerating trends in how web sites are constructed. We unpack the trends, link it to new data, and offer tactics for mitigating this new-old risk. But first, to place it all in context, we need to revisit some big-picture questions.

Again, We Ask: What Is an App?

One of the definitive questions we asked in 2018 was: what, really, is an app? We offered a new way of thinking about an application so you could monitor and protect them better. This year, the data revealed trends that cast this question into even sharper focus.

To the user, an application may appear to be a single thing: a program running on a server somewhere with a user interface. In reality, most applications on the Internet are swarms of microservices and sub-applications all converging at the last minute into a coherent user experience. These embedded services can include things like user analytics, chat features, debugging tools, social media sharing capabilities, advertising, and enhanced animation. Increasingly, these microservices are being linked to and run from external third-party sites. In other words, the active web code is running on a server that has nothing to do with the “primary” application.

While the pace of this trend is accelerating, microservices and sub-applications are not actually a new thing. At the 2014 RSA Conference keynote, noted security researcher Dan Geer said, "While writing this, the top level page from cnn.com had 400 out-references to 85 unique domains, each of which is likely to be similarly constructed and all of which move data one way or another."¹ By 2016, researchers at University of Illinois, Urbana Champagne found that 64% of website resources were loaded from an external domain.² In 2019, a simple scan of the F5 main web page reveals 70 external domain references.³

This tendency to assemble distributed content and functions at the browser is, in itself, not a bad thing. It saves server bandwidth and processing while freeing developers from having to reinvent wheels. It also, however, broadens the attack surface for that old and venerable vulnerability classification, injection. For that reason, we will revisit what makes injection such a durable flaw, and why its latest incarnation makes third-party content such a significant problem.

Injection Still?

Traditionally, when tech people hear about web injection, they think of SQL injection, which is a common form, but is far from the whole picture. Injection is a broad category of attacks that can manifest differently depending on the context. These attacks occur when an attacker secretly adds, or injects, their own instructions into an existing authorized application execution process. Injection can sit almost anywhere in an attack chain, from the initial contact with the target to the final exploit.⁴ It is often used as a way to circumvent authentication,⁵ but there are also many injection exploits that depend on the attacker already being authenticated.⁶ The insertion point for the payload can be at the server level,⁷ the web application itself,⁸ or, as we are seeing more and more, in third-party application modules or content (more on this below).⁹  In some cases, the injected code resides in a Content Delivery Network (CDN).¹⁰ It also is feasible to do a man-in-the-middle injection into a CDN.¹¹

The goal of the injection payload can vary widely, as well. Some injection exploits allow attackers to execute commands within the operating system (OS).¹ Some are used to circumvent authentication, as we mentioned earlier.² Some inject code, such as malware, or other objects, including code for escalation of privilege.³

A subtype of injection vulnerability that warrants a specific mention is file inclusion, in which an attacker injects a path to malicious files, either local or remote, that the server processes at runtime.⁴ In these cases, only a few lines of code need to be injected since the majority of the exploit runs away from the victimized server. And, while we generally treat cross-site scripting (XSS) vulnerabilities as separate because they exist in a specific context, they are also a form of injection in which the injection payload is a step to compromising another visitor to the site, not the site itself.

However, the most impactful form of injection at the moment is known as formjacking. A formjacking attack siphons information that users put into online forms such as login screens or payment forms and delivers it to a location under the attacker’s control. Most of the time the information sought by attackers is login credentials or financial information such as payment card numbers.

Formjacking is not a new type of attack, but it has exploded in popularity over the last two years, primarily in the form of Magecart attacks. The name Magecart originally stems from a name collectively assigned to the different threat actor groups who carried out the initial exploits of a shopping cart vulnerability on the Magento ecommerce platform (Magento + Shopping Cart = Magecart).¹ These exploits, which vary subtly over time and from group to group, mostly rely on a vulnerability in Magento, which runs on PHP. The vulnerability itself boils down to an inherent flaw in PHP’s unserialize() function that allows attackers to inject PHP objects, including executing arbitrary PHP code for formjacking.² And as we noted in episode 1 of this report, PHP is highly targeted by attackers.

In 2018 we reported that of the breaches we analyzed that were based on web attacks (as opposed to phishing or other vectors), 70% were formjacking injections of malicious code on websites for payment card theft—primarily shopping carts. We predicted that formjacking attacks against ecommerce platforms would endure, as they are hard to detect and have proven profitable. For the 2019 report, we examined 760 breach reports and found that formjacking payment cards remains one of the most common breach types and was responsible for 71% of web breaches and 12% of known breaches in total.

New Software Supply Chain, Old Attacks

As alarming as these numbers are for our industry, they only hint at a deeper problem. As webpages pull content from increasingly disparate and nebulous sources, we’re seeing more content getting injected in the browser from third-party add-ons. These exploited third-party tools run in the same computing context as the main web application and its sensitive content, like payment input fields. Compared with other types of injection, this has some significant advantages for attackers, which are illustrated by the 2017 breach of [24]7.ai, a customer experience software and services company.

In autumn 2017, a number of large enterprises, including Delta Airlines, Sears, Kmart, and Best Buy experienced coordinated breaches of customer financial information. The total number of exposed records is thought to number in the hundreds of thousands. The source of the breach was an unspecified piece of malware that was delivered to the target sites through a compromised customer service chatbot module created by [24]7.ai, one of the industry leaders in customer service automation tools.

Even though this attack is outside of the timeframe of this report, it encapsulates many of the factors that make it difficult to prevent formjacking today:

Visibility: Standard web application firewalls (WAFs) protect the primary site by examining traffic between the client and the app server. Third-party scripts, however, are loaded directly by the client browser, completely bypassing perimeter security controls. The WAF may see that a script, such as an advertisement loaded from an ad network, is included as part of the app page, but it will not see the contents of that script. Traditional security tooling will view it as completely legitimate. Furthermore, sites that deliver malware or receive skimmed financial information tend to have legitimate encryption certificates on look-alike domains. In the case of [24]7.ai, the target enterprises almost certainly had no indication from their own network monitoring surfaces. We know that they were notified by [24]7.ai, the third-party service provider, about the breach, not the other way around. 

Targeting: As more web applications outsource critical functions such as ecommerce, the vendors become an outsized target, specifically because their code is called by such a wide range of customers. Attackers know that if they compromise a single vendor for a microservice, they stand to skim data from a huge pool of potential victims, often across multiple industries. This acts as a force multiplier for attackers.

What the Data Say

The 2018 breach data that we have examined for the 2019 report revealed 83 breaches attributable to formjacking attacks on web payment forms. The total number of payment cards compromised in these attacks was 1,396,969. In terms of number of breaches, nearly half of these came from the retail industry. However, in terms of number of breached records, the transportation industry, including companies like Delta Airlines, British Airways, and Amtrak, are responsible for 60% of the breached payment cards.

Here’s how the formjacking injection breach data broke down by industry, as a percentage of all of the formjacking breaches (and ignoring number of records compromised in each breach):

The lesson is clear: for any organization that accepts payment cards via the web, their shopping cart is a target for cyber-criminals. Furthermore, formjacking has emerged as a reliable technique for extracting high value data like financial information specifically because of the decentralization trend in web content and services.

Injection Detection

Injection vulnerabilities can be detected during development but are more difficult to detect in deployed systems. Because injection flaws can be exploited in any stage of an attack, finding and evaluating their impact depends on context. Often attackers use lower-priority vulnerabilities such as cross site scripting (XSS) to gain an initial foothold to inject malicious JavaScript into a website.¹ In other cases, attackers can inject PHP commands into an application API or server-side applet, such as the case with Magento and the Magecart campaign.²

As we mentioned above, the risk of these kinds of attacks is magnified when the target web application uses third-party code running offsite. It is more difficult to detect changes to third-party code, harder to allowlist source IP addresses for content, and given the growth in malicious use of encryption, harder to inspect traffic.

Many sites, even high-profile ones that receive a huge amount of traffic, link to scripts posted directly in Amazon S3 buckets or other cloud storage solutions. With the huge number of S3 buckets that are deliberately configured to have weak or no authentication, this poses another significant risk: tampering of scripts hosted directly within a bucket would lead to compromise of every site that linked to that script. This is a similar campaign strategy to the one we explored above with the [24]7.ai campaign. The growing use of third-party content also means that attackers can exploit vulnerabilities across their targets’ customer lists to achieve a huge impact overnight.

Conclusion

Injection vulnerabilities are not new and mitigating them is theoretically simple. However, their enduring prevalence is not just because of the lag in mitigating or preventing these well-known flaws, or new, inexperienced developers recreating known issues in PHP. Instead, injection remains such a problem because new trends are opening up new forms of risk. Availability of published attack scripts, which can be easily added to hacking tools or malware, is a dominant predictor for future attacks³. So, looking at the Exploit-DB published exploits for 2018, we see that 11% were usable some part of a formjacking attack.
 

In other words, the injection landscape is not just sticking around, it is transforming along with our behavior. Detecting and mitigating injection flaws in light of these trends depends on adapting our assessments and controls to this new reality, not just fixing code.

Mitigating Injection Risks Today

We hope it’s clear by now that injection is a tricky devil. While no checklist will ever be enough on its own to control against such a mutable attack type, this will at least get you off on the right foot.

Inventory. As always, a proper inventory is a cornerstone of managing risk. Conducting an inventory of web applications in your environment with a specific focus on auditing for third-party content will tell you about your supply chain attack surface (at least with respect to software). This, however, can be extremely complex when the providers of our script libraries, advertising, and our resources will themselves link to yet more third parties. Also, consider that some of these third parties, such as web widgets or user trackers, will have a lower security stance than your average ecommerce site, which must meet PCI DSS standards.

Patching. Patching your environment is also a critical part of managing risk as things change. While patching won’t necessarily fix the flaws in third-party content that present the newest form of risk, it will make it harder to escalate from an initial foothold into a substantive compromise. Since injection is such a versatile technique, patching applications running in your own environment is still absolutely critical to preventing escalation from a compromised third-party asset.

Scanning. Similarly, vulnerability scanning not only remains important, but takes on a new dimension. Many CISOs have recognized for years that it is important to run external scans in addition to internal ones to get the “hacker’s eye view.”⁴ The fact that so much content is being assembled at the last minute now at the client side makes this even more important.

Change Control. Monitoring for code changes on the site, regardless of where that code is hosted, will provide an added degree of visibility irrespective of whether new vulnerabilities are emerging. This means monitoring GitHub and AWS S3 buckets as well as native code repositories.

Multifactor Authentication. Given that injection is so often used to bypass authentication to gain access to web server code, multifactor authentication should be implemented on any system that can connect to high-impact assets. Ideally, application-layer encryption can also supplement TLS/SSL to maintain confidentiality at the browser level. Many well-known web application firewall (WAF) products have this capability.

Web Application Firewalls. More broadly, modern WAFs will provide greater control over who connects to your systems, how they connect, and how their user input is protected. While technology is rarely a simple solution, and a firewall is only as good as the team that sets it up, modern WAFs offer a level of application-layer visibility and control that can help mitigate the distributed and polymorphic risk that injection presents.

Server Tools. There are also a number of server software tools at your disposal. You can set up a Content Security Policy (CSP) to block unauthorized code injections into a website or application.⁵ On top of that, you can add Subresource Integrity (SRI) web methods to verify that those third-party apps have not been altered.⁶ Both of these tools require some work to properly fit to a web application.⁷ This is where a good, flexible WAF can help.

Monitoring: Monitor for newly registered domains and certificates that include your brand name. These are often used to host malicious scripts while appearing genuine to end users.⁸

The Future of Injection and Decentralized Web Content

Over time, as new risks emerge from changing technology and the arms race that is information security, we gradually incorporate those risks into our business models. Cloud computing has gradually shifted from a perceived bleeding-edge risk to a cornerstone of modern infrastructure. The risks associated with the cloud have either been mitigated or displaced to contractual risk in the form of service level agreements and audits. In other words, as the business world comes to grips with new trends in service provision, risks gradually morph from purely technical exploits that are managed reactively to facets of a business model that are managed proactively.

We predict that the same will happen with the trend of third-party web functions and content. Organizations will begin to manage this risk in the form of security-oriented service level agreements. The mitigations we have suggested above are the beginning, an initial bulwark as the industry comes to terms with new trends. But as we digest the ramifications of this latest manifestation of the web, the management of these new risks will mature. Doubtless, injection will morph as well, and find new ways to trouble us. In the meantime, we hope that the perspective and practices above assist in managing the latest incarnations of these old risks.