Flash Notice: (UPDATED) Zero-Day Vulnerability - Log4Shell is a Critical Threat to Applications

Overview of Log4shell

Update 12/20/2021 - Third Log4j Vulnerability Patched Over the Weekend - Over the weekend, the Apache security team released another patch for a new vulnerability found in the Log4j logging library. The new vulnerability stems from an incomplete fix for CVE-2021-44228 and can be tracked as CVE-2021-45105, affecting versions 2.0-beta9 to 2.16.0.

CVE-2021-45105 addresses version 2.16.0, which is susceptible to a DoS attack caused by a Stack-Overflow in Context Lookups in the configuration file’s layout patterns. Version 2.16.0 was thought to be the final update for Log4j because it prevented Remote Code Execution (RCE) and Local Code Execution (LCE) exploits from taking place. However, version 2.16.0 does not address crafted input that could manipulate Context Lookup functionality that leads to a stack-overflow and crash.

It’s important to note that CVE-2021-45105 is not a cause for panic. CVE-2021-44228 is exploitable in the default configuration of the logging library, but CVE-2021-45046 and CVE-2021-45105 are not and are less likely to be exploited. According to cyber security analyst, Kevin Beaumont, CVE-2021-45105 only applies in certain “non-default” configurations and it is not being actively exploited in the wild.

As a result of this new discovery, Apache has released a patch to mitigate the vulnerability (version 2.17.0). If you haven’t already, it’s highly recommended that your organization upgrade to the latest version (2.17.0). If that’s not an option, your organization should at least upgrade to 2.16.0 and ensure they aren’t using Context lookups of the form: ${ctx:username}.

Log4j versions 1.x are not affected by this new vulnerability, as they have reached the end of life and are no longer supported. All organizations still using Log4j 1.x should upgrade to Log4j 2 to get the latest updates.

Update (12/14/2021) - Log4Shell: Previous Patch Does NOT Fix - It’s been discovered that the mitigation for CVE-2021-44228 for Apache Log4j 2.15.0 was incomplete in certain non-default configurations. Log4j (Log4Shell) now has a new CVE identification (CVE-2021-45046) and is rated lower in severity (3.7 severity) than CVE-2021-44228 (10 severity) due to the fact that only certain non-default configurations are vulnerable, and the exploit results in Denial-of-Service (DoS) rather than Remote Code Execution (RCE). This latest development could allow attackers with control over Thread Context Map (MDC) to input data when the logging configuration uses a non-default Pattern Layout with a Context Lookup or a Thread Context Map pattern. This allows the attacker to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack. This affects Log4j versions 2.0-beta9 to 2.15.0.

Examples

Context Lookup - $${ctx:loginId}
Thread Context Map pattern - %X, %mdc, or %MDC

Previous mitigations involving configuration do not mitigate this new vulnerability. Upgrading to Log4j 2.16.0 fixes the issue and removes support for message lookup patterns, disabling JNDI by default. To mitigate the issues please implement one of the following techniques:

Java 8 (or later) users should upgrade to release 2.16.0.
Users requiring Java 7 should upgrade to release 2.12.2 when it becomes available (work in progress, expected to be available soon).
Otherwise, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Additionally, some versions of Apache Log4j contain a different vulnerability. When an attacker has write access to the Log4j configuration, JMSAppender in Log4j 1.2 is vulnerable to deserialization of untrusted data. This means that an attacker can provide TopicBindingName and TopicConnectionFactoryBindingName configurations that cause JMSAppender to perform JNDI requests, resulting in remote code execution. This makes the vulnerability very similar to CVE-2021-44228. However, CVE-2021-4104 only affects Apache Log4j 1.2, which reached the end of life in August 2015. Upgrading to Log4j 2.16.0 will address this issue and numerous others from previous versions of the software.

Update (12/13/2021) - Last Friday, December 10, 2021, we learned that a critical zero-day vulnerability was found in the Apache Log4j Java-based logging library. CVE-2021-44228, now known as Log4Shell, is an unauthenticated RCE vulnerability that allows for complete system takeover on systems with Log4j 2.0-beta9 up to 2.14.1.

