Updated Guidance on Addressing Log4J CVEs

The Apache Software Foundation provided updated guidance that the patch to fix Log4Shell (version 2.15.0 and below) was insufficient – a new update (version 2.16.0) fixes these issues. In addition, it was also confirmed that updating JVM settings can be overridden by attackers and is no longer a viable fix. 

What changed?

Specifically, the log4j v2.15 fix was incomplete and is still vulnerable in certain non-default configurations and for applications that use pattern layouts like a Context Lookup. While it is better than the previous version and addressed the immediate issues on the remotely exploitable risk, a misconfiguration could create other issues. However, even with the v2.15 fix, it has now been shown to be bypassed by prominent researchers. One of those researchers, 

Alvaro Muñoz with GitHub Security Lab has published examples of what can go wrong.

Recommendations:

You Must Locate Vulnerable Log4J Instances

Teams should leverage the Software Bill of Materials that tools like Contrast produce, to locate Log4J and other vulnerable libraries. These inventories provide immediate guidance on which applications are affected so that you can take action.

We recommend looking at other applications where you have not yet created an inventory. You can use a tool such as SafeLog4J to evaluate these applications.

Once You have located your Log4j, what should you do?

Log4j2

Teams that locate Log4J2 in their applications must upgrade to version 2.16.0. Versions below this number are vulnerable to one or more serious and remotely exploitable CVEs.

For custom applications, we recommend that you update the library, rebuild, and redeploy the application

For vendor applications, obtain updated software from the vendor. If they do not have an update or you do not apply the update, your systems and their data are at high risk or remote exploitation.

Log4j1

Teams that locate Log4j1 should follow recommendations to either upgrade to log4j v2.16 or to remove the JMSAppender and SocketServer classes from the library. To do this run the following (with your version of log4j in the path):

• zip -d log4j-1.x.x.jar org/apache/log4j/net/JMSAppender.class
• zip -d log4j-1.x.x.jar org/apache/log4j/net/SocketServer.class

We Recommend Adding Detection and Protection

The common aspect of teams that were prepared to avoid a security scramble is that they had security sensors within applications. When the need to act appeared, they knew where to go and what to do. When these agents detect new custom vulnerabilities, these users know what happened, what the risk is, and how to fix the issue. These teams can remediate in a reasonable time to keep their organizations secure and avoid future security fire drills.

Consider using Contrast Assess and Protect to monitor and defend at your application layer.

At this time, Contrast recommends updating to log4jv2.16. Version v2.16 completely disables the jndi lookup feature, by default, which caused the vulnerability. 

What’s next:

The situation is fluid and constantly evolving. We will keep you updated as soon as we have something to share. Sign up here to get latest alerts on Log4J and monitor Apache’s page on this topic.