Apache Log4j Security Vulnerabilities

 

This page lists all the security vulnerabilities fixed in released versions of Apache Log4j 2. Each vulnerability is given a security impact rating by the Apache Logging security team. Note that this rating may vary from platform to platform. We also list the versions of Apache Log4j the flaw is known to affect, and where a flaw has not been verified list the version with a question mark.

Log4j 1.x has reached End of Life in 2015 and is no longer supported. Vulnerabilities reported after August 2015 against Log4j 1.x were not checked and will not be fixed. Users should upgrade to Log4j 2 to obtain security fixes.

Binary patches are never provided. If you need to apply a source code patch, use the building instructions for the Apache Log4j version that you are using. For Log4j 2 these can be found in BUILDING.md located in the root subdirectory of the source distribution.

If you need help on building or configuring Log4j or other help on following the instructions to mitigate the known vulnerabilities listed here, please subscribe to, and send your questions to the public Log4j Users mailing list.

If you have encountered an unlisted security vulnerability or other unexpected behaviour that has security impact, or if the descriptions here are incomplete, please report them privately to the Log4j Security Team. Thank you!

Fixed in Log4j 2.17.1 (Java 8), 2.12.4 (Java 7) and 2.3.2 (Java 6)

CVE-2021-44832: Apache Log4j2 vulnerable to RCE via JDBC Appender when attacker controls configuration.

CVE-2021-44832	Remote Code Execution
Severity	Moderate
Base CVSS Score	6.6 (AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H)
Versions Affected	All versions from 2.0-alpha7 to 2.17.0, excluding 2.3.2 and 2.12.4

Description

Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack where an attacker with permission to modify the logging configuration file can construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can execute remote code. This issue is fixed by limiting JNDI data source names to the java protocol in Log4j2 versions 2.17.1, 2.12.4, and 2.3.2.

Mitigation

Log4j 1.x mitigation

Log4j 1.x is not impacted by this vulnerability.

Log4j 2.x mitigation

Upgrade to Log4j 2.3.2 (for Java 6), 2.12.4 (for Java 7), or 2.17.1 (for Java 8 and later).

In prior releases confirm that if the JDBC Appender is being used it is not configured to use any protocol other than Java.

Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability.

Also note that Apache Log4j is the only Logging Services subproject affected by this vulnerability. Other projects like Log4net and Log4cxx are not impacted by this.

Release Details

From version 2.17.1, (and 2.12.4 and 2.3.2 for Java 7 and Java 6), the JDBC Appender will use JndiManager and will require the log4j2.enableJndiJdbc system property to contain a value of true for JNDI to be enabled.

The property to enable JNDI has been renamed from ‘log4j2.enableJndi’ to three separate properties: log4j2.enableJndiLookup, log4j2.enableJndiJms, and log4j2.enableJndiContextSelector.

JNDI functionality has been hardened in these versions: 2.3.1, 2.12.2, 2.12.3 or 2.17.0: from these versions onwards, support for the LDAP protocol has been removed and only the JAVA protocol is supported in JNDI connections.

Work in progress

The Log4j team will continue to actively update this page as more information becomes known.

Credit

No credit is being awarded for this issue.

References

• CVE-2021-44832

Fixed in Log4j 2.17.0 (Java 8), 2.12.3 (Java 7) and 2.3.1 (Java 6)

CVE-2021-45105: Apache Log4j2 does not always protect from infinite recursion in lookup evaluation

CVE-2021-45105	Denial of Service
Severity	Moderate
Base CVSS Score	5.9 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H)
Versions Affected	All versions from 2.0-beta9 to 2.16.0, excluding 2.12.3

Description

Apache Log4j2 versions 2.0-alpha1 through 2.16.0, excluding 2.12.3, did not protect from uncontrolled recursion from self-referential lookups. When the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC) input data can craft malicious input data that contains a recursive lookup, resulting in a StackOverflowError that will terminate the process. This is also known as a DOS (Denial of Service) attack.

Mitigation

Log4j 1.x mitigation

Log4j 1.x is not impacted by this vulnerability.

Log4j 2.x mitigation

Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or 2.17.0 (for Java 8 and later).

Alternatively, this infinite recursion issue can be mitigated in configuration:

