Another vulnerability found in Log4j library, as Siemens extends affected products
The Apache Software Foundation (ASF) has identified another vulnerability in the Log4j library, its open-source Java logging software that is used across both enterprise apps and cloud services. Following the ASF’s announcement of the second denial of service Log4j library vulnerability that rendered the initial mitigations and fix in version 2.15.0 as incomplete under certain non-default configurations, Siemens extended the number of product lines affected by the latest disclosure.
“Siemens is currently investigating to determine which products are affected and is continuously updating this advisory as more information becomes available,” according to the company advisory. “Log4j versions 2.16.0 and 2.12.2 are supposed to fix both vulnerabilities,” it added.
The Siemens product lines affected by the Log4j library vulnerabilities now include Advantage Navigator, COMOS, E-Car OC (E-Car Operation Center), EnergyIP applications, EnergyIP Prepay, HES UDIS (Head-End System Universal Device Integration System), Industrial Edge Management (IEM), LOGO! Soft Comfort, Mendix, MindSphere, Opcenter Intelligence, Operation Scheduler, SIGUARD DSA, SIMATIC WinCC, SiPass, Siveillance Control Pro, Siveillance Vantage, Solid Edge, Spectrum Power, Teamcenter, and Xpedition.
Siemens had previously identified on Monday the presence of the Apache Log4j vulnerability in some of its product lines, which could potentially be exploited by remote unauthenticated attackers to execute code on vulnerable systems.
Tracked as CVE-2021-45046, the threat level of the second log4j vulnerability is said to be ‘moderate.’ It was found that the incomplete patch to address the initial log4j vulnerability included certain non-default configurations which could allow attackers “to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack.” the ASF said in its latest advisory.
The Log4j 2.15.0 restricts JNDI LDAP lookups to localhost by default, according to the National Vulnerability Database (NVD) advisory. “Note that previous mitigations involving configuration such as to set the system property `log4j2.noFormatMsgLookup` to `true` do NOT mitigate this specific vulnerability.”
Log4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default, the NVD advisory added.
With the new version 2.16.0 of Log4j library, the “update disables JDNI by default requiring a user to explicitly turn the JNDI feature on and completely removes support for message lookups. When considering mitigations strategies for the Log4Shell vulnerabilities this should be considered the preferred method of mitigation,” McAfee observed in an updated blog post.
Another industrial vendor, Inductive Automation said that it “has conducted a full audit of Ignition’s direct and transitive dependencies to confirm that log4j is not used or included in any supported or unsupported release of Ignition, and as such it is not vulnerable to the RCE outlined in CVE-2021-44228.”
“This includes LTS versions 7.9 and 8.1, as well as all past and non-LTS versions. While Ignition versions 7.8 and prior did use log4j for its logging backend, the version used (1.2.x) is not affected,” Dave Fogle, a company executive, wrote in the advisory.
The OT-ISAC said in a LinkedIn post that its team is continuously working “closely with our members to ensure all necessary support is available and will host threat briefing this Thursday (December 16, 2021) at 3:00 PM SGT to provide additional insights on repercussions for Log4Shell to critical environments & OT systems and how to mitigate these vulnerabilities.”
Researchers at Check Point said that exactly a year after the SolarWinds hack, and “while organizations are still struggling to protect the software supply chain from third-party risk, the Apache Log4j vulnerability exploit has caught security teams during a weekend. Unlike other major cyber-attacks that involve one or a limited number of software, Log4j is basically embedded in every Java based product or web service. It is very difficult to manually remediate it,” according to a company blog post.
‘This vulnerability, because of the complexity in patching it and easiness to exploit, seems that it will stay with us for years to come, unless companies and services take immediate action to prevent the attacks on their products by implementing a protection,” Check Point added in its post.
CrowdStrike has also identified a malicious Java class file hosted on infrastructure associated with a nation-state adversary, according to a Tuesday update on the company’s blog post. “The Java code is used to download known instances of adversary specific tooling and is likely to be used in conjunction with the recently disclosed Log4Shell exploit (CVE-2021-44228),” it added.
Perpetrators include “Chinese government attackers,” Charles Carmakal, chief technology officer of cyber company Mandiant told ArsTechnica. He said, “that Chinese state-backed actors were also attempting to exploit the Log4J bug but declined to share further details.”
The initial vulnerability in Log4j was identified as parsing a specially crafted log message insecurely, causing it to execute remote code with the full privileges of the main program, according to details released by Recorded Future on Tuesday.
“The Log4Shell exploit is useful both for initial access and lateral movement, as both externally facing and internal services can use the Log4j logging library,” John Wetzel, director of intelligence solutions at Recorded Future, wrote in the post. “The earliest activity detected by Recorded Future for this vulnerability identified criminals actively exploiting it; active exploitation continues. BlackBerry researcher Greg Linares predicts the likelihood of a wormable version within the next few days, with some groups reportedly actively working on such versions,” he added.
A complimentary guide to the who`s who in industrial cybersecurity tech & solutions
Free DownloadRelated
