Found on December 11 through an POC, Log4J’s vulnerability is one of the biggest vulnerabilities we have found. This will affect tens of thousands of enterprise websites running on Java. Let’s go through, what happened and how to fix it?
Log4J is an extremely popular open-sources library used in Java to manage application logging. It is an extremely popular library among Java developers because of how simple it makes logging in Java.
What does zero-day vulnerability mean?
This means the developer has “zero days” to fix the bug and this can affect the systems immediately.
This is a Remote Code Execution vulnerability, meaning external malicious code can run on the server with it.
You might think how can a logging library help in remote code execution? Well, the reason why this is happening is a feature, present in Log4J. It enables log4J to actually execute Java code. This is enabled through something called JNDI.
JNDI stands for Java Naming and Directory Interface. It is an API that allows applications to check on services in a resource-independent way. This has several uses — for instance, it enables access to Java resources without exposing the resources or path to them.
Now, in case of log4j, when it sees a JNDI reference in its logs, it will actually go to the resource location and fetch what it needs to resolve the JNDI variable and execute it.
And in the process of fetching the resource (LDAP resource), it can download remote classes and execute them!
So, someone can inject something like this in logs and the server would be compromised:
Now obvious question, how can you know what is getting logged? Because if you pass something and that isn’t logged, the attack is useless, right?
One of the most common things that gets logged are User-Agents (which helps server identify the clients’ OS, browser, etc.).
So, if we can change the User-Agent in the request header to our malicious JNDI and if the User Agent is logged, remote code would be executed on the server.
There you go. Hacked 101 🎃
Virtually every company using Java and log4J… which might be most of the enterprise customers.
As of writing this, Apple, Amazon, Twitter, Cloudflare, Steam, Tencent, Baidu are acknowledged to be vulnerable. But most probably, the real number is much more.
For more on Java and web dev. let's connect on Twitter, Mukund Madhav
There are currently four solutions floating around:
- Upgrade Log4J to 2.15.0. Here is the download link for Log4J.
- Set this system level property
This will disable the JNDI lookup feature. This will work if you have log4j v2.1 - 2.14.1
3. Delete the JNDI class file. It will be named JdniLookup.class and should be inside org/apache/logging/log4j/core/lookup/JndiLookup.class
4. For versions 2.1 to 2.14.1, set the following environment variable to force change
That’s it. Safe to say this will go down as one of the most obvious (but hopefully not much exploited in future) bug.
Not a cool day to say,
Java runs on 3 billion devices
Happy fixing 😃