• In PatternLayout in the logging configuration, replace Context Lookups like ${ctx:loginId} or $${ctx:loginId} with Thread Context Map patterns (%X, %mdc, or %MDC).
• Otherwise, in the configuration, remove references to Context Lookups like ${ctx:loginId} or $${ctx:loginId} where they originate from sources external to the application such as HTTP headers or user input.

Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability.

Also note that Apache Log4j is the only Logging Services subproject affected by this vulnerability. Other projects like Log4net and Log4cxx are not impacted by this.

Release Details

From version 2.17.0, (and 2.12.3 and 2.3.1 for Java 7 and Java 6), only lookup strings in configuration are expanded recursively; in any other usage, only the top-level lookup is resolved, and any nested lookups are not resolved.

The property to enable JNDI has been renamed from ‘log4j2.enableJndi’ to three separate properties: ‘log4j2.enableJndiLookup’, ‘log4j2.enableJndiJms’, and ‘log4j2.enableJndiContextSelector’.

JNDI functionality has been hardened in these versions: 2.3.1, 2.12.2, 2.12.3 or 2.17.0: from these versions onwards, support for the LDAP protocol has been removed and only the JAVA protocol is supported in JNDI connections.

Work in progress

The Log4j team will continue to actively update this page as more information becomes known.

Credit

Independently discovered by Hideki Okamoto of Akamai Technologies, Guy Lederfein of Trend Micro Research working with Trend Micro’s Zero Day Initiative, and another anonymous vulnerability researcher.

References

• CVE-2021-45105
• LOG4J2-3230

Fixed in Log4j 2.16.0 (Java 8) and Log4j 2.12.2 (Java 7)

CVE-2021-45046: Apache Log4j2 Thread Context Lookup Pattern vulnerable to remote code execution in certain non-default configurations

CVE-2021-45046	Remote Code Execution
Severity	Critical
Base CVSS Score	9.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H)
Versions Affected	All versions from 2.0-beta9 to 2.15.0, excluding 2.12.2

Description

It was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. When the logging configuration uses a non-default Pattern Layout with a Context Lookup (for example, $${ctx:loginId}), attackers with control over Thread Context Map (MDC) input data can craft malicious input data using a JNDI Lookup pattern, resulting in an information leak and remote code execution in some environments and local code execution in all environments; remote code execution has been demonstrated on MacOS, Fedora, Arch Linux, and Alpine Linux.

Mitigation

Log4j 1.x mitigation

Log4j 1.x is not impacted by this vulnerability.

Log4j 2.x mitigation

Implement one of the following mitigation techniques:

• Upgrade to Log4j 2.3.1 (for Java 6), 2.12.3 (for Java 7), or 2.17.0 (for Java 8 and later).
• Otherwise, in any release other than 2.16.0, you may remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Users are advised not to enable JNDI in Log4j 2.16.0, since it still allows LDAP connections. If the JMS Appender is required, use one of these versions: 2.3.1, 2.12.2, 2.12.3 or 2.17.0: from these versions onwards, only the JAVA protocol is supported in JNDI connections.

Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-api JAR file without the log4j-core JAR file are not impacted by this vulnerability.

Also note that Apache Log4j is the only Logging Services subproject affected by this vulnerability. Other projects like Log4net and Log4cxx are not impacted by this.

APAC businesses still battling U.S. Log4Shell attacks

 Log4Shell attacks prove a continued and complex threat to APAC businesses, according to Barracuda. The company has found the injection bug is still leaving businesses in Asia-Pacific vulnerable to log injection attacks.

Log4Shell was first publicly disclosed in December 2021. It is a software vulnerability specifically targeting Log4j, a Java-based logging audit framework that is an Apache project. Log4j is an open-source Java package used to support activity-logging in many popular Java applications. 

The New Zealand CERT says, "Log4j has an unauthenticated RCE vulnerability if a user-controlled string is logged. This could allow the attacker full control of the affected server. Reports from online users show that this is being actively exploited in the wild, and that proof-of-concept code has been published."

While not all software written in Java is vulnerable, the affected package is widely used by developers across multiple organisations.

The vulnerability was given the highest severity rating possible when discovered, by the National Vulnerability Database, given the ease that malicious attackers can exploit it.

Since then, Barracuda researchers have been analysing the attacks and payloads detected and found the volume of attacks remains relatively constant and is unlikely to diminish any time soon. The company says the vulnerability allows a remote attacker to take control of a device on the internet if running specific versions of Log4j. Logging is a critical component of most applications and systems because it allows developers and system administrators to verify that software is working properly and identify more specific details when it is not.

