Mitigating Apache Log4j Vulnerability with Policy-as-Code

Overview

A critical vulnerability was reported in the extremely popular log4j logging framework for Java, Apache Log4j, (specifically, the 2.x branch called Log4j2). Apache Log4j is an open-source logging utility library broadly used by thousands, if not millions of apps.

Dubbed as Log4Shell, this vulnerability was initially reported through Minecraft gaming sites, which warned that threat actors could execute malicious code on servers and clients running the Java version.

The vulnerability, CVE-2021-44228, is a remote code execution vulnerability, allowing attackers to execute code on a system using the log4j2 Java library and has a severity rating of 10 out of 10, the highest and the most critical.

The Log4Shell vulnerability affects:

Log4j versions between 2.0 and 2.14 inclusive (and 2.15). The fix provided in 2.15 was incomplete.
Any software enabling and leveraging log4j message lookup substitution. Big technology players, including Microsoft, Cisco, Amazon Web Services, Google, and IBM have found that some of their services were exposed and vulnerable and have been rushing to fix the issue.

According to the illustration provided by Juniper Networks Researchers, here’s what the vulnerability exploits look like:

To Address This Vulnerability

To mitigate this vulnerability in releases prior to Log4j2 (<2.16.0), you need to do one of the following:

Java 8 (or later) users should upgrade to release 2.16.0.
Users requiring Java 7 should upgrade to release 2.12.2 when it becomes available (work in progress, expected to be available soon).
Otherwise, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Note that only the log4j-core JAR file is impacted by this vulnerability. Applications using only the log4j-API JAR file without the log4j-core JAR file are not impacted by this vulnerability.

More information can be found at the Apache Logging - Security website.

Mitigations Using Policy-as-Code

With Magalix Policies, there are multiple ways to discover and mitigate Log4Shell.

For those running Log4j 2.10 to 2.14.1, the environment variables LOG4J_FORMAT_MSG_NO_LOOKUPS should be set to “true”. The Magalix Platform can scan deployed Kubernetes objects and raise a violation if that environment variable isn’t being set, or is set to “false”. You can independently apply this same Policy left so that all Kubernetes objects-in-code are checked and violated before all within a feature branch.

Additionally, you can scan and prevent certain container images and tags (versions) from being applied. Magalix provides Policies that allow easy customization to block these images from entering your Cloud-native environment, within seconds, and without having to know REGO.

How Magalix Can Help

Mitigation is one thing, but being proactive by shifting your Policies left can prevent this issue from happening again. Magalix provides hundreds of out-of-the-box Policies and templates so that you can create and scale out your own custom rules as easily and quickly as possible.

Magalix K8s Policy packs cover CSI, MITRE ATT&CK, and PCI DSS standards. You can find more about our policies and our coverage here.

This article was originally published at Magalix
https://www.magalix.com/blog/mitigating-apache-log4j-vulnerability-with-policy-as-code