Updated: 12/20 - 11:30AM PST
On Dec 18, 2021, Apache released another log4j patch addressing a newly identified denial of service (DoS) vulnerability (CVE-2021-45105). Log4j versions 2.0-alpha1 through 2.16.0 do not adequately protect from uncontrolled recursion. An attacker can craft malicious input containing a recursive lookup, resulting in a StackOverflowError that will terminate the process, causing a denial of service. For organizations maintaining Java applications utilizing log4j, updating version 2.17.0(Java 8) or 2.12.3(Java7) is highly recommended. For organizations using Java-based products or solutions, please work with your vendors for updates or mitigations.
*Note that this vulnerability impacts only the log4j-core JAR file. This vulnerability does not impact applications using only the log4j-api JAR file without the log4j-core JAR file.*
Local Detection Scripts have been updated to help identify affected assets. Please see Detection Methods below.
On Dec. 9, 2021, a remote code execution (RCE) vulnerability in Apache log4j 2 was identified. Public proof of concept (PoC) code was released, which shows the vulnerability is extremely simple to exploit. By submitting a specially crafted request to a vulnerable system, an attacker is able to instruct that system to download and subsequently execute a malicious payload. Due to the prevalent use of the Log4j library in software and products as well as the easy of exploitability, this vulnerability has received a CVE score of 10. A large amount of scanning activity for CVE-2021-44228 has begun on the internet. We highly recommend that organizations upgrade to the latest version (2.15.0-rc2) of Apache log4j 2 for all systems.
The Log4j library is used in many applications, and products may be packaged in multiple solutions. Tec-Refresh is actively investigating the situation and is working with vendor partners to identify the impact and resolution of their products.
** MSP/MSSP customers: A Tec-Refresh engineer will be reaching out to your team to triage the situation by working to identify affected assets and begin remediation. ***
Apache has released version 2.16.0 which completely removes support for Message Lookups and disables JNDI by default.
Some of the changes in Log4j 2.16.0 include:
- Removed Message Lookups. This is a hardening related to changes made
to prevent CVE-2021-44228. While this change is recommended, it is NOT
required to fix CVE-2021-44228.
- While release 2.15.0 removed the ability to resolve Lookups and log
messages and addressed issues with how JNDI is accessed, the Log4j
team feels that having JNDI enabled by default introduces an undue
risk for our users. Starting in version 2.16.0, JNDI functionality is
disabled by default and can be re-enabled via the log4j2.enableJndi
system property. Use of JNDI in an unprotected context is a large
security risk and should be treated as such in both this library and
all other Java libraries using JNDI.
- Prior to version 2.15.0, Log4j would automatically resolve Lookups
contained in the message or its parameters in the Pattern Layout. This
behavior is no longer the default and must be enabled by specifying
Apache log4j is an open source Java-based logging framework, which is leveraged within many Java applications. Apache log4j is widely used in many popular software applications, such as Apache Struts, ElasticSearch, Redis, Kafka and others.
Exploit code for the CVE-2021-44228 vulnerability has been made publicly available. Any user input hosted by a Java application using the vulnerable version of log4j may be vulnerable to this attack.
The following a community shared YARA and Sigma rules. These rules can be used on endpoint detection software or SIEMs to help identify exploitation attempts.
The following scripts can help detect the presence of vulnerable versions of Log4j.
The Log4j library is used in many applications, and products. The following crowdsourced list can be used as a starting point. https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592
The following is a list of Tec-Refresh Vendor Partners:
Partial – SilverPeak Orchestrator only.
Partial – Core products like Exos are unaffected
Yes – Patch released for 8.1, 8.2 and 8.3
|Partial – Core products like FortiOS unaffected.|
Yes – Patch released for 3.x and 4.x
Partial – Panorama affected
Yes – VCenter, NSX, vRealize, etc.
- Patch Released for versions 8.1.4, 8.2.2, and 8.3.
- Main Article: https://forescout.sharepoint.com/:f:/s/FS-External/EnBJgeV3dWdIl05AnEMXGMgBlkxot-SIkvBuYgtwArj8vQ?e=5nVxiG
- 8.1.4 – https://forescout.sharepoint.com/:f:/s/FS-External/Em2Lpxq492dIil5pvcKRnTYBfDvZKutY1KLt8V8mzkG2GQ?e=5yG09F
- 8.2.2 – https://forescout.sharepoint.com/:f:/s/FS-External/Epl95GZ0TLpJnILX3MZplfEBNeImm_wdUOcC-0vvrehLYA?e=i5E1KN
- 8.3 – https://forescout.sharepoint.com/:f:/s/FS-External/Eonprce7wP1FrTtfr0eiAo0BRJxfmkmx77kJ9w5hWMDAfg?e=hmOU9e
- Patch available for v3.x and v4.x
- Several products impacted including vCenter,vRealize,NSX Horizon and Airwatch (on-prem)
Partially Impacted Products:
- Only Silver Peak Orchestrator is impacted by this vulnerability.
- Extreme Networks
- Most core products including EXOS, WING, ExtremeWiFi and ExtremeControl are not impacted by this vulnerability.
- Palo Alto
Identify assets using log4j and update to released 2.17.0. A large number of these affected assets will need to receive patch from vendors. Work with these vendors to install the required patch.
For further assistance please reach out to our team via firstname.lastname@example.org