Updates: |
---|
December 12, 2021: Java version based recommendation removed |
December 13, 2021: Log4j 1.x based recommendation added |
December 13, 2021: JDK versions have been removed from the affected list based on The work of Mario Almeida |
December 13, 2021: The link to the original tweet has now been deleted |
A previously unknown zero-day vulnerability in Log4j 2.x was reported on December 9, 2021. If your organization is deploying or using Java applications or hardware running Log4j 2.x, it is likely that your organization is affected.
Technical summary
Thursday the 9thGod’ In December, a new zero-day Log4J vulnerability was reported on Twitter. The first PoC (Proof of Concept) of the vulnerability is available as of this writing – https://github.com/tangxiaofeng7/apache-log4j-poc
According to the NVD (National Vulnerability Database) it is rated as 10.0 CVSSv3 Which is almost as bad as it can be. If used successfully on your infrastructure, it will allow attackers to perform Remote Code Execution (RCE) attacks and compromise the affected server. Given the relative simplicity of exploitation, it is likely that the response team to your event will have to deal with an attack.
There are several reports that the vulnerability is actively exploited in nature and needs to be corrected immediately. Refer to Apache Log4j Security Consulting for further details.
Am I affected?
All versions of Log4j 2.x <= 2.14.1 Affected. See the correction section below for the reducing advice.
If you use Log4j 1.xYou are only affected by this vulnerability if you use JMS Appenders. To verify that you are using this add-on, re-check your log4j configuration files for the presence of org.apache.log4j.net.JMSAppender status. Having said that, Log4j 1.x has reached the end of life starting in August 2015 and the fixes are no longer available. It has its own set of remote code execution issues and needs to be updated.
Please keep in mind that even if your application does not directly use log4j, its surrounding infrastructure such as the application server, the message queue server, the database server, network devices may use this combination of Java and log4j version that expose you to this vulnerability.
At this point, it is likely that the infrastructure facing your Internet has already been compromised because this vulnerability is being actively exploited, according to this report: https://www.cert.govt.nz/it-specialists/advisories/log4j-rce-0-day-acti…
Fix
Download the latest version of Log4j Reduced 2.15.0 from its version Download page
If you are unable to upgrade, follow these steps:
- If you are using a version log4j2.x version > = 2.10 and <= 2.14.1, This behavior can be reduced by setting a system attribute log4j2.formatMsgNoLookups Or variable environment LOG4J_FORMAT_MSG_NO_LOOKUPS For real.
- If you are using a version > = 2.0-beta 9 and <= 2.10.0, The easiest way is to remove log4j’s Jndi Lookup A class from the JVM class track as detailed below:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Risk management procedures
While development teams work on finding the affected applications and updating all relevant dependencies, it is advisable to update your intrusion prevention systems (IPS) kits to gain more time working on the patch.
We recommend contacting your IPS provider directly to ensure that the software used by your IPS / IDS system is not affected by the same vulnerability.
Although your IDs (intrusion detection) systems are helpful in showing attempts to test this vulnerability against your applications, they are not able to stop the attack from reaching your applications.
How Veracode helps you address this issue
Thanks to our Software Composition Analysis (SCA) product, you can quickly verify that an application portfolio you scan with us is affected and at increased risk of exploitation.
To verify that your applications are using vulnerable versions of log4j, sign in to the Veracode platform. Check out versions of log4j that depend on your apps by following this guide: https://docs.veracode.com/r/c_SCA_comps
*pay attention* Veracode SCA customers can scan for this vulnerability in all of their applications. The value of the vulnerability in our database is here: https://sca.analysiscenter.veracode.com/vulnerability-database/libraries/apache-log4j-2/java/maven/lid-344173/summary
References
https://logging.apache.org/log4j/2.x/security.html
https://nvd.nist.gov/vuln/detail/CVE-2021-44228
https://www.lunasec.io/docs/blog/log4j-zero-day/
https://www.veracode.com/blog/research/exploiting-jndi-injections-java
https://github.com/veracode-research/rogue-jndi
https://www.cert.govt.nz/it-specialists/advisories/log4j-rce-0-day-actively-exploited/