If you’re a web developer, you’ve probably heard of the Log4j Java exploit. It’s a vulnerability that allows attackers to inject malicious logs into web applications, resulting in data loss or even system failure. The Log4j exploit is particularly dangerous because it can be used to access sensitive information on your server, such as user passwords and credit card numbers. If you’re not careful, you could be vulnerable to this attack and lose your data or even your business. To protect yourself from the Log4j Java exploit, you first need to understand how it works and how it can be used to access your server’s sensitive information. Then, you need to install the appropriate security measures on your server. Finally, make sure that all of your users are aware of the risk and are taking steps to protect themselves from this attack.
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.
