If you’re a web developer, you’ve probably heard of the Log4j Java exploit. It’s a vulnerability that allows attackers to access your server’s logs and extract sensitive information. If you’re not familiar with the exploit, here’s a quick overview: Log4j is a Java library that helps developers write code that interacts with the web. When an attacker uses Log4j to access your server’s logs, they can extract sensitive information like user IDs and passwords. There are several ways to protect yourself from this exploit:
- Use a security guard or firewall to block all traffic to your server from outside sources. This will help protect your data and prevent attackers from extracting sensitive information.
- Use an anti-logging software like Logical Volume Manager (LVM) or File System Monitor (FSM). These tools will help you identify and stop any logins attempt from happening in the first place.
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.
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.
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.
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.
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.
