Question

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

Though the reports have been concerning, there are steps you can take to protect against this vulnerability! Dedicated security professionals and software engineers working across the world have provided patches to mitigate CVE-2021-44228/Log4shell. However, we still need you to do your part as a member of the broader internet community. We need you to ensure the services you’re hosting on DigitalOcean are up to date and free from this critical log4j vulnerability!

Subscribe
Share

Submit an answer
You can type!ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Accepted Answer

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.

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.