3rd Party Risk Management , Application Security , Governance & Risk Management

Researchers Discover H2 Database Flaw Similar to Log4Shell

JFrog: New CVE Is First JNDI-Related Flaw to Be Published Since Log4j in December
Researchers Discover H2 Database Flaw Similar to Log4Shell
Visual interpretation of similarities between Log4j and H2 database console flaws (Source: JFrog)

Researchers at the security firm JFrog have discovered a new remote code execution vulnerability in the H2 database console, a Java-linked database, which could allow attackers to exploit the flaw in applications and software via code injection. Although the researchers say the root cause of this critical flaw is similar to the flaw detected in Apache's Log4j, they believe the differences may lessen its impact.

See Also: Zero Trust Webinar: Research Insights Exploring the Actionable, Holistic & Integrative Approach to Security

The H2 vulnerability has yet to be publicly posted to the National Institute of Standards and Technology catalog, but according to a blog post authored by JFrog researchers Andrey Polkovnychenko and Shachar Menashe, it will be tracked as CVE-2021-42392.

H2, an open-source Java SQL, is popular with developers for its Maven package, which has nearly 7,000 artifact dependencies to add to a build configuration.

The JFrog researchers say they have been actively scanning for Java Naming and Directory Interface flaws due to the widespread usage and their belief that "there are bound to be more packages" affected by a similar cause. As a result of the scanning, they discovered the H2 database flaw.

"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 say.

After they detected the vulnerability, they notified H2, which rapidly released a patch for the flaw and posted a critical advisory to GitHub.

Known as Log4Shell and tracked as CVE-2021-44229, the Apache Log4j vulnerability has turned security teams' worlds upside down as they race to remediate the critical 10-out-of-10 flaw, which was first detected and reported in December. Attackers and nation-states are already beginning to exploit the vulnerability that was found in the broadly used library logging tool for Java applications. The Cybersecurity Infrastructure and Security Agency has also recommended that all security teams patch the flaw, also known as "Logjam," immediately. (see: Log4j Updates: Flaw Challenges Global Security Leaders).

Although it has a similar root cause to Log4Shell, researchers say that this new H2 vulnerability will not have as wide an impact.

JFrog did not immediately respond to Information Security Media Group's request for additional technical details regarding the new vulnerability.

Log4Shell: Similarities and Differences

The researchers say that the root cause of the vulnerability - remote class loading in JNDI - is comparable to the cause of Log4Shell. Ultimately, within the H2 database framework, attackers could exploit several code paths leading to the "javax.naming.Context" lookup function, allowing for Java code injection.

Many developers use the H2 database and expose the H2 console to a LAN or WAN port, which could open the potential for a RCE exploit, according to the researchers.

"The recent trend of supply chain attacks targeting developers, such as malicious packages in popular repositories, emphasizes the importance of developer tools being made secure for all reasonable use cases," they say.

Although the researchers say that the vulnerability is critical, they also predict it will not be as far-reaching as Log4j due to several factors:

  • Compared to the Log4j vulnerability, the new CVE is more easily detected due to a "'direct' scope of impact";
  • While the H2 console could be "easily changed to listen to remote connections," by default, the H2 console listens strictly to localhost connections - unlike Log4j, in which the exploit was detected in the default setting;
  • Although vendors may be running the H2 database, they may not be running the H2 console, meaning some attack vectors will not be as readily exploitable as those found in Log4j.

Casey Ellis, the founder and CTO for security firm Bugcrowd, says that the hype around Log4j has led some research teams to "capitalize on a sense of panic," but he does not believe that JFrog's research is of this nature.

"The JFrog folks seem to have taken great care to get their message across, but not cause undue work for already overloaded security teams," he says.

Attack Vectors

"The most severe attack vector of this issue is through the H2 console," the researchers say, adding that by default the database contains an embedded web-based console.

When using H2 as an embedded library, attackers could access the console through a malicious URL because the username and password do not need to be validated.

The researchers also discuss other attack vectors, including a context-dependent RCE built into the H2 shell tool, but say they consider this attack vector "highly unlikely."

Upgrade and Mitigation

Administrators can determine vulnerability of their networks by scanning the H2 console with nmap, which can detect dangerous servers in relation to the flaw.

Researchers urge all vendors to upgrade to the latest version of the H2 database to avoid the exploitation of the new CVE.


About the Author

Devon Warren-Kachelein

Devon Warren-Kachelein

Staff Writer, ISMG

Warren-Kachelein began her information security journey as a multimedia journalist for SecureWorld, a Portland, Oregon-based cybersecurity events and media group. There she covered topics ranging from government policy to nation-states, as well as topics related to diversity and security awareness. She began her career reporting news for a Southern California-based paper called The Log and also contributed to tech media company Digital Trends.




Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing inforisktoday.com, you agree to our use of cookies.