Heimdal
article featured image

Contents:

Another Log4j version has been released by Apache dubbed 2.17.1, as prior to yesterday the most recent Log4j version was 2.17.0. This new variant addresses the RCE found in 2.17.0 under the CVE-2021-44832.

Five CVEs Have Been Linked to Log4j in Less than a Month

The original Log4j vulnerability has been assigned the CVE-2021-44228. As a Proof of Concept (POC) exploit emerged on GitHub for it around December 9, hackers started to massively exploit it, impacting enterprises and governments worldwide, as most Java applications use Log4j.

However, other Log4j vulnerabilities started to appear in versions like 2.15 and 2.16.

According to BleepingComputer, log4j was impacted and linked to four different CVEs, one of them being found in the ‘logback’ framework. Then, a DoS bug was identified in version 2.16, so naturally, at that time the upgrade to 2.17.0 was the safest solution.

However, what followed next was that a new remote execution vulnerability was discovered in this version too and was classified as mentioned above: CVE-2021-44832. The newest release 2.17.1 is out now and comes with a patch for it.

The credit for reporting the vulnerability in the 2.17.0 version to Apache was claimed by the white hacker security researcher from Checkmarx, by his name Yaniv Nizry. He posted a tweet about this.

However, according to BleepingComputer, when he posted the tweet about this new RCE, there was no official advisory released regarding it in the 2.17.0 log4j version. The tweet post did not include details about this new flaw or the means by which it might be exploited.

Yesterday Yaniv Nizry published the blog post he announced on Twitter describing the RCE dubbed CVE-2021-44832:

After a week of reviewing the code and testing, we encountered a new undiscovered deserialization security vulnerability. This vulnerability doesn’t use the disabled lookup feature. The complexity of this vulnerability is higher than the original CVE-2021-44228 since it requires the attacker to have control over the configuration (like the ‘logback’ vulnerability CVE-2021-42550). Unlike logback, in log4j there is a feature to load a remote configuration file or to configure the logger through the code, so an Arbitrary Code Execution could be achieved with a MITM attack, user input ending up in a vulnerable configuration variable, or modifying the config file.

Source

The log4j flaws have been of interest for hackers for quite a while, as they have been massively exploited by state-backed hackers, by ransomware groups, and even in Monero mining campaigns.

In the recent event of this new RCE linked to log4j, users are recommended to upgrade the Apache Log4j2 to versions 2.17.1, 2.12.4, and 2.3.2 or higher.

If you liked this article, follow us on LinkedInTwitterFacebookYoutube, and Instagram for more cybersecurity news and topics.

Author Profile

Andra Andrioaie

Security Enthusiast

linkedin icon

Hi! My name is Andra and I am a passionate writer interested in a variety of topics. I am curious about the cybersecurity world and what I want to achieve through what I write is to keep you curious too!

CHECK OUR SUITE OF 11 CYBERSECURITY SOLUTIONS

SEE MORE