JFrog researchers Andrey Polkovnychenko and Shachar Menashe disclosed a Log4j like vulnerability in the H2 database console that could lead attackers to perform unauthenticated remote code execution vulnerability. The flaw, tracked as CVE-2021-42392, has the same root cause as the Log4j vulnerability in the Apache Log4j logging utility. Let’s see how to fix CVE-2021-42392- a critical unauthenticated RCE in the H2 database console.
Table of Contents
What Is H2 Database?
H2 database is a free, open-source, lightweight relational database developed in Java. It can be used in embedded, client-server, and in-memory database modes. In embedded mode, the database is embedded within the Java application, wherein case of client-server, the database can be used as a stand-alone DB server like MySQL and can be accessed through integrated web and command-line consoles. When it is used as an in-memory database, data will not persist on the disk.
What Is JNDI?
Java Naming and Directory Interface. Is a Java API that allows applications to communicate with other applications such as LDAP, DNS, NIS, NDS, RMI, and CORBA. Its main function is to provide naming and directory functionality to applications developed in the Java language. It runs on top of a Java application to fetch files from a database using naming conventions. It is defined to be independent of any specific directory service implementation.
JNDI architecture has two main components: JNDI API and JNDI SPI. API is used to access different naming and directory services. It allows the Java application to communicate with applications such as LDAP, DNS, NIS, NDS, RMI, and CORBA. JNDI has a JNDI SPI (Service Provider Interface) for each naming and directory service to communicate with different services.
About The CVE-2021-42392 Vulnerability (A RCE Vulnerability In H2 Database Console):
As per the report, “The root cause is similar to Log4Shell – several code paths in the H2 database framework pass unfiltered attacker-controlled URLs to the javax.naming.Context.lookup function, which allows for remote codebase loading (AKA Java code injection AKA remote code execution).
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:
The CVE-2021-42392 vulnerability is not widespread as Log4Shell because the H2 console only listens to localhost connections, unlike Log4Shell, which listen to remote connection by default. However, bear in mind that it is possible to make H2 listen to remote connection as well, which makes it critical.
Another important thing for your note is that some vendors say their application is running only the H2 database, not the H2 console, so their application is safe from the flaw. But, the reality is there are other vectors to exploit the CVE-2021-42392 vulnerability other than the console. You need to ensure that your application is protected from all these attack vectors.
- H2 Web Console: This is the most prevalent vector among others. It is an embedded web-based console that can be accessible on http://localhost:8082 from the browser.
- H2 Shell Tool: This is a command-line tool that allows an attacker to invoke the vulnerability.
- SQL-Based Vectors: This vector allows an attacker to invoke the vulnerability by several SQL stored procedures, available by default in the H2 database.
Ultimately, attackers will try exploiting the CVE-2021-42392 vulnerability by passing the “driver” and “url” fields to the corresponding fields of JdbcUtils.getConnection. This leads to unauthenticated RCE in H2 Database Console since the username and password are not validated before performing the lookup with the potentially malicious URL.
H2 Database Versions Vulnerable To The CVE-2021-42392 Vulnerability:
H2 database versions from v1.1.100 to v2.0.204 are vulnerable to the CVE-2021-42392 vulnerability. Make sure you shouldn’t have these versions running on your servers.
How To Check If The System Is Vulnerable To The CVE-2021-42392 Vulnerability?
You can use the Nmap tool to scan for vulnerable systems on your network. Run this below command to scan the vulnerable systems. Note: You should need to have Nmap installed on a system connected to the network.
nmap -sV --script http-title --script-args "http-title.url=/" -p80,443,8000-9000 192.168.0.0/24 | grep "H2 Console"
How To Fix CVE-2021-42392- A Critical Unauthenticated RCE In H2 Database Console?
The vendor has fixed the CVE-2021-42392 vulnerability in v2.0.206 by limiting JNDI URLs to use the (local) Java protocol only, which denies any remote LDAP/RMI queries. We recommend upgrading to version 2.0.206 even if the H2 console is not running on your server.
For the users who can’t immediately go ahead with the upgradation, they can consider one of these mitigation options.
- These versions of Java will not allow remote codebases to be loaded naively via JNDI. So, you can consider mitigation is enabled by default on these versions of Java. It is better to upgrade Java to any of these versions.
- As a second mitigation strategy, it is good to implement user access restrictions like only a set of users are allowed to access the console page.
You can choose any mitigation strategy that satisfies your requirements. We hope this post would help you know How to Fix CVE-2021-42392- A Critical Unauthenticated RCE in H2 Database Console. Thanks for reading this threat post. Please share this post and help to secure the digital world. Visit our social media page on Facebook, LinkedIn, Twitter, Telegram, Tumblr, Medium & Instagram, and subscribe to receive updates like this.