Google Cloud Armor WAF rule to help mitigate Apache Log4j vulnerability
Emil Kiner
Senior Product Manager, Cloud Armor
Dave Reisfeld
Customer Engineering Manager - Network Specialist
Editor's note:
- As of 12/16/2021 at 12pm PST, this post was updated to include more information about the latest NIST publication, CVE-2021-45046. The existing Cloud Armor ‘cve-canary’ rule offers the same level of protection for the new CVE.
- As of 12/13/2021 at 5:30pm PST, this post was updated to include more information about how our rules function and instructions on how to tune them.
- As of 12/11/2021 at 5:30pm PST, this post was updated to include more information about the new Cloud Armor WAF rules and an explanation of the log snippet screenshot.
NIST has announced a recent vulnerability (CVE-2021-44228) in the Apache Log4j library. To help mitigate the effects of this vulnerability, Google Cloud Armor customers can now deploy a new preconfigured WAF rule that will help detect and, optionally, block attempted exploits of CVE-2021-44228.
Background
The Apache Log4j utility 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 December 10, 2021, NIST published a critical Common Vulnerabilities and Exposure alert, CVE-2021-44228. More specifically, JNDI features used in configuration, log messages, and parameters do not protect against attacker controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from remote servers when message lookup substitution is enabled.
Customers should look to upgrade to the latest version of Log4j 2 as soon as possible.You can determine your exposure by reading further details on the NIST website (CVE-2021-4428 and CVE-2021-45046).
Addressing Apache Log4j vulnerability with Cloud Armor
Google Cloud’s Cloud Armor provides Denial of Service and Web Application Firewall (WAF) protection for applications and services hosted on Google Cloud, on your premises, or hosted elsewhere. The Cloud Armor team has worked closely with the Google Cybersecurity Action Team team to analyze this issue and prepare a response.
In an attempt to help our customers address the Log4j vulnerability, we have introduced a new preconfigured WAF rule called “cve-canary” which can help detect and block exploit attempts of CVE-2021-44228 and CVE-2021-45046. Cloud Armor customers can deploy the new rule into a new or existing Cloud Armor security policy following the below instructions.
In order to detect or help mitigate exploit attempts of this CVE, you will need to create a new rule in your Cloud Armor security policy leveraging the preconfigured WAF rules called “cve-canary”. The rule can be created and inserted into a new or existing Cloud Armor security policy via the Google Cloud Console or the gCloud CLI.
A sample gCloud command line to create a rule with a deny action and priority 12345 which blocks the exploit attempts into an existing security policy is as follows:
Monitoring, detecting, and analyzing potential threats
If you need to monitor your Cloud Armor protected endpoints for exploit attempts without necessarily blocking the traffic, you can deploy the above rule in preview mode. Deploying the rule in preview mode will allow you to receive Cloud Logging event logs that the rule was triggered but Cloud Armor will not block the request. To configure preview mode for any rule, you can set the preview flag to enabled in the UI or CLI
To analyze suspicious requests you can enable Cloud Armor’s verbose logging capability in the relevant policy. With verbose logging enabled, Cloud Armor’s logs will contain additional information about where in the incoming request the suspicious signature appeared as well as a snippet of the suspicious signature and the field it appeared in.
The above is one example of the log generated from a simple exploit attempt with a snippet of the suspicious message in the matchedFieldValue field. The Cloud Armor WAF rules use a variety of techniques to detect attempted obfuscations and bypasses within attempted exploits of CVE-2021-44228 and CVE-2021-45046. The WAF rules in Cloud Armor are not guaranteed to detect all possible exploit attempts but are being updated as industry knowledge of this vulnerability develops.
Finally, if your protected workload receives requests with content-type=’application/json’ like a REST API, then you will need to enable JSON parsing in your security policy to ensure Cloud Armor parses the JSON in a POST request’s body to detect exploit attempts.
Tuning Cloud Armor’s mitigations for the log4j vulnerability(updated 12/13/2021)
As we’ve been updating our “cve-canary” WAF rule over the last several days, we have provided the ability to tune this rule like our other pre-configured WAF rules to find the right balance with rule sensitivity and potential noise.
With the “cve-canary” rule, Cloud Armor inspects for log4j exploit attempts in the HTTP request headers, URL, and body. Deploying the rule as described above will enable all existing signature ids and includes all future updates to this rule. However, if you find that the rule is too noisy based on the unique context of your applications, you can tune down some of the more sensitive signatures. To disable individual signature ids within the rule you can update your Cloud Armor rule and pass in the signature ids you wish to disable as indicated in the below example.
For more details, consult the Cloud Armor rule tuning guide.
More detailed Cloud Armor product documentation for configuring the above capabilities is available here:
Please contact Google Cloud’s technical support or your Google Cloud account team for assistance with applying the mitigation steps described above. Additionally, you can seek support assistance in the Google Cloud Platform Community Slack Channel under gcp-security for non-urgent questions.
