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.
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.
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?
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.
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.
*** This is a Security Bloggers Network syndicated blog from AppSec Observer authored by Erik Costlow, Principal Product Evangelist. Read the original post at: https://www.contrastsecurity.com/security-influencers/updated-guidance-on-addressing-log4j-cves