Editor’s note: This post was updated on 12/17/21 at 2:45pm PST.
In this post, we provide recommendations from the Google Cybersecurity Action Team and discuss Google Cloud and Chronicle solutions to help security teams to manage the risk of the Apache “Log4j 2” vulnerability (CVE-2021-44228 and CVE-2021-45046).
For the latest updates on our assessment of the potential impact of the vulnerability on Google Cloud products and services, please visit Google Cloud’s security advisory page.
The Apache Log4j 2 utility is an open source Apache framework that is a commonly used component for logging requests. On December 9, 2021, a vulnerability was reported that could allow a system running Apache Log4j version 2.15 or below to be compromised and allow an attacker to execute arbitrary code on the vulnerable server. On December 10th, 2021, NIST published a critical CVE in the National Vulnerability Database identifying this as CVE-2021-44228. The official CVSS base severity score has been determined as a severity of 10. We strongly encourage customers who manage environments containing Log4j 2 to update to the latest version or take the mitigation actions outlined in this post. The Cybersecurity and Infrastructure Security Agency (CISA) released additional recommendations for immediate steps regarding this vulnerability.
The “Log4j 2 vulnerability” can be exploited by sending specially crafted log messages into Log4j 2. The attacker does this by leveraging the Java Naming and Directory Interface (JNDI) – which is a Java abstraction layer included by default in the Java SE Platform that allows a Java application to retrieve data from directory services (such as LDAP). JNDI uses HTTP URIs to resolve to a specific directory service – and the URI can be adjusted as needed to resolve to the right directory location. Using Log4j 2, an attacker sending a log message with a specially crafted URI can cause the application to execute arbitrary code (such as by providing a Base64 encoded script in the path).
This is due to specific behavior in Log4j 2 that allows for the input of variable data into the log (called Lookups). In a Lookup, the reference is queried and evaluated for input into the log. By using this feature during an exploit, the attacker uses the URI input to instruct Log4j 2 to resolve an object they input (such as an encoded script). This issue has been resolved in the latest version of Log4j 2.
Updates and Recommendations to Identify, Detect & Protect
In addition to updating Log4j 2, some Google Cloud Security products can help detect and temporarily mitigate exploitation until the patch can be applied. Additionally, if you have third party WAF, IDS/IPS, and/or NDR solutions deployed in Google Cloud, please consult with your vendors for more guidance related to this vulnerability.
To identify potentially impacted systems we recommend the use of a vulnerability scanner. These tools have reported identifying the vulnerability referenced in National Vulnerability Database (NVD) and will help to locate impacted systems.
Where possible, we recommend implementing all of the below for a layered defense in depth strategy.
Cloud Armor WAF Log4j 2 Detection and Blocking Rules
Relative to Log4j 2, Cloud Armor helps mitigate threats for applications or services behind external HTTP(S) load balancers. You can enable Cloud Armor through Cloud Console > Network Security, or via API. Cloud Armor’s WAF rules can be configured to detect, or detect and block requests. Cloud Armor customers can now deploy a new preconfigured WAF rule that will help detect and, optionally, block commonly attempted exploits of CVE-2021-44228 and CVE-2021-45046 while you are patching your systems. To learn more about addressing the Apache Log4j 2 vulnerability with Cloud Armor, please read this blog article.
Threat Hunting and investigation tools can be used to look at historical data and determine if exploitation was attempted – or can be used as vehicles for monitoring active exploitation. Chronicle is Google’s threat hunting tool that provides extended event collection across cloud and on-prem (such as EDR logs, firewall logs, etc). If you are using Chronicle for log ingestion/SIEM and have historical event data stored (Chronicle retains 12 months of data by default) you can search for historical exploit attempts. Customers should search for events that contain “jndi” and a combination of strings that follow including “ldap”, “rmi”, “ldaps”, or “dns”, generated from HTTP requests, which correspond to possible Log4j 2 exploitation patterns.
For example – this syntax could be used in a Yara-L rule: