| 3 min read
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
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.
Scanning Your System
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 ru