At the end of November, we’ll be migrating the Sematext Logs backend from Elasticsearch to OpenSearch

Log4Shell: How We Protect Sematext Users

December 20, 2021

Table of contents

On December 9, 2021, a vulnerability was reported that could allow a system running Apache Log4j 2 version 2.14.1 or below to be compromised and allow an attacker to execute arbitrary code on the vulnerable server. This vulnerability was registered on the National Vulnerability Database as CVE-2021-44228, with a severity score of 10.

Here is a diagram of the attack chain from the Swiss Government Computer Emergency Response Team (GovCERT).

Log4Shell Diagram

The Log4j 2 vulnerability can be exploited by sending a log message with a specially crafted URI, which can cause the application to execute arbitrary code (such as by providing a Base64 encoded script in the path).

This is due to specific behavior in Log4j 2 that allows for the input of variable data into the log. By using this feature during an exploit, the attacker uses the URI input to instruct Log4j 2 to resolve an object they input (such as an encoded script). This issue has been resolved in the latest version of Log4j 2.

What We’ve Done to Protect our System and Users

We are investigating and have taken action by updating all of our vulnerable systems to the latest version of Log4j 2 (version 2.16.0) which is not affected by this exploit. We understand the critical nature of the issue and continue to monitor the development of this issue to ensure we take all necessary steps to keep our systems and our users’ systems protected.

Are You Affected By This?

Any Java application running Log4j 2 from versions 2.0 to 2.14 is affected by this vulnerability and should be updated immediately. You should find all systems and software using log4j in your environment (this can be a time-consuming task, so better start early) and check what version they’re using. Here’s a list by the Nationaal Cyber Security Centrum of the Netherlands in which you can check if software you are using is affected.

None of the latest versions of any Sematext software you installed as part of your Sematext Cloud subscription is affected by this vulnerability. Make sure you update your agents to the latest version following our docs.

What You Need to Do If This Affects You

Apply the corresponding security patches for internet facing software and devices immediately, and those for internal software and devices at your earliest convenience. We recommend upgrading Log4j 2 to the latest version, currently 2.16.

If patching is not possible for whatever reason, we strongly recommend applying the following mitigation measures:

  • For version >=2.10: set log4j2.formatMsgNoLookups to true
  • For releases from 2.0 to 2.10.0: you may want to remove the LDAP class from log4j completely by issuing the following command:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
  • For certain JVM Versions, it is possible to set com.sun.jndi.rmi.object.trustURLCodebase and com.sun.jndi.cosnaming.object.trustURLCodebase to false to mitigate the vulnerability. Some JVM versions already have this as default setting
  • You may check for exploitation attempts — no matter whether they were successful or not — in your web server logs using the following Linux/Unix command:
sudo egrep -i -r '\$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+' /var/log/

Learn More

For more information on how to proceed regarding this exploit, check out the Swiss Government Computer Emergency Response Team (GovCERT) webpage.

To learn more about Log4j and how to use it to ship logs to Sematext Cloud, read the Log4j Tutorial on our blog.

Java Logging Basics: Concepts, Tools, and Best Practices

Imagine you're a detective trying to solve a crime, but...

Best Web Transaction Monitoring Tools in 2024

Websites are no longer static pages.  They’re dynamic, transaction-heavy ecosystems...

17 Linux Log Files You Must Be Monitoring

Imagine waking up to a critical system failure that has...