Learning from the Unfolding Log4j Emergency – InApps 2022

The infosec world has been “all hands on deck” dealing with the Log4j vulnerability in the ubiquitous Log4j Java-based open source logging framework. This vulnerability, listed under CVE-2021-44228 last week, was released with a score of 10 out of 10 in the common vulnerability scoring system (CVSS), which is why it’s being treated like the emergency it is.

The vulnerability takes advantage of a newly discovered flaw that renders some versions of Log4j capable of executing arbitrary text through the LDAP directory lookup protocol, which does not require authentication. This means that the Log4j_2 vulnerability, also called Log4jShell, allows attackers to perform remote code execution to deploy ransomware, remote access trojans, and web shells on vulnerable systems.

Since the vulnerability was first reported last week, more than 1.8 million attacks have been launched. Security companies’ telemetry reports show that attackers, including nation-state actors, have already targeted half of all corporate global networks using at least 70 distinct malware families. There are vibrant discussions taking place on Twitter, in forums, and in group chats around the world, which is helping foment continued interest in the vulnerability. These discussions are also propelling research about how to mitigate not just this problem, but future problems like this one.

There are DevSecOps and AppSec protocols that can help you protect your organization from this unfolding Log4j_2 crisis and others like it. Here are six mitigations you should be taking to build more robust defense-in-depth and AppSec protocols to protect your organization from these threats.

1. Vulnerability notification. You can’t fix a vulnerability you don’t know about, so implementing automated alert systems can minimize the lead time from vulnerability discovery to that information propagating to your teams. This will help you maximize your ability to respond and identify which applications utilize the problem component. Using a robust software composition analysis (SCA) solution like Black Duck, which sends real-time alerts directly to developers or product owners based on the items in their software Bill of Materials (SBOM), will streamline your ability to recover.
2. Susceptibility to exploitation: input and output validation. Successful exploitation of the Log4j_2 vulnerability means that you’ve ignored several secure coding principles. Data from untrusted sources (i.e., user-controlled input) should generally not be concatenated into log files without sanitization. This is especially true when the data is from an unauthenticated origin, whether human users or other applications. Data flowing into sensitive areas such as databases and logs that may be rendered to others should be subjected to output validation. Not doing so is a log injection vulnerability in itself, which has long been known and categorized as CWE 117, as well as being described in the CERT Java coding rules. Your first line of defense is making sure your applications are free from these kinds of flaws.
3. Network architecture and network-level access controls. Successful exploitation of the Log4j_2 vulnerability requires that an attacker can transfer a payload to or exfiltrate data from an external system. This might include transferring code to execute a shell, or to launch cryptomining malware. Initiating communication with outside hosts should always be locked down to the bare minimum. Guidelines from the Center for Internet Security (CIS) cover this, as do many other control frameworks including MITRE ATT&CK, which has a whole category of mitigations in M1037 covering network filtering. For client-side applications, using sandboxing technology — even if only the built-in OS and JVM functionality — could further mitigate the range of exploitation paths available.
4. Application architectural risk. Defensive programming techniques, deployed appropriately can help you avoid a worst-case scenario in which unauthenticated external users access application elements that must be exposed for the application to function. A well-designed application should lock down server-side input filtering to limit the accepted data to only those types and range values that are expected. Why does your login page need to allow $ and { characters anyway? Although it might make sense for free-text search fields to allow a wide range of characters, you should eliminate the propagation of sensitive data such as passwords into logs throughout your architecture. Interactive analysis tools can help you visualize the application dataflow — including across application and microservices boundaries — so you can find out what data needs to go where and make sure appropriate filtering exists.
5. Logging, monitoring, and anomaly detection. No, this isn’t irony. Anomaly detection routines should spot when an application does something unusual like attempting to connect to an inappropriate host, or launching processes, or accessing files that it doesn’t usually interact with. There is a long list of layers of defensive and detective controls that can be configured as part of a sandbox environment to make real-world exploitation practically impossible. Or, if an exploitation does occur, these controls can show what was accessed and support the breach investigation team in determining the true business impact.
6. Software component transparency, vendor management, and mature open source adoption. One reason the Log4j_2 vulnerability has been so critical is that it’s a perfect example of the ubiquitous risk of software that we did not develop ourselves, including software embedded in products we use every day. This is why you should have an accurate SBOM — to streamline response and investigation by identifying exactly where a component like Log4j is used, and which products or vendors you to engage with for remediation. Mature management of open source code is a big part of this cyber wildfire as well. As Tim Mackey, principal security strategist at Synopsys Cybersecurity Research Center (CyRC), likes to say, “There is no such vendor as open source.” In the case of Log4j, it appears that the library was still actively maintained and supported as part of a broader community initiative via the Apache Foundation. But many libraries are developed without the support of specific groups or even dedicated individuals, and are later abandoned or forgotten. Knowing the provenance of your open source components, including their level of community support, provides an indicator of where you might be vulnerable to this kind of latent risk.

No one wants to gloss over the efforts of all the teams out there working around the clock right now to patch the Log4j_2 vulnerabilities across the network, but it’s important to remember that the problem is not this particular hack. Every attack, from the infamous Heartbleed to the recently disclosed Trojan Source, is a learning opportunity for AppSec.

The early lessons from Log4j_2 indicate that security principles are key to handling these high-risk software supply chain security incidents. This incident is one more in a long line of supply chain attacks, and the nature of today’s globally interconnected software supply chain means vulnerable software components are likely going to be a recurring threat for the foreseeable future. For organizations to achieve success, a range of security activities must be woven into the culture of how IT systems are planned, constructed, and operated.

Feature image via Pexels.