HO! HO! Oh NOOOO! The Log4j Vulnerability

Here we go again: another holiday season, another exploit.

It appears many IT, risk, and security professionals are going to have to wait to down their favorite holiday cheer as another exploit has brought tumult to the community.

A Log4j vulnerability has bubbled to the surface – a hint of bitterness as we sip our eggnog. Log4j (which stands for “Log for Java”) is a Java library for logging error messages in applications using Apache software. Many applications globally use Java – it’s ubiquitous and has been around for decades. With this vulnerability, hackers can bypass restrictions and gain access to any system remotely without using a password and can try to install malware or even steal data by redirecting incoming JNDI (Java Naming and Directory Interface) lookups to a remote codebase forcing the vulnerable server to execute potentially malicious code.

According to Checkpoint, the vulnerability was discovered on November 24th, and initially, the attacks were relatively small. Around December 9th, attacks exploiting this vulnerability have exploded – jumping into the millions – averaging around a hundred exploits per minute.

Log4j software updates are now available. In update version 2.15, the security risk is no longer present. Update version 2.16 is highly recommended as it fixes the problem by removing support for message lookup patterns and disabling JNDI functionality by default. There are still many older software applications that don’t use the current version of Log4j, so anything previous to 2.15 is very much at risk.

So, what does this mean to third party risk practitioners?

If you haven’t already, you need to immediately craft and distribute a notification to ALL your vendors asking them if they utilize any application that may be affected by this vulnerability. Next, make sure your internal IT organizations are familiar with the vulnerability and can inventory not just in-house applications that may potentially be affected, but to be on the watch for connecting network and system traffic for any irregular data extraction or movement from your networks systems.

For the standard user, the typical mantra of “change passwords; use MFA; etc.” may provide temporary relief, but since this vulnerability is ingrained at the application level, the onus is on companies to propagate their software updates as soon as possible.

Shared Assessments has responded by producing a quick question set (taken from the 2022 SIG Questionnaire) to assist the community in further vendor due diligence. Like past exploits and issues, Shared Assessments will continue to analyze and acquire a deeper understanding of the impact these may have on the community and our profession.

I can only hope that Santa has enough coal to deliver to the countless “Grinches” who tried to rob the holiday spirit from us Whos down here in Whoville. Now, please allow me to return to my eggnog!

Additional reading:

Second Log4j vulnerability discovered, patch already released | ZDNet

Apache Log4j Vulnerability – Check Point Software

Blog Footer Cybersecurity