Google Cloud Armor WAF Rule To Help Mitigate CVE-2021-44228 Apache Log4j Vulnerability

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.

 

Partner with aster.cloud
for your next big idea.
Let us know here.

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).

Read More  Are You A Multicloud Engineer Yet? The Case For Building Skills On More Than One Cloud

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.

 

WAF rule in Console

 

 

 

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:

 

gcloud compute security-policies rules create 12345 \
--action=deny-403 \
--security-policy=[cloudArmorPolicyName] \
--expression=evaluatePreconfiguredExpr\(\'cve-canary\'\) \
--description='CVE-2021-44228 and CVE-2021-45046'

 

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

Read More  Learn How To Stream JSON Data Into BigQuery Using The New BigQuery Storage Write API

 

Preview mode in Cloud Armor

 

 

 

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.

 

Example log message of a blocked exploit attempt with verbose logging enabled

 

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.

Read More  How To Get Started With Klaviyo - A Developer's Guide
evaluatePreconfiguredExpr('cve-canary', ['owasp-crs-v030001-id244228-cve'])

 

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.

 

 

By: Emil Kiner (Product Manager, Cloud Armor) and Dave Reisfeld (Network Specialist Manager)
Source: Google Cloud Blog

For enquiries, product placements, sponsorships, and collaborations, connect with us at [email protected]. We'd love to hear from you!
Our humans need coffee too! Your support is highly appreciated, thank you!

Related Topics
You May Also Like