JFrog researchers discover JNDI vulnerability in H2 database consoles similar to log4shell
JFrog security researchers said on Thursday they discovered a critical JNDI-based vulnerability in the H2 database console exploiting a root cause similar to Log4Shell. The CVE has not been released by NIST but will be assigned to CVE-2021-42392.
In a blog post, the company said CVE-2021-42392 is not expected to be as prevalent as Log4Shell, even though it is a critical issue with a similar root cause.
JFrog explained that Java Naming and Directory Interface (JNDI) is an API that provides naming and directory functionality for Java applications. H2 is an open source Java SQL database widely used for various projects ranging from web platforms such as Spring Boot to IoT platforms such as ThingWorks. The researchers noted that the com.h2database: h2 package “is among the 50 most popular Maven packages, with nearly 7,000 artifact dependencies.”
Shachar Menashe, senior director of security research at JFrog, told ZDNet that, similar to the Log4Shell vulnerability discovered in early December, attacker-controlled URLs that propagate in JNDI searches may allow remote code execution not. authenticated, giving attackers exclusive control over another person’s operation or organizational systems.
The security company said that CVE-2021-42392 for the H2 Database Console is the first critical issue published since Log4Shell, on a component other than Log4j, which exploits the same root cause of the Log4Shell vulnerability, namely the JNDI remote class loading.
âTo the best of our knowledge, CVE-2021-42392 is the first unauthenticated JNDI-related RCE vulnerability to be released from Log4Shell, but we believe it won’t be the last,â the researchers wrote.
âOne of our main lessons from the Log4Shell vulnerability incident was that due to the widespread use of JNDI, there are bound to be more packages affected by the same root cause as Log4Shell – accepting JNDI search URLs. Thus, we adjusted our automated vulnerability detection framework to account for the javax.naming.Context.lookup function as a dangerous (sink) function and launched the framework on the Maven repository to hopefully find problems similar to Log4Shell. “
The H2 database package was one of the first they released and they reported it to H2 maintainers who immediately patched it to a new version, creating a critical GitHub notice.
According to JFrog, multiple code paths under the H2 database pass unfiltered in URLs controlled by the attacker to the javax.naming.Context.lookup function, which they claim allows the database to load. remote code. Of all the attack vectors of the problem, the most serious is through the H2 console.
âThis feature may impact those running a network exposed H2 Database Console and we recommend that you update your H2 database to version 2.0.206 immediately. Note that the H2 database is used by many third-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 H2 console deployments exist in the wild. JFrog also explained several other attack vectors using the same vulnerability.
JFrog suggested users to upgrade their H2 database to the latest version. They noted that they had seen a number of developer tools “build on the H2 database and specifically expose the H2 console”.
“If you are running an H2 console that is exposed to your LAN (or worse, WAN) this problem is extremely critical (unauthenticated remote code execution) and you should immediately update your H2 database to version 2.0 .206, âthe company said. âNetwork administrators can scan their local subnets for open instances of the H2 console with nmap. Any returned servers are very likely to be exploitable. “
According to researchers, version 2.0.206 is similar to Log4j 2.17.0 in that it addresses the issue by restricting JNDI URLs to only use Java (local) protocol, which denies any remote LDAP / RMI request.
JFrog has also provided several mitigation options for those who cannot upgrade to H2.
Matthew Warner, CTO at Blumira, told ZDNet that according to OSINT there are likely less than 100 impacted servers on the internet because the H2 database console has to be deliberately exposed to the internet by changing the configuration to not just listen. on localhost.
âAlthough this vulnerability also uses remote JNDI class loading, it requires access that is not available with the default H2 database configuration,â Warner said.
BreachQuest CTO Jake Williams said widespread exploitation is unlikely because this vulnerability is found in an application as opposed to a library like log4j, which means vulnerable systems should be much easier to discover and to correct.
In a default configuration, the vulnerability can only be triggered from the same machine on which the database console is running, which means that the exploitation is extremely conditional.
“This is unlikely to cause widespread damage, although vulnerability managers should be prepared to remediate other newly discovered JNDI vulnerabilities as they are disclosed,” Williams said. “It is clear that this vulnerability will not be the latest discovery related to log4j.”
Others, like Ray Kelly of NTT Application Security, said that while exploitation was unlikely, using a SQL and JNDI mashup to exploit an RCE vulnerability “is a pretty creative and excellent example on the way in which a single problem can be abused in several ways â.
The research is also worth the effort because even though log4j had specific coding flaws resulting in Log4Shell, the broader idea of ââa lack of validation on JNDI searches leading to vulnerabilities is a general attack route that is likely to fail. ‘exist elsewhere and, given the vulnerabilities in log4j weren’t discovered earlier, likely hasn’t come under scrutiny, according to Bugcrowd’s CTO Casey Ellis.
âThis is a classic example of ‘clustered search’ which is a phenomenon that Bugcrowd has observed several times before and that we predicted after the initial release of Log4Shell,â said Ellis.
âSome research teams have chosen to capitalize on a sense of panic to get their point across, while the folks at JFrog seem to have taken great pains to get their point across, but without causing undue work to the already overburdened security teams. “