About CVE-2021-44228 aka ‘Log4Shell’ (Updated)
This weekend a new 0-day has been published and the web was set to fire. The vulnerability has been assigned CVE-2021-44228 and flagged with Critical severity, it affects Java code importing the very popular log4j logging library. As we can read on Log4j security page: An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled.
It is being actively exploited, so I encourage you to update to a patched version and deploy remediations ASAP.
How it works
Log4shell works by sending a maliciously crafted string as value of a request header to web services depending on log4j, allowing remote code execution to the attacker in an environment where he controls LDAP servers and other JNDI related endpoints. Such environment could be the Internet itself. That kind of criticity recalls Shellshock from 2014 and because of this has been named Log4Shell.
To go deeper on how it works, please head over this well-written articles on naked security and Snyk blog.
Who is affected and mitigations
Even major providers like Apple (now patched), twitter, Minecraft, Microsoft and Amazon are affected (source).
Vulnerable versions are those from 2.0-beta9 to 2.14.1. The patched one is the recently released 2.15.0, which disables the lookup behaviour by default.
Update: Recently released version 2.15.0 has been found to have a moderate security vulnerability (CVE-2021-45046). Now the version you should update to is 2.16.0.
For versions after 2.10.0 you can mitigate the vulnerability by disabling JndiLookup. You can do it by setting the env var LOG4J_FORMAT_MSG_NO_LOOKUPS=true or by running the jar with the property formatMsgNoLookups=true, e.g: java -Dlog4j2.formatMsgNoLookups=true -jar myapp.jar.
JDK versions greater than 6u211, 7u201, 8u191, and 11.0.1 are not impacted by the LDAP attack vector because in these versions com.sun.jndi.ldap.object.trustURLCodebase is set to false (source), yet DNS is being used as JNDI endpoint so upgrading is still strongly recommended.
Spring-boot, per their statement, is affected only if you use log4j2 as the default logging system. More specifically, only applications using log4j-core and including user input in log messages are vulnerable, meaning that if you use spring-boot-starter-logging (which depends on log4j-to-slf4j and log4j-api) your application is safe. Check your pom to know if you use it and have to upgrade.
Cloudflare has written about how they have already deployed a mitigation throught their WAF to both free and paid users. Also, Microsoft has published a guide about their solutions via Microsoft 365 Defender and Defender for Cloud products.
Remaining in the cloud world, HAProxy developers have recently announced that their products are not impacted because they do not use log4j2.
Update 2: More companies have deployed their remediations. I’ve gathered their announcements below and I’ll keep adding as soon as I know more.
Be sure you update because the vuln is already being exploited to mine Monero via RMI (Remote Method Invocation).
If you're looking to identify jars vulnerable to the log4j bug, we wrote this tool to help: https://t.co/VcqluEttY6
— The Paranoids (@TheParanoids) December 16, 2021
To check if your hosts or jar files are vulnerable, you may use this tool from the Yahoo Infosec Team.
An alternative mitigation
If you can’t update the library shortly, e.g. for some older projects, an alternative is to deploy an nginx instance with some Lua scripts and expose the services throught the (reverse) proxy so that malicious headers do not pass to the Java backend behind (link).
Of course similar solutions can be deployed with other products.
Further considerations
You may find yourself using log4j 1.2.x, for example on a couple of old projects. If you are still including it, you should upgrade ASAP since it reached end of life in 2015 and hasn’t included security fixes for a while. It is vulnerable to other remote code execution attacks, like CVE-2019-17571, which has been discovered in 2019 and is somewhat similar to the one discovered this weeekend (link).
Log4j developers strongly recommend to upgrade to version 2.x (as written here), and considering the latest news I advise you to update at least to version 2.16.0. A guide to do so is available on the dedicated Apache website.
Hope it helps. Thanks for reading.
Updates
- Dec 15, 2021: About CVE-2021-45046
- Dec 17, 2021: Added announcements from more companies, Monero mining via RMI and Yahoo! tool.