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: https://logging.apache.org/log4j/2.x/security.html 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 affected 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 version. 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 org/apache/logging/log4j/core/lookup/JndiLookup.class Or Or 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 and "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 applications 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: https://docs.veracode.com/r/c_SCA_comps References https://www.lunasec.io/docs/blog/log4j-zero-day/ https://nvd.nist.gov/vuln/detail/CVE-2021-44228 https://logging.apache.org/log4j/2.x/security.html https://www.cert.govt.nz/it-specialists/advisories/log4j-rce-0-day-actively-exploited/ https://www.veracode.com/blog/research/exploiting-jndi-injections-java https://github.com/veracode-research/rogue-jndi
