Analysis and Remediation: Log4j Zero-Day RCE (CVE-2021-44228)

A previously unknown zero-day vulnerability in Log4j 2.x has been reported on December 9, 2021. If your organization deploys or uses Java applications or hardware running Log4j 2.x your organization is likely affected.

Technical summary

Thursday the 9^th of December,  a new Log4J zero-day vulnerability was reported on Twitter. The first PoC (Proof of Concept) of the vulnerability is already available at the time of writing -  https://github.com/tangxiaofeng7/apache-log4j-poc

According to NVD (National Vulnerability Database) it’s rated as 10.0 CVSSv3 which is 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 the affected 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. Refer Apache Log4j security advisory for more details.

Am I affected?

At this point in time all versions other than the latest Log4j 2.x versions are affected by different security issues. Version 2.15.0 fixes the widespread CVE-2021-44228. 

However, there are few specific usages that suffer from Denial-of-Service attacks and more severe Remote Code Execution attacks as discussed in detail under Apache Log4j Security page and corresponding CVE-2021-45046, CVE-2021-45105, and CVE-2021-44832. Those usages include having enabled lookups, ThreadContext, custom message factory, Logger.printf replacement patterns and others as described on log4j2 website. To obtain more information about vulnerable usage refer to the Apache Security advisory. 

If you are using Log4j 1.x, you may be impacted by this vulnerability, but only if the attacker can modify your Log4j 1.x configuration file, and if you are using JMS Appenders, which is highly unlikely. The attack is weaker compared to Log4j version 2.x. To verify if you are using this appender, double check your log4j configuration files for presence of org.apache.log4j.net.JMSAppender class. This case is reported with a separate CVE-2021-4104. Having said this, Log4j 1.x has reached end-of-life as of August 2015 and patches are no longer available. Log4j 1.x has its own set of remote code execution issues such as CVE-2019-17571   and should be updated. 

Log4j Vulnerability Remediation

Patch with the latest available version from Log4j 2.x download page. 

Your organizational priority with respect to patching should be as under: 

• Update all applications which are using log4j 2.x <= 2.14.1 and applications using Log4j < latest Log4j 2.x version with any insecure usage as described in Log4j security advisory  to the latest available version. If confirming the presence of any insecure usage is time consuming or complex, please update to the latest available version. 

• Applications already updated to Log4j version 2.15.0 or 2.16.0 and not using any vulnerable configurations, patterns, or APIs can be updated to the latest Log4j 2.x version with a lower priority.

For mitigations related to specific CVEs, please refer to the Log4j 2.x Security Advisory page.

If you are limited to Java 6 or Java 7 and can’t update to the latest Log4j 2.x version, update to the latest Log4j version available for your Java version as described on Log4j 2.x Security Advisory page.

How Veracode helps you to address this problem

Thanks to our Software Composition Analysis (SCA) 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, log in to the Veracode Platform. Check versions of log4j that are dependencies of your applications by following these guides: https://docs.veracode.com/r/c_SCA_comps and https://community.veracode.com/s/contentdocument/0693n00000EsnqvAAB

*Please note* Veracode SCA customers are able to scan for this vulnerability across their applications. The entry for the vulnerability in our database is here: https://sca.analysiscenter.veracode.com/vulnerability-database/security/remote-code-execution-rce-/java/sid-33244/summary 

Off the Shelf Software

Please bear in mind that even if your application does not use log4j directly, its surrounding infrastructure such as the docker container, 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. It is also possible that other 3^rd party frameworks and libraries used in your project could also be using insecure versions of Log4j.

Number of private and government entities prepared lists of vulnerable off-the-shelf software products. Out of those we are recommending CISAs list (United States Cybersecurity and Infrastructure Security Agency) as well as Dutch NCSCs list (Nationaal Cyber Security Centrum). There’s also log4j2 information available on the Docker blog if your organization is using Docker to run applications. 

Your vulnerability scanning vendor (not to be confused with SAST, DAST, or SCA products) is likely already providing detection capability for many of the vulnerable off-the-shelf products mentioned in the collections listed above. 

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 by this same vulnerability. 

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 from reaching your applications. 

References

https://logging.apache.org/log4j/2.x/security.html

https://nvd.nist.gov/vuln/detail/CVE-2021-44228

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046 

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4104 

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45105

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44832

https://www.lunasec.io/docs/blog/log4j-zero-day/

https://www.veracode.com/blog/research/exploiting-jndi-injections-java

https://community.veracode.com/s/contentdocument/0693n00000EsnqvAAB 

https://sca.analysiscenter.veracode.com/vulnerability-database/security/remote-code-execution-rce-/java/sid-33244/summary 

https://sca.analysiscenter.veracode.com/vulnerability-database/security/denial-of-service-dos-/java/sid-33337 

https://github.com/veracode-research/rogue-jndi

https://www.cert.govt.nz/it-specialists/advisories/log4j-rce-0-day-actively-exploited/

https://www.docker.com/blog/apache-log4j-2-cve-2021-44228/ 

https://github.com/cisagov/log4j-affected-db 

https://github.com/NCSC-NL/log4shell/blob/main/software/README.md