skip to Main Content

How to Virtual Patch LOG4J in AWS, AZURE, GCP, and OCI

Also, see our second blog titled: “Log4Shell Observations: Why Protecting Workloads with Native, Layered Defense Is Essential”

LOG4J Overview

When news of CVE-2021-44228 hit mainstream media, every network defender collectively sighed, “It’s always on a Friday.” A zero day RCE (remote-code-execution) vulnerability in the open-source logging library Log4j2 poses a critical risk to much of the Internet as it is packaged within Apache and used by many Java applications.

In late November 2021, Alibaba’s Cloud Security Team reported the vulnerability to Apache. On December 9th, 2021, a publicly-available POC (proof-of-concept) was released on GitHub. Log4j2 versions between 2.0 and 2.14.1 are impacted by CVE-2021-44228, also known as Log4Shell.

Valtix Security Researchers have observed active exploitation and reconnaissance behavior related to CVE-2021-44228 since 12/10/21. A noticeable increase in exploitation attempts began on 12/12/21, as more community tools became publicly available for download.

Valtix customers with virtual patching enabled mitigate exploitation by auto-updating to Log4j2 version 2.15.0. Valtix customers with automatic updates for IDS/IPS rules and who have IDS/IPS in prevent mode, mitigate exploitation of CVE-2021-44228. Valtix’s built-in visibility allows customers to quickly review all logs for related Log4Shell exploitation.

This article provides an overview of how to Virtual Patch LOG4J in AWS, AZURE, GCP, and OCI.

The Vulnerability

The vulnerability arises from the poor deserialization of user input that allows for lookups to appear within logged messages. JNDI (Java-Naming and Directory Interface) controlled endpoints like LDAP (lightweight directory access protocol) or DNS (domain name services) can execute external Java classes; a known attack technique showcased during Blackhat USA 2016

How to mitigate this vulnerability

On 12/10/21 at 10:22 GMT, patch 2.15.0 was released by Apache that mitigates exploitation of CVE-2021-44228. If you are running versions 2.0 and 2.14.1, Apache recommends updating as soon as possible.

If updating is not possible, Apache recommends changing the system property “log4j2.formatMsgNoLookups” to “true” or removing the JndiLookup class from the classpath.

Valtix enables virtual patching, domain filtering, and WAF protection rules for LOG4J in AWS, Azure, GCP, and OCI. Valtix can easily be enabled in minutes. 

Our full resources and experience in the cloud are here to help. Contact us.

log4j JNDI attack
log4j JNDI attack and how to prevent it

Step 1: Sign Up for the Valtix Free Tier

You can sign up for the Valtix Free Tier in minutes. The Free Tier includes full capability to mitigate this vulnerability through virtual patching. For 90 days, Valtix will waive the normal Free Tier limitations to enable you to patch Log4j for AWS, Azure, OCI, and GCP. 

Sign Up Here

 

Step 2: Discover all of your apps

While organizations are spending time finding out where Log4J is in their environment, a safer policy is to deploy protections upfront. Valtix can give you a complete picture of your cloud accounts, VPCs, and apps in just a few steps. From there, we’ll apply policy to mitigate exposure regardless of whether the vulnerability exists or not.

Perform Discovery

Step 3: Deploy Valtix for Protection 

Valtix performs robust security through a managed gateway as a service. Deploying the Valtix Gateway in a service VPC can be done in minutes.

Step-by-step Instructions

Step 4: Virtual Patch Including WAF and IPS

Virtual patching is a proactive security process that incrementally reduces exposure through the application of an Intrusion Prevention (IPS) and WAF policy.

Valtix published updates from Talos and Trustwave rulesets to the Valtix Controller that contain the ability to detect and protect against the vulnerability. The ruleset update for each is listed as follows:

Talos (IDS/IPS):  2.9.11-[December 12, 2021] / 2.9.11-12122021
Trustwave (WAF):  3.0.2-[December 12, 2021] / 3.0.2-12122021

These updates apply to IDS/IPS Profiles (Talos) and WAF Profiles (Trustwave). Each has benefits for protecting against the vulnerability for various use-cases (Ingress, Egress, and East/West). 

Profiles that are configured to update Automatically will see the updates applied based on the delay configured in the Profile (immediate or delayed by N days). The Profiles that are configured to update Manually will need to be updated by a user with appropriate permissions to do so. It is strongly recommended to configure your Profiles for Automatic updates and receive these updates immediately after the publish date.

Valtix provides a full cloud web application firewall with full auto-updating ruleset. This will also identity the GEO IPs of any source traffic and correlate them with known malicious IPs.

a) Step-by-step IPS Instructions

b) Apply an Auto-updating ruleset WAF Profile

Step 5: Apply Egress Filtering (FQDN / URL Filtering)

 

Contact us for more info on these use cases for Log4j. Learn more about virtual patch Log4j for AWS, Azure, OCI, and GCP. 

Latest Posts

Back To Top