Log4j for Dummies: How to Determine if Your Server (or Docker Container) Is Affected by the Log4Shell Vulnerability

Update (12/17/21): This is a living guide that I will be updating frequently as the situation continues to develop. I am currently planning on making some additional recommendations that I will be posting here shortly, so please check back often.

Log4Shell in a Nutshell

Approximately a week ago (December 9th, 2021), a 0-day exploit was announced affecting the ubiquitous Java logging library, log4j. This vulnerability (CVE-2021-44228) allows an attacker to pass a request to a server such that the log4j (the logging library/module) parses it and ends up downloading a malicious payload from a remote server. That malicious payload can then be used to carry out further attacks.

The Swiss Government Computer Emergency Response Team has a great visualization of the attack:

How Do I Determine If My Server Is Affected by the Log4j/Log4Shell Vulnerability?

I'll split this into two groups: the quick and (relatively) easy checks vs. a more in-depth check that will require a little more effort to set up, but nonetheless will hopefully still be easy with this guide.

Quick and Easy Checks for Log4j Vulnerability

So the quick and easy checks are to simply see if you have any obvious log4j libraries laying around anywhere on your server. Unfortunately, however, this isn't necessarily the most reliable since some applications could potentially ship with the log4j .jar file or they could be hidden in archive. Nonetheless, this can be a helpful way to start triaging your servers.

dpkg -l | grep log4
locate .jar | grep log4j
dpkg -l | grep liblog4j

Note that the same commands can be run within a Docker container (see docker exec -it) to check a "server" running there.

If you find you don't already have locate, you'll have to install it with sudo apt-get update && sudo apt-get install mlocate). The mlocate is important, you don't want to pull the locate package; it's not the same.

The locate command also depends on a database that indexes the file names. If you're installing locate for the first time, it should index immediately; if it was already installed, make sure to update the database for the most recent results with updatedb.

References: ubuntu - How do I check if Log4j is installed on my server? - Server Fault

Scan Your Web Servers for the Log4j Vulnerability

This is the more robust way. Sometimes the best way to diagnose an issue is to simply look at the response to an input. Given the myriad of ways that you could be affected by some installed dependency that has dragged in log4j and isn't readily detected with the above quick-and-easy methods, one could simply ask if a more reliable way to determine if you're affected by the log4j vulnerability isn't to simply launch a log4j attack against yourself?

All of these are going to rely on Docker, so make sure you have it installed.

Set Up a Known-Vulnerable Server (Docker Container)

If you're to have any faith in the result of your pentesting, it'd be nice to know that your test is capable of detecting the vulnerability if you have a vulnerable server. So let's do that by setting up a known-vulnerable dummy server. Thankfully, such a Docker image already exists: log4shell-vulnerable-app!

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

You might want to change the first port number if port 9100 is already in use on your Docker host.

Also, this should go without saying, but make sure this container isn't publicly accessible from outside your network. We're not trying to actually give anyone an easy target.

Set Up the Log4j Vulnerability Scanner (Yes, Another Docker Container)

In this case, we're going to use log4j-scan, provided by FullHunt.io. Of the scanners I looked at, this seemed the most robust, attempting 60 HTTP request headers and allowing both GET and POST requests.

Now, unfortunately, the maintainer hasn't provided us with a readymade image from Docker Hub as of the time of this writing. Nonetheless, it's fairly straightforward so we'll roll our own Docker image locally.

git clone https://github.com/fullhunt/log4j-scan.git
cd log4j-scan
sudo docker build -t log4j-scan .

Scan Your Known-Vulnerable Server

Scanning is accomplished with the following syntax:

sudo docker run -it --rm log4j-scan -u http://<serverIPaddressHere>:<port>

So to scan our known-vulnerable server above, you would simply run the following command:

sudo docker run -it --rm log4j-scan -u http://<serverIPaddressHere>:9100

After a few seconds, you'll get the following response:

[!!!] Target Affected

Determine If Your Server and Docker Containers Are Vulnerable to Log4Shell

Now that you know that your log4shell scanner is working, scan the servers and Docker containers you actually care about using the same syntax above:

sudo docker run -it --rm log4j-scan -u http://<serverIPaddressHere>:<port>

You can also just use a URL if you have one. It also should go without saying that you should only run this scan against URLs and IPs YOU OWN.

If you're not affected, you should get a message saying as much:

[•] Targets does not seem to be vulnerable.

What To Do If You Find You Are Affected

In a future post we'll talk about mitigating this vulnerability, but for now, the answer is SHUT IT DOWN. If you find an affected server or container, immediately pull public/WAN access to the vulnerable container.

Ideally, this is the way it should be anyway even in a world without this issue. A primary principle of cybersecurity is to limit access on a need-to-know basis. If you don't absolutely need to allow public access to a server or Docker container, don't give WAN access to it, just use Unraid's WireGuard feature and VPN in to access the service locally.

As always, if you have any questions or feedback, please let me know in the comments/forum below! Thanks for reading and I hope you find this helpful.