“It’s Log4Shell, Jim,” Commander Spock never actually said, “but not as we know it.”
This is the shortest summary of the bug we could come up with CVE-2021-42392, One security breach A recent report by researchers at software supply chain management firm Jfrog.
This time, the vulnerability is not in Apache’s beleaguered Log4j toolkit, but can be found in a H2 database engine.
H2 is not like traditional SQL systems such as MySQL or Microsoft SQL server.
Although you can run H2 as a standalone server for other applications to connect to, its main claim to fame is its modest size and standalone nature.
As a result, you can bundle H2 SQL database code directly into your own Java application and run your database entirely in memory without the need for a separate server process.
Of course, as with Log4j, this means that if you use any application or development component that silently includes it itself, you may be running instances of H2 database engine code inside your organization without realizing it.
JNDI back in the spotlight
As with the Log4Shell vulnerability, it depends on abuse Java Naming and Directory Interface, better known as JNDI, which is part of every standard Java installation.
JNDI should make it easier to identify and access useful resources across the network, including finding and retrieving remotely stored software components using well-known search and discovery protocols such as LDAP (Lightweight Directory Access Protocol).
As dangerous as this sounds, it’s important to remember that similar functionality can be coded into any software (compiled or interpreted, scripted or binary) with network access, can download arbitrary data, and be able to transform that data A type of executable code for some software. JNDI just makes it very easy to build distributed applications that find and load remote components. This programming convenience can sometimes improve security because it is often easier to audit and review code when it follows a well-documented path. But sometimes it’s less safe because it’s easier to introduce unintended side effects by mistake.We see this in Log4j, where “Write out a text string to log data submitted by the remote user” may inadvertently become “Download and run an untrusted program specified by the remote user”.
Fortunately, unlike Log4Shell, the CVE-2021-42392 bug cannot be triggered simply by embedding booby-trapped text into the query sent to the H2 database engine.
While Jfrog has documented several ways in which cybercriminals could theoretically trick H2 into running arbitrary remote code, the most likely attack paths include:
- An active web-based H2 console. This is a built-in web server that usually listens on TCP port 8082 and allows developers to interact with the H2 SQL backend at runtime. This attack vector will not work if this port is blocked or the console is inactive.
- H2 console listening on external network interface. By default, the console only accepts connections from the computer it is running on (
localhost, usually the IP number127.0.0.1in an IPv4 network). Unless this default is changed, attackers will need local access anyway to access the H2 console.
According to H2, the application Embedded H2 engine directly into their code “Not exposed”, But as far as we can tell, this comment refers only to the database engine itself, when it’s not running as a SQL server, not the web console component.
Unfortunately, Jfrog states:
We have observed that some third-party tools relying on the H2 database run by default the H2 console exposed to remote clients.For example, the JHipster framework also exposes the H2 console, and by default
webAllowOtherspropertytrue.
(that setting webAllowOthers Is a Java property that H2 uses to decide whether to accept connections from external network interfaces. )
The default web console login page includes a form that allows users to specify how they wish to connect to the database.
A malicious user can use this form to request a JNDI lookup via LDAP, as in a Log4Shell attack, to trick H2 into fetching and running a remote Java .class file (compiled Java program).
Although the dangerous URL used to launch the attack will be submitted in the same login form that requests the username and password, Jfrog found that the JNDI lookup happens before the username and password are validated.
This means that an attacker does not need working credentials to exploit the vulnerability, so the vulnerability opens the so-called Unauthenticated remote code execution (RCE) holes, the most dangerous species.
Learn how JNDI and LDAP combine for remote code execution
For a live demonstration of how JNDI can be combined with JDAP to look maliciously to download and run untrusted remote code, watch this video:
If you can’t read the text in the video clearly here, try full screen mode, or look directly on YouTube. Click the gear in the video player to speed up playback or turn on subtitles.
what to do?
- If you have an application using the H2 database engine, Upgrade H2 to version 2.0.206.
At the time of writing, 2.0.206 (released 2022-01-04) listed As the latest version, although H2 Changelog still lists 2.0.206 as “Unpublished”, and CVE-2021-42392 is not documented as one of the fixed issues.
However, Jfrog states that 2.0.206 contains code changes similar to what Apache used in the Log4j 2.17.0 update: H2 no longer allows using JNDI with any remote references.
This means that, in theory, an attacker can no longer use the say “Do a lookup, but use a web request that takes you to an untrusted external location so we can manipulate the results”.
From what we’ve seen, the updated H2 database engine now only uses JNDI for what are essentially native Java function calls, so remote code execution as an unintended side effect of using JNDI is no longer possible, either by accident or by design.
- To find instances of H2 code on your network, You can search for
h2-*.jar.
Wildcard text is given by * should be the form X.Y.Z, which represents the version number of H2 in use – anything below 2.0.206 should be replaced with the latest version.
