Addressing Log4Shell

By Zach Matthews - 16 Dec 2021.

Tags:

pci
blog
x

The Log4Jshell vulnerability has sparked an Internet firestorm and may potentially be one of the most devastating bugs in years. But why? Log4shell is a zero-day, supply chain, remote code execution vulnerability that is amongst the most widely used components in use today. Vulnerable components are difficult to trace as Log4j2 has seen industry wide adoption across the entire technology stack. And many threat actors are actively exploiting it.

On December 9th, 2021, a critical severity remote code execution vulnerability in the Apache logging code library “Log4j2”, now described by CVE-2021-44228[1] and dubbed “Log4Shell”, was publicly disclosed on Twitter. Proof-of-concept exploit code posted to GitHub[2] a short time later prompted a surge in exploit attempts and worldwide emergency response.

What is Log4J?

Log4j2, commonly referred to just as Log4j, is an open-source library developed by the Apache foundation to implement logging functionality in Java applications[3]. Due to the library's utility and ease of use, Log4j has become incredibly popular: some experts estimate that millions of applications directly or indirectly use it[4]. Major organizations and open-source projects such as Apple iCloud, Twitter, Amazon, Cloudflare, Elasticsearch, and Apache Struts were reported to have been affected by the vulnerability[5][6].

Response

Out of an abundance of caution, a number of Canadian organizations and institutions have preemptively taken services and websites offline to assess their current security posture in relation to the vulnerability. Organizations which had taken preventative measures include the Canada Revenue Agency as well as the provinces of Quebec and New Brunswick[7][8]. While the global scope and totality of the vulnerability remains unclear, the expedient decision by the Canadian parties mentioned above to interrupt service preemptively highlights the severity of this vulnerability.

JNDI Injection - The Ticking Time-Bomb

The root cause of the vulnerability was discovered in 2016 by Alvaro Muñoz and Oleksandr Mirosh and was presented as research at the Black Hat USA 2016 conference[9][10][11]. The research explored in great detail the underlying mechanisms in the Java Naming and Directory Interface (JNDI) which would allow for remote code execution if an attacker could inject content into a JNDI variable. This vulnerability class was coined as “JNDI Injection”. The presentation also identified several vectors through which an attacker may provide a malicious Java object to obtain remote code execution, including LDAP and RMI, which are currently being used to exploit Log4j2 in the wild.

The key takeaway from the 2016 presentation was a simple recommendation: "Applications should not perform JNDI lookups with untrusted data". Unfortunately, Log4j2 does exactly that. Log4j2 versions 2.0-beta9 <= 2.14.1 are configured to resolve JNDI variables by default. With Log4j2, this type of dangerous variable resolution will happen if any such JNDI variable appears anywhere within a log message parsed by Log4j2. As a result, if an attacker is able to inject a crafted JNDI variable string into an application log file which is parsed through a vulnerable version of Log4j2, it could execute a remotely hosted malicious Java object to obtain remote code execution on server infrastructure underlying the vulnerable applications.

The scope of JNDI variable strings which can induce this behaviour is expanding by the hour. Many applications will log user supplied input from a variety of sources and, as such, exploitation of the vulnerability is frequently trivial and the attack surface for affected applications is all-encompassing.

Mitigations, Work-Arounds, and Bad Actors

Mitigations and patches for the vulnerability have already been released. The most comprehensive course of action is to update Log4j2 to 2.16.0, which represents the most current version at the time of this blog post. If an organization moves to patch and already finds the appropriate patch for Log4j2 installed, it should be ensured that the update was implemented internally or by a vendor or other authorized third party, and that attackers or threat actors did not implement the patch as a post-compromise activity. Threat actors and botnets alike have been known to exploit vulnerabilities, establish persistence, and then patch the vulnerability so that other threat actors and malware cannot establish similar footholds, reducing competition.

For some applications, updating immediately may not be feasible: in this case, popular guidance is to modify the Log4j2 configuration parameter "formatMsgNoLookups" to have a value of "true", but this mitigation does not prevent all vulnerabilities. The only way to truly protect your organization for Log4j2 exploits is to upgrade to version 2.16.0.

Lunasec was one of the first organizations to release a comprehensive blog post on the Log4Shell vulnerability along with mitigation guidance. Lunasec have also built a set of utilities for assessing your exposure to Log4j, including identifying vulnerable instances and Java classes that depend on Log4j [12]. Numerous Log4j exploitation detection scripts have also emerged over the past week, including an easy-to-use PowerShell script by Datto, an MSP [13], and a collection of quick, but not comprehensive commands, scripts, and rules by the GitHub user Neo23x0 [14].

Organizations seeking to assess their exposure to “Log4Shell” should establish a well-defined application inventory which includes first and third-party components or dependencies. The entirety of this inventory should be scrutinized to determine if Log4j2 is being leveraged for logging in any capacity, at any level within the technology stack. Organizations should monitor applicable vendor communications in relation to this vulnerability and act on vendor advisories which may require remedial action. Security testing to identify JNDI injection should be included as part of a comprehensive vulnerability management program.

Log4j and Control Gap

Control Gap has already performed these self assessment steps and determined that we are unaffected by all Log4j2 vulnerabilities disclosed in the past week. As all organizations should, we will continue to monitor the situation for further developments.

If you or your organization requires incident response services in relation to Log4j incidents or comprehensive guidance on navigating this vulnerability and securing your organization, contact Control Gap for more information.