On December 9, a severe remote code vulnerability was revealed in Apache’s Log4J library, a Java-based logging tool widely used in applications around the world. This vulnerability allows an attacker who can control log messages to execute arbitrary code loaded from attacker-controlled servers  – impacting a broad range of services and applications.

Logz.io has been aware of the log4j vulnerability – termed as Log4Shell or LogJam (CVE-2021-44228) – for several days and remains obligated to update you on how this impacts your information. Thankfully, we are not vulnerable to Log4Shell for a number of reasons. Despite that, we have taken precautions and tested our entire stack to ensure that that assessment remains accurate.

Why is CVE-2021-44228 so Dangerous?

What makes this scenario particularly risky is the ease of exploitation, as even an inexperienced hacker can likely execute a viable attack using this vulnerability. According to the initial research as documented by MITRE, attackers need only to force the application into writing a single  string to the log, whereupon they are able to upload their own code into the application. No authentication is required to take advantage of this vulnerability.

The primary reason Logz.io customers are insulated from this issue results from our use of Logback for microservice logging. We don’t use log4j, nor log4j2. As stated above, we still have moved to ensure that Logz.io users are secure from the log4j CVE.

Here are the major steps we’ve undertaken since news of the vulnerability first broke late last week:

  1. We audited all 3rd-party components to search for instances of log4j use. We found one such instance, and after reviewing it  determined that it was unaffected by the involved vulnerability.
  2. We also tested our entire stack against a number of exploits, which did not affect any components of the stack.
  3. Using our Cloud SIEM product, we have added a number of mitigation measures and detections to alert for potential exploits in our environment. At the moment, none have emerged, but we will continue to monitor to that end. Cloud SIEM customers will be alerted to any such detections that we encounter, should they arise.
  4. We have implemented content-level blocking for exploit attempts at our distributed WAF layer.
  5. For customers of our Cloud SIEM product, we will continue to add new or expanded detections, threat intelligence, and additional IOCs as details come to light.

As a precaution, you can query Logz.io Cloud Management and/or Logz.io Cloud SIEM to search for exploits. The following queries will show you the relevant data:

"jndi\:ldap"~2 
"jndi\:rmi"~2 
"jndi\:ldaps"~2
"jndi\:dns"~2

We will also keep you up-to-date via email, the Logz.io App, and through our blog as this situation develops.