How to Patch Log4j

The security game is complex, and it’s a hard one to play and get right. The unfortunate reality is that the good guys have to be right consistently, whereas the bad guys only have to be right once. A prime example of this complex game is Log4j.

Chances are, you either have extensive knowledge of it or have at least heard about Log4j. Log4j is the latest in a line of extremely versatile vulnerabilities with widespread susceptibility. Log4j is an open-source logging library, or mechanism, that Java uses. This allows apache to log all java actives from fatal errors, splitting logs, security events, etc.

The latest vulnerability in it was discovered around December 10^th, 2021. The vulnerability allows hackers to execute remote code on vulnerable assets. Remote code execution involves hackers sending syntax URL strings to the vulnerable asset that allows them to run a multitude of backend commands on the server. The start of this vulnerability saw hackers installing crypto miners on assets. It quickly evolved into installation of ransomware and now has gone even further to allow extraction of data such as usernames, passwords and credit card data.

Over 58% of organizations are still using vulnerable versions of Log4j. The staggering statistic is 40% of users are still downloading vulnerable Log4j versions of apache software. When we look at the history of similar vulnerabilities such as WannaCry/EternalBlue, we will be dealing and responding to this vulnerability for years to come. This lasting impact makes it imperative to get ahead of this and address it ASAP. There are a couple of methods to fight this.

The first, most straight forward way is to not run the vulnerable versions of Log4j. This means patching if you are currently running the software. Due to the complex nature of workloads, this approach is unfortunately not always feasible immediately because of the possible impact to other assets that are running the workload.

This means possibly having a bifurcated approach to fighting this vulnerability. I have provided detailed instructions below on how to patch to newer version of Log4j that isn’t vulnerable. However, due to possible workload impacts, it’s important to understand what other possible workload impacts could occur with the patch. Once you have gone through a risk assessment on the patching then you can determine which assets can and can not be patched.

The second prong to this means protecting the assets that can not be patched. The easiest way to do this is with a Web Application Firewall (WAF). I say this is the easiest way, but the care and feeding of the WAF can be complex in nature. When you look at the ever-evolving attack types in conjunction with development of your workloads, you have to be vigilant on updating the WAF rules as appropriate. Yes, there are self-learning WAFs, but this still requires a checks and balances and manual intervention for the best protection possible.

As a result of leveraging both patching and a WAF, you will have an immediate 20% increase in your security posture. Also, the best news is your applications will not be vulnerable to the Log4j exploit which could save you from nasty fines, customer loss and huge reputation hits.

How to patch Log4j

• For Java 8+: upgrade to 2.17.1 and for Java 7: upgrade to 2.12.4 from the patch link and migration guide available in the references.
• Users can remove the LDAP class from log4j by using the command: “zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class”.
• Set “com.sun.jndi.rmi.object.trustURLCodebase” and “com.sun.jndi.cosnaming.object.trustURLCodebase” to “false” if acceptable on JVM versions to mitigate the vulnerability.
• In PatternLayout in the logging configuration, replace Context Lookups like ${ctx:loginId} or $${ctx:loginId} with Thread Context Map patterns (%X, %mdc, or %MDC).
• The recommended action is to upgrade to Log4j 2.17.0, which is the latest version of Log4j2. For example, within the pom.xml of your application include:

<properties>

<log4j2.version>2.17.0</log4j2.version>

</properties>

ivision has the security experience and expertise to assist your business with the necessary steps to keep the good guys in charge. Learn more about our security offerings and how to get started.