What should I do to protect against CVE-2021-44228/Log4shell vulnerability with Apache Log4j?

How can you tell?

As of this posting, this is an evolving issue but we know the impact of log4j is widespread. This Apache library is widely used and integrated across all manner of software. We will continue to update this answer as more of the attack surface becomes known.

Here are a handful of commands you can use to check for what version of log4j is used by applications on your server:

• Gradle:

gradelw dependencyInsight --dependency org.apache.logging.log4j:log4j-core --configuration runtimeClasspath

• Maven:

mvn dependency:tree -Dincludes=org.apache.logging.log4j:log4j-core

• JDK:

jdeps -R -verbose:class filename.jar | grep log4j

• Linux:

find / 2>/dev/null -regex ".*.jar" -type f | xargs -I{} grep JndiLookup.class "{}"

You can validate whether your infrastructure is vulnerable by following these directions that show how to use Thinkst CanaryTokens in very creative ways. Be careful when following those steps on sensitive servers! The ${jndi section can be used in a variety of places, such as comments on a Minecraft server, request headers (as in the example), and anywhere an end user can supply input that ends up processed by log4j. Do not attempt to exploit a server you do not own.

Vulnerability details:

Affected Apache log4j2 Versions:

• 2.0 <= Apache log4j <= 2.15.0

• 2.15.0 was previously thought to fix this vulnerability but was found to be insufficient. 2.16.0 is now the “fixed” version.

However, a lower severity denial of service issue was discovered in 2.16.0. This is not as bad as the remote code execution in <=2.15.0, but upgrading to 2.17.0 is recommended.

While 1.x is not vulnerable to this specific threat, it is end of life and has other security vulnerabilities, including other remote code executions of similar danger as this CVE. Upgrading to 2.16.0, if not 2.17.0, is strongly recommended.

How to fix this?

If you can upgrade log4j directly, do that. Upgrade to at least 2.16.0. log4j-core.jar is available on Maven Central here, with [release notes] and [log4j security announcements].

If you cannot update Apache log4j or the software that bundles it and are using at least log4j 2.10, you can set this JVM flag for partial protections:

-Dlog4j2.formatMsgNoLookups=true

This flag was previously thought to mitigate the vulnerability (and was the only change in the 2.15.0 release) but was found to not cover all cases of RCE. 2.16.0 was released to fully mitigate this issue. If you have applied this log4j2.formatMsgNoLookups flag, patching to 2.16.0 is still required. If you are using a version of log4j before 2.10, this flag is not available.

If the library is bundled with other software (e.g. Elastic, Kafka, Minecraft), seek out the latest updates there.

Product Update Links:

The Netherlands National Security Center is maintaining a list of software responses to the log4j vulnerability. https://github.com/NCSC-NL/log4shell/tree/main/software. Consult this list to see if you are running any vulnerable software and understand remediations. Note: a piece of software not appearing on this list does not convey safety. Verify with the methods listed above to be safe.

We have extracted some of the more popular software we see on our platform below:

Elastic Products (e.g. Search, Logstash, Kibana): https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vulnerability-cve-2021-44228-esa-2021-31/291476

Minecraft: Upgrade to at least https://www.minecraft.net/en-us/article/minecraft-java-edition-1-18-1

Atlassian Products: https://confluence.atlassian.com/kb/faq-for-cve-2021-44228-1103069406.html

Apache: The Apache HTTP and Tomcat servers are not affected. Detailed product notes from Apache can be found here: https://blogs.apache.org/security/entry/cve-2021-44228

Defense in Depth:

Using Nginx and LUA script to mitigate against Log4Shell (CVE-2021-44228) vulnerability attacks:

https://www.infiniroot.com/blog/1155/using-nginx-lua-script-mitigate-log4shell-cve-2021-44228-vulnerability

Keep in mind that these detections are only one line of defense and will not fully stop a determined attacker. Also, note the script has been updated a few times as attack signatures change.

Continued reading and deep dives:

Interested in learning more? Fastly has produced an excellent write-up here.

Want a more in-depth examination of the vulnerability and see how a Minecraft server can be exploited? See John Hammond’s YouTube video here.