Network Security
Vulnerability Management
Privileged Access Management
Endpoint Security
Threat Hunting
Unified Endpoint Management
Email & Collaboration Security
Contents:
JFrog security researchers published a report on Thursday revealing a JNDI vulnerability located in the H2 database console, indicating the same root cause as the well-known Log4Shell bug. They also mentioned that the bug will be assigned the CVE-2021-42392.
What Is JNDI?
Java Naming and Directory Interface aka JNDI stands for an API whose role is to facilitate naming and directory range of capabilities for Java applications. The open-source Java SQL database is referred to as H2 being useful for web platform-related projects like Spring Boot or to IoT platforms projects such as ThingWorks.
About the JNDI Vulnerability
The researchers mention that the newly discovered JNDI vulnerability should not be as widespread as Log4Shell for several reasons like:
- This bug is characterized by a “direct” scope of impact, meaning that the RCE will have an impact on the server that will process the initial request.
- The default setting is safe because the H2 console listens by default to localhost connections;
- The H2 database is run by many vendors, but no the same thing applies to the H2 console.
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. (…) 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.
Why Is the JNDI Vulnerability Dangerous?
Shachar Menashe, who is the JFrog’s senior director, shared with the ZDNet publication the fact that URLs controlled by hackers that propagate into JNDI lookup can lead to unauthenticated remote code execution. This way cybercriminals could gain control over a company’s system or another person’s operation.
Various code paths in the H2 database framework can pass unfiltered in the URL controlled by threat actors reaching the javax.naming.Context.lookup function, a function that facilitates the loading of the remote codebase. As researchers underline, the H2 console serves as the most severe attack vector regarding this vulnerability.
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. (..) 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.
Researchers reported the H2 database package to the maintainers of H2, thus this issue was addressed and fixed in a new release of a GitHub advisory.
Mitigation Measures Recommended by Researchers
The experts recommend users upgrade their H2 database to the most recent version (2.0.206), as the issue becomes critical if users are exposed to LAN or WAN because this could result in an unauthenticated remote code execution cyberattack. This version addresses the issue as it manages to limit JNDI URLs to leverage only the (local) java protocol, this way remote LDAP/RMI queries being denied.
Network administrators can check if they are vulnerable to the JNDI vulnerability by scanning the local subnets for the H2 console open instances using nmap. Return servers will indicate their exploitation likelihood. Here you can read more about how to use Nmap to enhance network security.
Vendors who cannot upgrade H2 for the moment should upgrade their Java (JRE/JDK) version to enable the trustURLCodebase mitigation. It’s worth mentioning here that this mitigation is enabled by default on Java versions like 6u211, 7u201, 8u191, 11.0.1. Another option would be to add a security constraint to the H2 console Servlet when deployed on a web server. This will allow only certain users to access the console page. To do this, vendors should follow this configuration example, as emphasized by the experts.
Did you enjoy this article? Follow us on LinkedIn, Twitter, Facebook, Youtube, or Instagram to keep up to date with everything we post!
Hi! My name is Andra and I am a passionate writer interested in a variety of topics. I am curious about the cybersecurity world and what I want to achieve through what I write is to keep you curious too!
