On 9 December, 2021, a Proof-of-Concept (PoC) exploit was published highlighting a Remote Code Execution (RCE) critical vulnerability in the Apache Log4j library. Log4j is a popular Java library that can be found in many applications and services found throughout the Internet. Some of the more popular products that leverage this are:
- Minecraft: Java Edition
- Cisco Routers, Switches, Security Appliances, and others
- Multiple VMware Products
From the CVE-2021-44228 security advisory:
Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.
A Remote Code Execution (RCE) vulnerability is one in which arbitrary commands can be executed from an external (remote) source without the appropriate authorization headers. As you can imagine, this should concern any administrator who is responsible for an organization’s critical systems. In terms of criticality, the National Vulnerability Database (NVD) will score a vulnerability from 0.0 to 10.0. The CNSS score for this Log4j vulnerability is 10.0.
Although Apache has fixed the vulnerability in Log4j version 2.15.0, there are many applications and services that have not yet updated their products to use the next version. However, this version requires users to upgrade to at least Java 8. Depending on your environment and the application, this could be an issue for you.
At the time of this writing, VMware has not yet provided fixed versions of their applications, but have released a workaround for on how to mitigate the vulnerability. These instructions are similar across many platforms and applications. I have seen similar instructions from numerous vendors, so it should work. You will have to research your specific application to understand the best means to implement the mitigation. Basically, disable the Log4j function that accepts the RCE inputs by adding the following the parameter to the startup call:
-Dlog4j2.formatMsgNoLookups=trueThis does not eliminate the vulnerability in the application; the impacted library is still there. Any re-installation of that version of the application will revert this change, so you will need to make these changes again.
Tenable has posted a blog entry with a lot of good information on detection of this vulnerability within your systems using the Tenable Nessus or Tenable.io applications. They have updated their plugins (available in plugin set 202112112213 and later) to detect this vulnerability using the following 4 plugins:
- Plugin ID 155999 – Apache Log4j < 2.15.0 Remote Code Execution
- Plugin ID 156000 – Apache Log4j Installed (Unix)
- Plugin ID 156001 – Apache Log4j JAR Detection (Windows)
- Plugin ID 156002 – Apache Log4j < 2.15.0 Remote Code Execution
It has been a busy weekend going through my #HomeLab systems to determine the extent of my personal risk. Luckily, Ubiquity has posted an update to their Network Controller to correct the vulnerability. Versions 6.5.54 and later are in the clear. Having the system auto-update applications saved me in this case. In the coming days, I hope your efforts to isolate and update your system vulnerability are successful.