Apache has released another version of Log4j, 2.17.1, which fixes a newly discovered remote code execution (RCE) vulnerability (CVE-2021-44832) in 2.17.0.
Up until now, 2.17.0 was the latest version of Log4j and was considered the safest to upgrade to, but we’ve gone further.
Fifth Log4j CVE in less than a month
The Log4Shell vulnerability (CVE-2021-44228) began mass usage by threat groups after a PoC exploit was published on GitHub on December 9.
Because of the heavy use of Log4j in most Java applications, Log4Shell quickly became a threat to enterprises and governments around the world.
The Log4Shell vulnerability is a very serious problem, but milder variants of this vulnerability have emerged in versions such as Log4j 2.15 and 2.16 (which were previously considered fully patched).
We have reported on four different CVEs affecting Log4j, one of which was found in the “logback” framework. After the DoS vulnerability was discovered in version 2.16, there was a rapid increase in recommendations to upgrade to version 2.17.0, which is considered the most secure.
This time, however, a fifth vulnerability, the RCE vulnerability (CVE-2021-44832), was discovered in 2.17.0 and its patch was applied to the latest release, 2.17.1.
With a severity of “Medium” and a CVSS score of “6.6”, this vulnerability is caused by a lack of additional control of JDNI access in log4j.
JDBC Appender should use JndiManager when accessing JNDI. Access to JNDI should be controlled by system properties
Related to CVE-2021-44832, an attacker with permission to modify the logging configuration file can use a JDBC Appender with a data source that references a JNDI URI to construct a malicious configuration and execute remote code.
Yaniv Nizry, a security researcher at Checkmarx, commented that they have reported this vulnerability to Apache.
After a week of code review and testing, we have encountered a new, undiscovered deserialization security vulnerability. This vulnerability does not use the disabled lookup feature. This vulnerability is more complex than the original CVE-2021-44228 because it requires the attacker to control the configuration (like the “logback” vulnerability CVE-2021-42550).
Unlike logback, log4j has the ability to load a remote configuration file or configure a logger through code, which allows arbitrary code execution through MITM attacks, user input ending up in a vulnerable configuration variable, or modifying a configuration file.
“I hope this is a joke, I hope so… #log4j,” one user tweeted.
Another user wrote, “We’re way past the stage where the only responsible thing to do is to flash a giant neon sign that says “LOG4J can’t be fixed, don’t use it anyway”. https://twitter.com/rootwyrm/status/1475851798908964864
Did we release the information too early?
At the time of Nizry’s tweet, the tweet did not contain any details about the vulnerability or how it could be exploited, but within minutes, security experts and netizens began to investigate the claim.
As seen in the Log4Shell vulnerability leak that occurred on December 9, premature disclosure of security vulnerabilities can invite malicious scanning and exploitation activities.
Marc Rogers, VP of Cybersecurity at Okta, was the first to disclose that exploiting the vulnerability identifier (CVE-2021-44832) requires a non-default log4j configuration, and that the configuration is loaded from a remote server.
So far, the log4j vulnerability has been exploited by all sorts of threat groups, including state-sponsored hackers and ransomware groups, to inject Monero miners into vulnerable systems.
Conti, a ransomware group, has been confirmed to target vulnerable VMWare vCenter servers. Meanwhile, attackers who infiltrated the Vietnamese crypto platform ONUS via log4shell demanded a ransom of $5 million.
Log4j users should immediately upgrade to the latest release 2.17.1 (Java 8 compatible). Backported versions 2.12.4 (Java 7) and 2.3.2 (Java 6) containing this fix will also be released shortly.
Comments