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.