The researchers also say they have made interesting insights into the location of the original attacks. The majority of attacks came from IP addresses in the U.S., and half of those were associated with AWS, Azure and other data centers. Attacks were also sent from Japan, Germany, Netherlands, and Russia. 

"These were the IPs that performed scans and attempted intrusions. Actual payloads would have been delivered from other compromised websites or VPS hosts," says Barracuda senior product marketing manager, Applications and Cloud Security, Tushar Richabadas.

"Given the popularity of the software, the exploitability of the vulnerability and the payoff when a compromise happens, we expect to see this attack pattern continue, at least for the short term."

He says the best way to protect against Log4shell is to upgrade to the latest version of log4j. Maintaining up-to-date software and libraries helps ensure that vulnerabilities are patched. Given the growing number of vulnerabilities found in web applications, it is getting progressively more complex to protect against attacks. 

However, Richabadas says all-in-one solutions are now available, including WAF/WAF-as-a-Service solutions, also known as Web Application and API Protection (WAAP) services, which can help protect web applications by providing all the latest security solutions.

This dangerous new malware is attacking Windows devices via infected USB drives

Researchers have found new malware that is attacking Windows devices, but they’re not yet sure why exactly it does what it does.

Cybersecurity researchers from Red Canary recently discovered a new worm-like malware that spreads offline, via infected USB drives.

The researchers did not name this particular malware, but rather linked it to a “cluster of malicious activity” they named Raspberry Robin.

The malware was found in different endpoints in multiple networks belonging to organizations in technology and manufacturing industries.

After analyzing an infected thumb drive, the researchers discovered that the worm spreads to new devices via a malicious .LNK file. Once the victim plugs in the USB drive, the worm will trigger a new process through cmd.exe, and run the file. 

To reach out to its C2 server, the researchers further state, the worm uses Microsoft Standard Installer (msiexec.exe). They speculate the server is hosted on a compromised QNAP device, with TOR exit nodes being used as extra C2 infrastructure.

"While msiexec.exe downloads and executes legitimate installer packages, adversaries also leverage it to deliver malware," the report states. "Raspberry Robin uses msiexec.exe to attempt external network communication to a malicious domain for C2 purposes."

But one of the key questions remains unanswered - what’s the whole point?, as the researchers are yet to discover the malware’s endgame. “Absent additional information on later-stage activity, it’s difficult to make inferences on the goal or goals of these campaigns,” the expert said.

What’s more, they found that it installs a malicious DLL file, probably to establish persistence.

"We also don't know why Raspberry Robin installs a malicious DLL," the researchers said. "One hypothesis is that it may be an attempt to establish persistence on an infected system, though additional information is required to build confidence in that hypothesis."

• Keep safe from worms and malware with the best firewalls around

 

This New Fileless Malware Hides Shellcode in Windows Event Logs

 

 

 

 

 

 

 

A new malicious campaign has been spotted taking advantage of Windows event logs to stash chunks of shellcode for the first time in the wild.

"It allows the 'fileless' last stage trojan to be hidden from plain sight in the file system," Kaspersky researcher Denis Legezo said in a technical write-up published this week.

The stealthy infection process, not attributed to a known actor, is believed to have commenced in September 2021 when the intended targets were lured into downloading compressed .RAR files containing Cobalt Strike and Silent Break.

The adversary simulation software modules are then used as a launchpad to inject code into Windows system processes or trusted applications.

Also notable is the use of anti-detection wrappers as part of the toolset, suggesting an attempt on the part of the operators to fly under the radar.

 

 

 

 

 

One of the key methods is to keep encrypted shellcode containing the next-stage malware as 8KB pieces in event logs, a never-before-seen technique in real-world attacks, that's then combined and executed.

The final payload is a set of trojans that employ two different communication mechanisms — HTTP with RC4 encryption and unencrypted with named pipes — which allow it to run arbitrary commands, download files from a URL, escalate privileges, and take screenshots.

Another indicator of the threat actor's evasion tactics is the use of information gleaned from initial reconnaissance to develop succeeding stages of the attack chain, including the use of a remote server that mimics legitimate software used by the victim.

"The actor behind this campaign is quite capable," Legezo said. "The code is quite unique, with no similarities to known malware."

The disclosure comes as Sysdig researchers demonstrated a way to compromise read-only containers with fileless malware that's executed in-memory by leveraging a critical flaw in Redis servers.