[ad_1]
Apache has launched one other Log4j model, 2.17.1 fixing a newly found distant code execution (RCE) vulnerability in 2.17.0, tracked as CVE-2021-44832.
Previous to as we speak, 2.17.0 was the latest model of Log4j and deemed the most secure launch to improve to, however that recommendation has now developed.
Fifth Log4j CVE in beneath a month
Mass exploitation of the unique Log4Shell vulnerability (CVE-2021-44228) by menace actors started round December ninth, when a PoC exploit for it surfaced on GitHub.
Given Log4j’s huge utilization within the majority of Java functions, Log4Shell quickly became a nightmare for enterprises and governments worldwide.
Whereas the crucial danger posed by the unique Log4Shell exploit is paramount, milder variants of the vulnerability emerged in Log4j variations, together with 2.15 and a couple of.16—beforehand believed to be totally patched.
BleepingComputer earlier reported on 4 totally different CVEs impacting Log4j and one found within the ‘logback’ framework. After the invention of a DoS flaw in model 2.16, the recommendation had swiftly shifted in the direction of upgrading to model 2.17.0, deemed the most secure of all.
However now a fifth vulnerability—an RCE flaw, tracked as CVE-2021-44832 has been found in 2.17.0, with a patch utilized to the latest launch 2.17.1 which is out.
Rated ‘Average’ in severity and assigned a 6.6 rating on the CVSS scale, the vulnerability stems from the shortage of further controls on JDNI entry in log4j.
“JDBC Appender ought to use JndiManager when accessing JNDI. JNDI entry must be managed through a system property,” states the difficulty description seen by BleepingComputer.
“Associated to CVE-2021-44832 the place an attacker with permission to change the logging configuration file can assemble a malicious configuration utilizing a JDBC Appender with a knowledge supply referencing a JNDI URI which may execute distant code.”
Checkmarx safety researcher Yaniv Nizry claimed credit score for reporting the vulnerability to Apache:
Keep tuned for a blogpost 😉 pic.twitter.com/D56WpVsuF3
— Yaniv Nizry (@YNizry) December 28, 2021
Nizry’s tweet rapidly exploded in visitors, attracting remarks and memes from safety consultants and ‘victims’ of the continued log4j-patching fatigue.
“I hope it is a joke, I hope a lot Pensive face #log4j,” tweeted one consumer in response.
“We’re LONG previous the purpose the place the one accountable factor to do is put up an enormous flashing neon signal that reads ‘LOG4J CANNOT BE FIXED, DO NOT USE IT FOR ANYTHING.'” taunted one other.
Safety skilled Kevin Beaumont labeled the occasion one other “failed Log4j disclosure in movement” throughout the holidays.
Disclosed too quickly?
On the time of Nizry’s tweet, BleepingComputer didn’t see an official advisory or memo indicating the presence of an RCE bug in log4j 2.17.
The tweet itself contained no particulars in regards to the vulnerability or the way it might be exploited however, inside minutes, led a pack of safety execs and netizens to begin investigating the declare.
Disclosing safety vulnerabilities prematurely can lure menace actors to conduct malicious scanning and exploitation actions, as evident from the Log4Shell exploit leak of December ninth.
Marc Rogers, VP of cybersecurity at Okta first disclosed the vulnerability identifier (CVE-2021-44832) and that the exploitation of the bug is dependent upon a non-default log4j setup the place configuration is being loaded from a distant server:
Seems to be like log4j CVE-2021-44832 has non default preconditions: “You’re loading configuration from a distant server and/or somebody can hijack/modify your log4j configuration file
You’re utilizing the JDBC log appender with a dynamic URL deal with.”— Marc Rogers (@marcwrogers) December 28, 2021
Up till now, log4j vulnerabilities have been exploited by every kind of menace actors from state-backed hackers to ransomware gangs and others to inject Monero miners on weak methods.
The Conti ransomware gang has been seen eying weak VMWare vCenter servers. Whereas, attackers breaching Vietnamese crypto platform ONUS through log4shell demanded a $5 million ransom.
Log4j customers ought to instantly improve to the newest launch 2.17.1 (for Java 8). Backported variations 2.12.4 (Java 7) and a couple of.3.2 (Java 6) containing the repair are additionally anticipated to be launched shortly.
BleepingComputer has reached out to Checkmarx for remark prematurely of writing and we’re awaiting their response.
Replace 4:45 PM ET: Checkmarx has revealed a weblog put up describing the vulnerability.
[ad_2]
