Revisiting the Apache Log4j Vulnerability

By now, most are aware of the Apache Log4j vulnerability that was announced in December of 2021. The exposure is widespread in Java applications, and I have been discovering that many companies are affected by it. Remediation is imperative to ensure that attackers do not exploit affected assets in their environment. It is an easy exploit, which adds to the urgency of remediation. The first step in remediation is finding a tool that will scan your assets for the Apache Log4j vulnerability. As of this writing, Qualys has forty-six confirmed Apache Log4j vulnerabilities in their KnowledgeBase consisting of QIDs that detect vulnerabilities or gather information in CGI and VMware web applications, Cisco network services or devices, web servers, and Ubuntu Linux. Furthermore, the Apache Log4j QIDs detect vulnerabilities that can be exploited after getting local access to a box or vulnerabilities that need authenticated credentials to be detected, and security policy checks that detect the presence of anti-virus or various other settings that could be pushed with a Windows group policy. If after performing a vulnerability scan, it is confirmed that the vulnerability is positively detected within your network, here are some quick steps to begin the remediation process:

1. Perform upgrades and patches by investing in a tool or MSP that will detect and respond to the vulnerability in real time. For example, tools like Qualys VMDR or Cynet can assist in automatically detecting the issue and deploying patches. The vulnerability management tool you choose is only as good as the response. The idea is that vulnerabilities will not persist over a period with patch management. As a new threat is pushed out, MDR or EDR tools will immediately check for it and automatically prioritize the riskiest vulnerability on the most critical assets.
2. Wait for the vendor to release a patch. This is obviously not highly recommended as there is inherent risk involved in waiting for the application vendor’s patch to be released. It is advisable to analyze the risk and if it can be mitigated, use a patch management tool to deploy the vendors patch as soon as it is available.
3. Upgrade Log4j or remove the JndiLookup class. This is a less risky option as application patching best practices assume that patching a vulnerable application by upgrading the Log4j library may break the application and demands extensive testing. The Apache Log4j webpage recommends the following mitigation endeavors:
   • Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or 2.17.0 (for Java 8 and later)
   • Remove the JndiLookup class from the classpath
     1. Qualys Open-Source Remediation Utility: for existing customers, this method simplifies the complexity of removing Log4Shell utilizing the removal of the JndiLookup class. This utility removes all instances from all vulnerable libraries found on all assets. The steps for this type of remediation can be found here: https://blog.qualys.com/vulnerabilities-threat-research/2022/01/11/how-to-make-log4shell-remediation-quick-effective

Should you have any further questions regarding the Log4j vulnerability and remediation steps your organization should take, please do not hesitate to reach out to our team. Our cybersecurity experts are always available to serve as an unbiased sounding board to assist with whatever challenges or questions you might have. Contact us today to learn more!