While the end of 2020 was dominated by Nobelium’s supply chain intrusions, 2021 closes with continued worry and response over vulnerabilities in the widely-deployed Log4j library. Starting in earnest on 10 December 2021 with public disclosure of CVE-2021-44228, information security practitioners and security program managers have subsequently dealt with a sequence of updates and patches to the framework since. Other than the 2.16 patch, which hardens the initial CVE-2021-44228 fix in 2.15 by disabling JNDI by default in Log4j, the following items have been a bit… confusing.
As noted previously, vulnerabilities are meaningless absent satisfying three critical factors:
- An available mechanism for exploiting the vulnerability.
- An opportunity for delivering that mechanism to a vulnerable system.
- An adversary’s intention to deliver that exploit to victims.
Take any of these away, and the scariest “world ending” vulnerability becomes inert. With that in mind, a new vulnerability – CVE-2021-44832 – was issued on 28 December 2021 for an additional vulnerability in Log4j. Prior to, and even after, its disclosure, social media and various information security communication channels lit up with worry and hype over the “latest” issue in Log4j. Yet closer review of the actual issue reveals important details:
“[prior versions of Log4j are] vulnerable to a remote code execution (RCE) attack where an attacker with permission to modify the logging configuration file can construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can execute remote code…”
On its face, this “vulnerability” seems ridiculous. Essentially, an adversary who already possesses the ability to arbitrarily modify files on the victim machine can establish conditions for follow-on RCE. Thinking through the language here, if you already can modify a configuration file (not a log file, like CVE-2021-44228), an intruder has already achieved a level of local privilege escalation (LPE) for a file with (likely) higher-level permissions associated with it along with some means of RCE to make the actual modification. Putting all of this together, the item seems redundant as an adversary would already have achieved the three conditions previously mentioned to even be in position to leverage this latest item.
Having said this, the sheer variety of web applications and janky installations and setups in the world mean that there is a non-zero chance that some application in the world may exist where this is an actual issue. In this case, some mechanism of passing commands to the application that writes the malicious entry to the configuration file could be used to achieve a more robust or thorough RCE over the victim system. In this sense, we could view CVE-2021-44832 exploitation as superficially similar to how Sandworm leveraged Exim vulnerability CVE-2019-10149 to launch a remotely-hosted script to then enable follow-on connectivity via SSH and other mechanisms. Yet given what information exists about the latest Log4j item, the necessary permissions and other controls that must be overcome to allow for successful exploitation seem significant enough such that an existing breach is the only way to consistently satisfy them.
That in mind, system owners and risk evaluators shouldn’t brush off this vulnerability in Log4j 2.17 completely. But, as it stands right now, recalling your IT and security people over what is normally a “down” period (as of this writing, the world is currently between the Christmas and New Year holidays) to scope and patch this item seems a wild overreaction to the actual situation. Instead, apply normal patch evaluation and application cycles for this item at a time of convenience, rather than as an item of immediate necessity.
The above all serves as a cautionary point for handling (and reacting to) software vulnerabilities. Aside from basic questions such as “are we even impacted” that go to the heart of basic security hygiene, such as asset and software application inventories, understanding precisely what a vulnerability means is important in evaluating risk. Theoretically CVSS scores provide a quick mechanism through which to evaluate risk, but as noted by third-party analysis such scores often contain errors for various reasons. Errors aside, a 0-10 scale still fails to properly communicate nuance and context around a vulnerability making this a subpar measure upon which to base subsequent security decisions, such as recalling teams over a weekend or holiday to address an item.
As of this writing, a CVSS score for CVE-2021-44832 is unavailable, yet even when disclosed the unique (and some might argue unrealistic) exploit path for this item is likely not truly represented in the final score. From a risk assessment perspective then, the only appropriate way to respond to items such as this Log4j issue is through reading and understanding the patch in question and the underlying vulnerability it attempts to resolve. Unfortunately, this solution requires not only the time and effort to go through patch notes, but also the expertise and domain awareness to understand them – assuming first off that the vendor or maintainer has written a clear, correct, and understandable patch release to begin with. All of these items holding true, on both user and vendor sides, represents an ideal that is sadly not reflected universally in reality. As a result, decision makers are left in a suboptimal position in assessing and triaging patches, especially on items where significant media or non-expert attention has accreted (such as Log4j, although you could swap that out for SolarWinds at the end of 2020).
Decision support, though, is something that an entire facet of information security revolves around: Cyber Threat Intelligence (CTI). Distilled to its most basic form, CTI should enable either front-line defenders (tactical CTI) or larger scale, longer term risk evaluators (strategic CTI) to make better, more informed decisions. While there is no shortage of CTI efforts to chase the latest arcane knowledge surrounding narrowly-targeted state-sponsored intrusion campaigns or precise identification of some APT entity, vulnerability assessment and analysis is woefully underrepresented outside of a handful of “headline” bugs that everyone must comment on because of their scale and popularity (such as the original Log4j item, CVE-2021-44228).
This state of affairs is unacceptable, and represents an area where security practitioners need to demand more of CTI functions, and CTI elements must put forth greater efforts. If we view the intelligence discipline as covering those actors and capabilities used to hold defended or valued elements at risk, then vulnerability analysis represents a vital piece of the intelligence puzzle: evaluating the environment through which adversaries can or may compromise the defended entity.
In an ideal world, asset owners and decision makers would possess the expertise required to properly vet and understand software vulnerabilities to make sound, risk-based decisions on patching and defense. Absent such a condition, CTI can and should view itself as the appropriate support function for filling in these knowledge gaps. Yet the majority of CTI training and education resources – with some exceptions – ignore vulnerability research and analysis. This seems both short-sighted and deeply unfortunate, as it leaves a critical area of defender support unaddressed.
Moving forward, CTI consumers should demand more of their teams or vendors to provide vital assessment of vulnerabilities that are relevant for the organization, establishing this as an intelligence requirement if necessary. More immediately, security practitioners and IT program managers must work to satisfy this requirement themselves, critically examining vulnerability notes and patch releases to determine just how critical a given item may be, and what the appropriate responses are for purposes of mitigation or outright elimination.
Overall, despite the seemingly endless parade of software vulnerabilities over the past two years, actual understanding and critical assessment of vulnerabilities is sorely lacking. Unless this is addressed, organizations will continue responding in either haphazard or inefficient ways to released items, driven more by hype and perception than cold-eyed analysis and risk evaluation. As an industry, information security must do better to avoid not just suboptimal security outcomes, but to protect our personnel from endlessly responding to items as a never ending sequence of crises thus inducing burnout.