Over the weekend, further news broke regarding Log4Shell, and we now know that the first attacks were observed two weeks before they were publicly disclosed. Mass exploitation began over the weekend and originated from professional crypto-mining and DDoS botnets, like Muhstik and Mirai. Additionally, Microsoft observed Log4Shell being used to deploy webshells with Cobalt Strike beacons, which are backdoors. Please see below for more information regarding the products we offer and how CVE-2021-44228 affects them.

Avertium engineering teams rolled out IOCs and detections for Log4shell Friday night. Our analyst teams have been vigilant over the weekend alerting customers if any evidence of the exploit is found in their environments. We are currently following up with all of our tech vendors to ensure that all affected applications and services are secure. Please see the table below for details and link where you can find further information from each vendor.

Log4Shell Vendor Status
Vendor	Product	Log4Shell Status	Link
Sophos	Central	Not Impacted	Sophos.com
Sophos	Firewalls	Not Vulnerable	Sophos.com
Sophos	SUM UTM Manager	Not Vulnerable	Sophos.com
SentinelOne	EDR Agent	Not Vulnerable	SentinelOne.com
SentinelOne	Cloud Manager	Not Vulnerable	SentinelOne.com
FortiNet	EDR Agent	Not Vulnerable	Fortiguard.com
FortiNet	EDR Cloud	Remediated	Fortiguard.com
FortiNet	FortiEDR Portal	Pending Fix 12-18-21	Fortiguard.com
FortiNet	FortiSIEM	Mitigated	Fortiguard.com
LogRhythm	LogRhythm Appliance	Mitigated	LogRhythm.com
LogRhythm	LogRhythm Cloud	Mitigated	LogRhythm.com
BlackKite	BlackKite	Not Vulnerable	BlackKite.com
HelpSystems	DDI RNA	Not Vulnerable	Confirmed via email
HelpSystems	DDI Cloud Manager	Not Vulnerable	Confirmed via email
Microsoft	Sentinel	Not Vulnerable	Microsoft.com
Microsoft	Defender for Endpoint	Not Vulnerable	Microsoft.com
AlienVault	USM Appliance	Not Impacted	AlienVault.com
AlienVault	USM Anywhere	Log4j Present but not vulnerable	Github.com
VMware	CarbonBlack	Mitigated	CarbonBlack.com
Avertium	Breach Radar	Mitigated	Internal Confirmation
Okta	Okta Verify	Not Vulnerable	Okta.com
Cisco	CiscoAMP	Investigating	Cisco.com
Wazuh	Wazuh	Mitigated	Confirmed via email

How Avertium is Protecting Our Clients:

Avertium is actively hunting for evidence of vulnerable or exploited Log4j instances in customer environments.
Avertium is publishing detectors for synchronizing IOCs of malicious scanning activity associated with the Log4Shell vulnerability to all customer SIEMs. Detections published for CVE-2021-44228 are still effective.
Avertium is conducting Endpoint research and reconnaissance for strings associated with this exploit.
Avertium development teams are performing an inventory and assessment of all internally developed software that uses Java, to ensure the vulnerability does not exist or is mitigated.
Avertium is reaching out to our technology vendors to verify and mitigate any potential exposure to this vulnerability.
Avertium has third-party vendor risk assessment services that you can utilize to help protect you from this vulnerability. Please contact your Account Executive or Service Delivery Manager for further details.

Avertium's recommendations

Please patch your devices as soon as possible with the latest version of Log4j. Apache has released version 2.16.0 here.
Please follow the instructions above to mitigate CVE-2021-45046
Apache Log4j recommends the following temporary mitigation if upgrading is not possible:
- In releases >=2.10, this behavior can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true. With the release of CVE-2021-45046 this is no longer sufficient!
- For releases from 2.0-beta9 to 2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
Avertium recommends that your organization complete inventory and assessment of internally developed code and external vendor tools.