Uploaded by Crusher Cards

Log4j blog post-final

Responding to Log4j CVE-2021-44228 vulnerability
A previously unknown 0-day vulnerability in Log4j 2.x has been reported on 9th of December 2021. If
your organization deploys or uses Java applications or hardware running Log4j 2.x you organization is
likely affected.
Technical summary
Yesterday a new Log4J 0-day vulnerability was reported on twitter:
https://twitter.com/P0rZ9/status/1468949890571337731 . The first PoC (Proof of Concept) of the
vulnerability is already available at the time of writing - https://github.com/tangxiaofeng7/apachelog4j-poc
According to RedHat (source: https://access.redhat.com/security/cve/cve-2021-44228) it’s rated as 9.8
CVSSv3 which is almost as bad as it gets. If successfully exploited on your infrastructure, it will result in
attackers being able to perform a RCE (Remote Code Execution) attack and compromise affected the
server. Given the relative simplicity of the exploit it’s likely that your incident response team will need to
deal with an attack.
There are multiple reports that the vulnerability is being actively exploited in the wild and needs to be
patched promptly, there’s already a patched Log4j version available:
Am I affected
To check whether your application is likely affected you must verify:
Log4j version – all 2.x versions before 2.15.0 (released today, Friday, 10th of December 2021) are
JVM version - if lower than (to be confirmed):
o Java 6 – 6u212
o Java 7 – 7u202
o Java 8 – 8u192
o Java 11 - 11.0.2
If both are true, your Log4j version is older than 2.15.0 and your Java version patch level is older than
listed above, you’re almost certainly affected. At this time, it’s likely that your internet-facing
infrastructure may have been already compromised as this vulnerability is being actively exploited,
according to this report: https://www.cert.govt.nz/it-specialists/advisories/log4j-rce-0-day-activelyexploited/
Please bear in mind that even if your application does not use log4j directly its surrounding
infrastructure such as the application server, message queue server, database server, network devices
may be using that combination of Java and log4j version that expose you to this vulnerability.
Even if your application does not use the affected JVM version it’s still recommended to update log4j
How to mitigate in the short term
Source: https://logging.apache.org/log4j/2.x/security.html
In earlier versions of log4j >= 2.10 it is possible to mitigate this issue by
Setting the system property
o log4j2.formatMsgNoLookups: true
Set the JVM parameter
o -Dlog4j2.formatMsgNoLookups=true
Removing JndiLookup class from the classpath
o example: zip -q -d log4j-core-*.jar
According to the guidelines in https://logging.apache.org/log4j/2.x/security.html , if the Java version is
== 8u121 it is possible to mitigate the issue by setting (to be confirmed)
"com.sun.jndi.rmi.object.trustURLCodebase" to false
"com.sun.jndi.cosnaming.object.trustURLCodebase" to "false".
Risk Management procedures
While the development teams work on finding the impacted applications and update all the relevant
dependencies, it is advisable to update your Intrusion Prevention Systems (IPS) rulesets to gain more
time to work on the remediation.
We would recommend that you reach out to your IPS vendor directly to ensure that the software in use
by your IPS/IDS system is not affected as well by this same vulnerability.
Note: Even though your IDS (Intrusion Detection System) systems are helpful to show attempts of
testing this vulnerability against your applications, they are not able to stop the attack reaching your
How Veracode helps you to address this problem
Thanks to our SCA (Software Composition Analysis) product you can quickly verify whether an
application portfolio that you’re scanning with us is affected and at elevated risk of being exploited.
To verify whether your applications are using vulnerable versions of log4j login to Veracode Platform to
check versions of log4j that are dependencies of your applications by following this guide: