Now in the popular open-source H2 Java database console, JFrog security detected and rated the flaw critical. This critical issue is similar to the Log4J vulnerability where the vulnerability in the Log4J logging library allows the attacker to execute remote code on vulnerable systems.

It has got a lightweight in-memory solution that eliminates the need for data to be saved on a disc. However, this issue does not offer the same risk as the one previously discovered in Log4Shell.

Researchers said the H2 flaw may be highly critical and the most severe attacking method is directly hitting the H2 console. This flaw allows unauthenticated RCE through the systems running H2 console connected to LAN or WAN.

“ There are likely less than 100 servers on the internet impacted by the H2 flaw according to open-source intelligence (OSINT), so only a very limited number of organizations are directly affected.” Blumira’s Warner said. He also added that “This vulnerability is a good reminder that it is important to ensure that sensitive services are only internally exposed to mitigate potential future risks”

H2 Bug and Log4J:

“H2 bug (CVE-2021-42392) is similar to Log4Shell (CVE-2021-44228) but not of a much widespread and less severe than Log4Shell because the susceptible servers should be easier to discover.” JFrog researchers wrote in their post. The main similarity is JNDI remote class loading is the primary cause of the H2 vulnerability. This bug permitted many H2 database framework code paths to deliver unfiltered attacker-controlled URLs to the javax.naming.Context.lookup function which enables remote codebase loading (also known as Java code injection or remote code execution).

“The org.h2.util.JdbcUtils.getConnection method requires a driver class name and database URL as parameters,” they wrote in the blog post. “The function creates an object from the driver’s class and executes its lookup method if the driver’s class is assignable to the javax.naming.Context class.”

Unlike Log4Shell, The remote code execution (RCE) bug will directly affect the H2 console server which processes the initial request and the H2 console only listens to localhost connections by default on vanilla H2 database releases which makes the default setting safe.

“Log4Shell was vulnerable under Log4j’s default configuration and comparatively H2 console also can be easily modified according to remote connections. But in comparison to the Log4j, the severity of H2 is less because of its execution aspects. Despite the fact that many companies run the H2 database, they may not run the H2 console along with it” researchers said.

Recommendations:

Numerous developer tools depend on the H2 database and expose the H2 console. This is concerning because of a “current trend of supply chain attacks targeting developers, such as malware packages in prominent repositories,”. These attacks highlight “the significance of securing development tools for all legitimate use cases and after applying their recommended update, many H2-dependent tools should be safer.,” according to the researcher.

The JFrog team recommends upgrading the H2 database with version 2.0.206, which can fix CVE-2021-42392 by limiting JNDI URLs to use only local java protocol and excludes any remote LDAP/RMI queries. “This fix is so much similar to the fix which is recommended for Log4j 2.17.0” researchers explained.

With Clear Infosec security experts, find and fix any bugs before someone bad does and stay away from being in the next headline. Keep your IT infra secured.

Reference:

Montalbano, A. E., & Montalbano, E. (n.d.). LOG4J-related RCE flaw in H2 database earns critical rating. Threatpost English Global threatpostcom. Retrieved January 11, 2022, from https://threatpost.com/log4j-related-flaw-h2-database/177448/