Security researchers from JFrog said on Thursday that they discovered a critical JNDI-based vulnerability in the H2 database console exploiting a root cause similar to Log4Shell. The CVE hasn’t been posted by NIST but will be assigned CVE-2021-42392.
In a blog post, the company said that CVE-2021-42392 should not be as widespread as Log4Shell even though it is a critical issue with a similar root cause.
JFrog 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 researchers noted that com.h2database:h2 package is “part of the top 50 most popular Maven packages, with almost 7,000 artifact dependencies.”
Shachar Menashe, senior director of JFrog security research, told ZDNet that similar to the Log4Shell vulnerability uncovered in early December, attacker-controlled URLs that propagate into JNDI lookups can allow unauthenticated remote code execution, giving attackers sole control over the operation of another person or organization’s systems.
The security company said CVE-2021-42392 for the H2 database console is the first critical issue published since Log4Shell, on a component other than Log4j, that exploits the same root cause of the Log4Shell vulnerability, namely JNDI remote class loading.
“To the best of our knowledge, CVE-2021-42392 is the first JNDI-related unauthenticated RCE vulnerability to be published since Log4Shell, but we suspect it won’t be the last,” the researchers wrote.
“One of our key takeaways from the Log4Shell vulnerability incident was that due to the widespread usage of JNDI, there are bound to be more packages that are affected by the same root cause as Log4Shell – accepting arbitrary JNDI lookup URLs. Thus, we’ve adjusted our automated vulnerability detection framework to take into consideration the javax.naming.Context.lookup function as a dangerous function (sink) and unleashed the framework onto the Maven repository to hopefully find issues similar to Log4Shell.”
The H2 database package was one of the first they validated and they reported it to H2 maintainers who immediately fixed it in a new release, creating a critical GitHub advisory.
According to JFrog, several code paths in the H2 database framework pass unfiltered in attacker-controlled URLs to the javax.naming.Context.lookup function, which they said allows for remote codebase loading. Of all the attack vectors of the issue, the most severe is through the H2 console.
“This feature can impact those running an H2 database console exposed to the network and we recommend updating your H2 database to version 2.0.206 immediately. Note that the H2 database is used by many 3rd-party frameworks, including Spring Boot, Play Framework and JHipster,” Menashe said.
“While this vulnerability is not as widespread as Log4Shell, it can still have a dramatic impact on developers and production systems if not addressed accordingly.”
The report notes that because the H2 database is used by so many artifacts, it is difficult for them to quantify how many vulnerable deployments of the H2 console exist in the wild. JFrog also explained several other attack vectors using the same vulnerability.
JFrog suggested users upgrade their H2 database to the latest version. They noted that they have seen a number of developer tools “relying on the H2 database and specifically exposing the H2 console.”
“If you are running an H2 console which is exposed to your LAN (or worse, WAN) this issue is extremely critical (unauthenticated remote code execution) and you should update your H2 database to version 2.0.206 immediately,” the company said. “Network administrators can scan their local subnets for open instances of the H2 console with nmap. Any returned servers are highly likely to be exploitable.”
According to the researchers, version 2.0.206 is similar to Log4j 2.17.0 because it fixes the issue by limiting JNDI URLs to use the (local) java protocol only, which denies any remote LDAP/RMI queries.
JFrog also provided several mitigation options for those who cannot upgrade H2.
Matthew Warner, CTO at Blumira, told ZDNet that according to OSINT, there are likely under 100 impacted servers on the internet because the H2 Database Console must be purposefully exposed to the internet by changing the configuration to not only listen on localhost.
“While this vulnerability also utilizes remote JNDI class loading, it requires access that is not available with the default configuration of the H2 Database,” Warner said.
BreachQuest CTO Jake Williams said widespread exploitation is unlikely because this vulnerability is in an application as opposed to a library like log4j, meaning vulnerable systems should be much easier to discover and remediate.
In a default configuration, the vulnerability can only be triggered from the same machine the database console is running on meaning exploitation is extremely conditional.
“It’s unlikely that this will cause widespread damage, though vulnerability managers should be ready to patch other newly discovered JNDI vulnerabilities as they are disclosed,” Williams said. “It’s clear that this vulnerability won’t be the last one discovered that’s related to log4j.”
Others, like NTT Application Security’s Ray Kelly, said that while exploitation was unlikely, using a mashup of SQL and JNDI to exploit an RCE vulnerability “is quite creative and excellent example on how a single issue can be abused multiple ways.”
The research is also worthwhile because even though log4j had specific coding flaws resulting in Log4Shell, the broader idea of a lack of validation on JNDI lookups leading to vulnerabilities is a general attack pathway which is likely to exist elsewhere and, given the log4j vulnerabilities weren’t discovered sooner, likely hasn’t been the subject of directed scrutiny, according to Bugcrowd CTO Casey Ellis.
“This is a classic example of ‘research clustering’ which is a phenomenon Bugcrowd has observed many times before and one we predicted after the initial publication of Log4Shell,” Ellis said.
“Some research teams have opted to capitalize on a sense of panic to get their message out there, while the JFrog folks seem to have taken great care to get their message across, but not cause undue work for already overloaded security teams.”
