All the Log4j, logback bugs we know about so far, and why you MUST abandon 2.15

Everyone has heard of log4j’s Critical Zero Day before. Nicknamed “Log4Shell” and “Logjam”, the vulnerability set the Internet on fire.

So far, the log4j vulnerability, identified as CVE-2021-44228, has been exploited by all kinds of threat actors, from state-backed hackers to ransomware gangs and others to inject Monero miners into vulnerable systems.

The use of Log4j is rampant among many software products and several vendor reviews have since surfaced. And, it now appears, the “logback” is not that immune either.

Below, we summarize the multiple relevant CVEs identified so far, and some very good reasons to drop log4j version 2.15.0, in favor of 2.16.0.

What should I be concerned about for all CVEs?

It all started last Thursday, December 9, when a Leverage the PoC for the critical zero-day hit from Log4j GitHub.

What followed was vulnerability disclosure and mass scan attacker activity targeting vulnerable servers.

Considering the vast use of Log4j in the majority of Java applications, Log4Shell has quickly become a nightmare for businesses and governments around the world.

You will find below the CVEs in the order of their appearance which you should know:

  • CVE-2021-44228 [Critical]: The original vulnerability ‘Log4Shell’ or ‘logjam’ is a unreliable deserialization fault. Classified as critical in severity, this one gets a 10 on the CVSS at scale and grants remote code execution (RCE) capabilities to unauthenticated attackers, allowing complete control of the system.

    Reported by Chen Zhaojun of Alibaba Cloud Security Team to Apache on November 24, CVE-2021-44228 impacts the default configurations of several Apache frameworks, including Apache Struts2, Apache Solr, Apache Druid, Apache Flink, and others.

    Being the most dangerous of all, this vulnerability lurks in the log4j-core component, limited to versions 2.x: from 2.0-beta9 up to and including 2.14.1. A patch for Log4Shell was deployed in version 2.15.0 but deemed incomplete (keep reading).

    Florian Roth, Threat Analyst, shared the Sigma Rules [1, 2] which can be used as one of the means of defense.

  • CVE-2021-45046 [Low]: Low severity, this is a denial of service (DoS) vulnerability with a score of only 3.7. The vulnerability arose as a result of an incomplete patch that entered in 2.15.0 for CVE-2021-44228. While the patch applied to 2.15.0 largely fixed the flaw, this was not quite the case for some non-default configurations.

    Log4j 2.15.0 makes “best effort” to restrict LDAP JNDI searches to local host by default. However, attackers who control Thread Context Map (MDC) input data can create malicious payloads through JNDI search patterns to cause a DoS attack. This applies to non-default configurations where a non-default template layout using either a context search, for example $$ {ctx: loginId}, or a thread context map template (% X,% mdc or% MDC).

    “Log4j 2.16.0 addresses this issue by removing support for message search templates and disabling JNDI functionality by default,” the NVD advisory states. For those on the 2.12.1 branch, a patch was backported to 2.12.2.

  • CVE-2021-4104 [High]: Did we say that Log4j 2.x versions were vulnerable? What about Log4j 1.x?

    While previously thought to be safe, Log4Shell also found a way to hide in the old Log4j. Essentially, the non-default configuration of Log4j 1.x instances using the JMSAppender class also become susceptible to the unreliable deserialization flaw.

    Although it is a less severe variant of CVE-2021-44228, this CVE nevertheless impacts all versions of the log4j: log4j and org.apache.log4j: log4j components for which only 1.x versions exist. Because these are end of life versions, a patch for the 1.x branch does not exist anywhere, and you have to upgrade to log4j-core 2.16.0.

  • CVE-2021-42550 [Moderate]: This is a vulnerability in the Logback logging framework. Successor of the Log4j 1.x library, Logback claims to pick up “where log4j 1.x left off”.

    Until last week, Logback also boasted this being “unrelated to log4j 2.x, [logback] does not share its vulnerabilities. “

    This assumption quickly faded when it was discovered that CVE-2021-4104 also impacted Log4j 1.x and the possibility of a potential impact on Logback was. assessed. The new versions of Logback, 1.3.0-alpha11 and 1.2.9 addressing this less severe vulnerability have now been published.

  • One more CVE …? Keep reading.

Ditch Log4j 2.15: DNS & RCE exfiltration possible

Log4j 2.15.0 could contain even more serious vulnerabilities than those discovered so far, which is why 2.16.0 is by far a safer bet.

Due to CVE-2021-45046 described above, the maximum impact of the flaw initially appeared to be DoS, but that assumption is evolving, BleepingComputer has learned.

Cloud security company Praetorian has demonstrated how versions of Log4j 2.15.0 can still be misused for DNS data exfiltration from external hosts, and is working with Apache for coordinated disclosure.

In an email interview with BleepingComputer, Praetorian’s senior security engineer, Anthony Weems sheds light on the research:

“The Praetorian blog post is in response to CVE-2021-45046, which applies to Log4j version 2.15. The CVE description indicates that, when using a specific type of template layout, this vulnerability can lead to a denial of service. The reason they say this is only DoS is due to the local host authorization list, “Weems told BleepingComputer.

“We have developed a workaround for this ‘localhost’ authorization list and sent the details to Apache. At a minimum, this means that systems vulnerable to CVE-2021-45046 are not only vulnerable to DoS, but also to exfil DNS of a potentially sensitive environment variables. “

Praetorian shared a PoC video demonstrating just this:

“Apache has confirmed receipt of our item; whether it merits a CVE change or a new CVE is a good question – however, the action required by defenders is clear in either case: move to 2.16.0 where jndi is off by default is the safest course of action and it is the approach we recommend to our customers, ”Praetorian concluded in his statement to BleepingComputer.

Additionally, at the time of writing this article, BleepingComputer has come across several security researchers claiming that it is possible to get a full RCE even with 2.15.0.

“Here is a PoC on how to bypass authorizedLdapHost and Authorized courses check in Log4J 2.15.0. reach the RCE … and bypass Authorized courses just choose a name for a class in the JDK. Deserialization will occur as usual, ”says researcher Márcio Almeida:

Likewise, Alvaro Muñoz of GitHub Security Lab shared success in bypassing fixes made in 2.15.0 to achieve remote code execution:

“As a note, the default settings will not be affected. Search must be enabled by specifying % m {research} or by a method such as CVE-2021-45046, ” said security researcher RyotaK, adding to the search for Muñoz.

The possible worst-case scenario resulting from Log4j 2.15.0 has yet to be fully determined, but suffice it to say that it doesn’t appear to be limited to DoS.

As the situation continues to evolve, organizations and developers are encouraged to upgrade to version 2.16.0 and continue to monitor Apache’s Log4j. advice page for updates.

Previous Warzone RICOCHET anti-cheat has hackers begging for a second chance
Next It's the season to be happy: don't let pirates ruin the holidays | Item