Cybersecurity Announcement - Log4J Zero Day
On December 9, 2021, security researchers made public a zero day vulnerability in Log4J, a Java logging tool maintained by the Apache Foundation.
Update: Log4J version 2.17.1 released
The Apache Logging Services Project released version 2.17.1 of Log4J on 12/27/2021 to address a new security vulnerability (CVE-2021-44832). The vulnerability allows attackers with permission to modify the logging configuration file to construct a malicious configuration using JDBC Appender.
Cybersecurity recommends if you have not yet already patched to 2.16.0, to upgrade to Log4j 2.3.2 (for Java 6), 2.12.4 (for Java 7), or 2.17.1 (for Java 8 and later) during normal patching and change cycles.
Update: Log4J version 2.17.0 released
The Apache Logging Services Project released version 2.17.0 of Log4J to address another new security vulnerability (CVE-2021-45105). Log4j versions 2.0-alpha1 through 2.16.0 (excluding 2.12.3) do not protect from uncontrolled recursion from self-referential lookups which could result in a Denial of Service (DOS) condition.
Cybersecurity recommends if you have not yet already patched for 2.16.0, to proceed with patching to version 2.17.0. Otherwise, upgrade to 2.17.0 (for users of Java 8 and later) or review mitigation options during normal patching and change cycles.
Cybersecurity Announcement: New Guidance on Log4J Remediation
About the Event:
The Apache Logging Services Project has revised the CVSS score for CVE-2021-45046 to Critical (9) and revised their advice on mitigations for versions 2.14.1 or lower. Additionally, they released version 2.12.2 of Log4J for use with Java version 7.
Actions to Take:
Cybersecurity recommends patching Log4J to version 2.16.0 (for Java 8) or 2.12.2 (for Java 7) as soon as possible.
If you are unable to upgrade, the only mitigation that the Apache Logging Service Project now recommends is removing the JndiLookup class from the log4j-core jar.
Remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
If you have already upgraded to Log4J 2.15.0, Cybersecurity is changing our recommendation from patch on your normal cycle to patch as soon as possible.
CVE-2021-45046 was originally believed to allow a denial of service in Log4J 2.15.0 if certain non-default configurations were used. Security researchers have since found ways to leverage this vulnerability to allow remote code execution.
Additional research on Log4J 2.15.0 also showed that previous mitigations (specifically setting system property log4j2.formatMsgNoLookups or environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true) did not provide sufficient protection as there are still code paths in Log4J where message lookups could occur.
Cybersecurity Analyst: Allen Monette
Update: Log4J version 2.16.0 released
The Apache Logging Services Project released version 2.16.0 of Log4J to address a new security vulnerability (CVE-2021-45046). The vulnerability allows for a denial of service if Log4J is run in certain non-default configurations.
Cybersecurity recommends using the 2.16.0 patch if you have not already upgraded Log4J. If you are already on version 2.15.0, upgrade to 2.16.0 on your normal patch cycle unless you use the non-default configurations.
An attacker with control over Thread Context Map (MDC) input data when logging configuration uses a non-default Pattern Layout with either a Context Lookup or a Thread Context Map pattern, can craft a malicious input data using a JNDI Lookup pattern resulting in a denial of service condition. https://logging.apache.org/log4j/2.x/index.html
Update on Log4J situation:
Cybersecurity continues to see scans and attacks leveraging the Log4J vulnerability (CVE-2021-44228) hitting campus networks throughout the weekend and into today. It is critical that IT staff review IT assets, particularly software, in your environment for Log4J use. Where you find it, check with the vendor for updates or official mitigations. If neither are available, you need to review the compensating controls that are in place to protect the asset.
Again, Log4J CVE-2021-44228 is actively under attack on campus. Cybersecurity strongly recommends taking action on this issue immediately.
Cybersecurity is attempting to maintain a list of known-vulnerable applications and updated information in this KB doc. Please check the References and Known Impacted Applications sections for new links.
Additional information from Qualys webcast: The Log4J API has been confirmed not vulnerable.
Apache Logging Services Project statement on version prior to 2.x: "Please note that Log4j 1.x has reached end of life 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."
Some versions of Java may provide protections that help to reduce the impact of attacks on Log4J: Java 8u121
protects against RCE by defaulting
"com.sun.jndi.cosnaming.object.trustURLCodebase" to "false". (https://github.com/advisories/GHSA-jfh8-c2jp-5v3q
About the Event
On December 9, 2021, security researchers made public a zero day vulnerability in versions of Log4J prior to 2.15.0, a Java logging tool maintained by the Apache Foundation. This vulnerability is sometimes referred to as Log4Shell and is documented in CVE-2021-44228.
Actions to Consider
Cybersecurity recommends patching Log4j to version 2.15 or applying the recommended mitigations prior to the weekend. *The current version available for download on Apache's website is version 2.15 rc2.
If patching is not possible, Cybersecurity recommends applying one of the following mitigations:
- Set the system property "log4j2.formatMsgNoLookups" to "true"
- Remove JndiLookup class from the classpath
If exploited, the attacker can execute remote code on the server running the vulnerable version of Log4j. Successful attacks can allow attackers to redirect incoming JNDI lookups to a remote codebase and force the vulnerable sever to execute malicious code. Cybersecurity is aware of active exploits in the wild for this vulnerability and has seen scanning activity on campus networks.
Known impacted applications
The Cybersecurity and Infrastructure Security Agency (CISA - https://www.cisa.gov/
) maintains a list of vulnerable products here:
Cybersecurity is aware of the following applications commonly used across campus that are impacted by this vulnerability
Palo Alto Networks:
Puppet, specifically Continuous Delivery for Puppet Enterprise (CD for PE):
For additional applications, see: