Log4Shell in SQL ? JNDI exploit for Java H2 (CVE-2021–42392)
We all still remember Log4Shell (CVE-2021–44228) that messed with some of us. And how the Christmas break began. Since then, it has been a recurrent topic in many professional conversations and has found its spot almost daily in the news.
At the beginning of this year, another similar exploit was found. This vulnerability was found by Jfrog in early January this year. This time the vulnerability comes from the Java H2 SQL library(CVE-2021–42392).
We would not hear as much from this vulnerability as from the Log4J for two reasons: First, the vulnerable library is not as widespread. And second, there is minimal scope for the attack inside the library.
Understanding the attack:
This vulnerability comes from a library used by H2 called org.h2.util.JdbcUtils.getConnection. The method from this library requires a driver class name and database URL as parameters. If we get the right value on the driver class to perform a lookup on the URL, we can use a JNDI connection pattern to download or execute the malware as we did in Log4Shell.
In the JFrog blog, we can read how they explain the exploit: <<Specifically, the org.h2.util.JdbcUtils.getConnection method takes a driver class name and database URL as parameters. If the driver’s class is assignable to the javax.naming.Context class, the method instantiates an object from it and calls its lookup method. Supplying a driver class such as javax.naming.InitialContext and a URL such as ldap://attacker.com/Exploit will lead to remote code execution. >>
There are two different attack patterns or attack vectors that can allow a successful attack, and both require access to the web console:
- Active H2 Web console enabled; by default, there is the option to use a web client interface to configure or interact with the backend when using the H2 module. This console can be found by default in the TCP port 8082.
- Remote connection to an H2 console; by default and for obvious security reasons, H2 disables the option of connecting remotely to the console, limiting the access to the console to localhost. Nevertheless, when we use some frameworks that include the H2  like the JHipster framework, the framework allows the H2 library web console remote access by default, allowing users remote access to it (still require a successful login).
Detection and patching:
Thankfully there are simple methods to recognize a possible use of the h2 libraries, and therefore potential vulnerabilities we can look for a naming pattern on the Server’s file system. We have to look for the “h2-*.jar” naming pattern.
Another option, as JFrog recommends, is to avoid the Goose chase and scan the network for running instances of the Web Console.
They propose to perform such scans with nmap using the comand below :
nmap -sV — script http-title — script-args “http-title.url=/” -p80,443,8000–9000 192.168.0.0/8 | grep “H2 Console”
After we detect that we are vulnerable, the last step is to mitigate the vulnerability. To do so, we have two main options :
-Update to newer versions of Java that contain the trustURLCodebase mitigation. This blocks codebases from being loaded from JNDI
The mitigation is enabled by default on the following versions of Java (or any later version)
- Add security restrictions as to what users can access the Web console when installing a new server.
- Use a multilayered approach: If we configure the NGFW or a WAF to read and detect JNDI patterns and block by default not allow patterns for apps where we don’t use this as a feature, we will avoid ourselves a considerable amount of drama. People who use this approach to protect themselves from Log4J will be protected from this vulnerability.
From my experience, I can say that there are not that many apps that actively use JNDI connections outside the network in a legit way. And I’ve found this approach to be an effective way of blocking Log4J attacks.
Remember that things fail, and nothing is secure!
I hope the article was helpful!