Don’t Panic: Log4Shell

2021-12-29: Updates related to CVE-2021-44832

2021-12-20: Updates related to CVE-2021-45105

We, like many of you, have spent our weekend and the start of this week triaging the risks posed by CVE-2021-44228 (aka Log4Shell).

Choosing a Global Software Development Partner to Accelerate Your Digital Strategy

To be successful and outpace the competition, you need a software development partner that excels in exactly the type of digital projects you are now faced with accelerating, and in the most cost effective and optimized way possible.

Get the Guide

As we’ve been checking and patching our internal systems, products and client systems, some colleagues and I have made a few observations we wanted to share.

First things first, though. If you are concerned about the risks posed by this log4j vulnerability we recommend making sure that you’ve patched vendor products according to vendor instructions and ensure that all your systems are updated to use log4j 2.16.02.17.0 2.17.1or newer. Also, here are some other resources from trusted sources and partners that we find helpful:

• Log4j – Apache Log4j Security Vulnerabilities
• How Log4j Vulnerability Could Impact You (securityintelligence.com)
• Critical New 0-day Vulnerability in Popular Log4j Library Discovered  with Evidence of Mass Scanning for Affected Applications – Latest updates (sonatype.com)
• Log4Shell Remediation Cheat Sheet | Snyk
• Microsoft’s Response to CVE-2021-44228 Apache Log4j 2 – Microsoft Security Response Center
• Zero-day in ubiquitous Log4j tool poses a grave threat to the Internet | Ars Technica
• Inside the Log4j2 vulnerability (CVE-2021-44228) (cloudflare.com)
• Log4J2 Vulnerability and Spring Boot
• Log4j vulnerability: Companies scramble to gird against hackers : NPR

A couple other technical notes…

1. UPDATED 2021-12-20 29: There are several situations where the fixes in 2.15.0, 2.16.0 and 2.17.0 are incomplete as described in CVE-2021-45046, CVE-2021-45105 and CVE-2021-44832, we recommend using 2.16.0 2.17.0 2.17.1 wherever possible. It was previously thought that CVE-2021-45046 was medium to low risk, it has been upgraded to critical. The new vulnerability, CVE-2021-45105, is also a high risk issue and should be patched as soon as possible. Therefore, we recommend upgrading to 2.17.1 even if you had previously upgraded to 2.15.0, 2.16.0 or 2.17.0. This is a dynamic situation, and this may change again as more thorough testing continues to be done.
2. log4j 1.2.x has a similar but more limited vulnerability and no patch will be available as that version of log4j is past end of life. The CVSS 3.0 score for CVE-2021-4104 is still pending, but we do expect the risk level to be lower given the limited code paths that appear to be affected, but there is still some uncertainty here. More information should be available soon, but the TL;DR is that you should be okay if you don’t use JMSAppenders, but this may yet evolve.
3. Remember that log4j may not be a direct dependency of your code, it may be a dependency of a dependency or deeper down the dependency tree. It’s important to use your dependency management tool (i.e. Maven, Gradle, etc.) to check the full tree for references to log4j.
4. The vulnerability itself is fairly straight forward and shockingly easy to exploit. It uses the magic of JNDI lookups, a feature in Java that allows you to transparently interact with a variety of directory and naming services. In this case, the exploit uses LDAP (Lightweight Directory Access Protocol) and a little trickery to get the JNDI lookup to pull what it thinks is an object from an LDAP server via a redirect to an https endpoint but is really code that will be executed on the vulnerable server. The risk here is that any place in an application for which a user can pass in a textual input and that text is logged as-is, will be susceptible to having any arbitrary code passed to it and executed by the JNDI lookup in that text input.
5. NEW 2021-12-29: Per CVE-2021-44832 the same issue can be exploited, although with more difficulty (the attacker must first get access to the log4j configuration file), when using 2.17.0 with the JDBCAppender (i.e. writing logs to a database). If you’re not using this functionality, there should be no risk related to this new vulnerability. Unlike the JMSAppender noted for the log4j 1.2.x risk, however, the JDBCAppender is widely used in log4j 2.x. This problem is interesting because it’s an additional layer of JNDI lookup capability that exists to allow log4j to lookup the connection information for the intended database from the local application context, or possibly, a remote service. This use of JNDI lookup is commonly used to avoid hard-coded database connection information in code and configuration files (as well as centralizing the storage of credentials). The fixed jar is simply changing the default behavior and allowing the prior behavior to be enabled with a setting. This is the sort of change that may require more rework if the JDBCAppender needs to be used with JNDI lookups to make it safe.

Now on to the interesting part. As we’ve been discussing this internally, we realized a few things about the risk posed by the log4shell vulnerability:

• There is an industry-wide tendency to shrug off these kinds of risks as “only a problem for internet-facing systems.” There are two key ways that this thinking is flawed. First, perfectly preventing a malicious actor from accessing your network is impossible. Not only are firewalls not perfect, but social engineering and angry employees can circumvent them entirely. Second, this sort of vulnerability can be exploited by cascading an offending string from system to system via service calls down the chain until it finds one that is vulnerable.
• Every software vendor is taking a different approach. Even the ones that agree that swapping out the jars is the right move don’t agree on how they want to deliver that to customers. We find that it is important to take the time to assess each vendor’s approach and follow their instructions carefully to ensure you don’t create more problems than you solve. That said, patience is required to allow vendors the time to not only identify which products are vulnerable and release a fix, but also to test that fix and ensure it doesn’t cause problematic regressions.
• It is not at all surprising how widespread this is, but it is surprising that it was found because of Minecraft. It turns out that Minecraft is written in Java and uses log4j2. It appears that Minecraft servers were logging, by default, all the messages typed into the chat. This meant that anyone could put a malicious JNDI lookup into the chat on a Minecraft multiplayer server and exploit this vulnerability. Here’s a great video showing how it works, including how to get as far as getting a remote shell on a Minecraft server.

If you need help either to work through remediations or devise a strategy to optimize response next time (because there certainly will be a next time), as your trusted partner and advisor, we’re ready, willing, and able to help.

Just don’t forget your towel.