Mitigate the impact of JNDI bugs by disabling vulnerable behaviors by default
A vulnerability with the same root cause as the infamous Log4j vulnerability has been patched in the console of the popular Java SQL database H2 database engine.
As with the recent “Log4Shell” vulnerability, an unauthenticated attacker can achieve remote code execution (RCE) because the console accepts arbitrary Java naming and directory interfaces (JNDI) to find the URL.
According to GitHub, the vulnerability (CVE-2021-42392) “allows loading custom classes from remote servers via JNDI” Safety Consulting Posted by the H2 maintainer on January 5th.
admired Researchers Find 70 Web Cache Poisoning Vulnerabilities, Win $40,000 Bug Bounty
The flaw confirms the suspicions of the security researchers who discovered it — the widespread use of JNDI suggests that “there must be many more packages affected by the same root cause as Log4Shell,” according to a blog post Published yesterday (Jan 6) by Andrey Polkovnychenko and Shachar Menashe of cybersecurity firm JFrog.
With nearly 7,000 artifact dependencies, H2 is one of the most popular open source Maven packages.
Worryingly, given the “recent trend of supply chain attacks against developers,” Polkovnychenko and Menashe said they observed a number of H2-dependent developer tools exposing the H2 console.
Safe by default
The pair described the flaw as “extremely serious” if the H2 console were exposed to a LAN or worse, a WAN.
However, since the H2 console is secure by its default settings, the fact that it only listens for localhost connections (although enabling remote connections is simple, the researchers point out) greatly reduces threats.
Also, RCE typically only affects the server that handles the initial request, and many vendors running H2 databases may not expose the H2 console.
Nonetheless, JFrog recommends that all H2 users upgrade to the latest version, whether or not they use the H2 console directly.
That’s because there are other attack vectors — the researchers also discovered H2 Shell tools and authentication-dependent SQL vectors — although they are “context-dependent and unlikely to be exposed to remote attackers.”
Restrict JNDI URLs
Vulnerable H2 versions span from 1.1.100 to 2.0.204 (inclusive).
The researchers praised the H2 maintainers for addressing the vulnerability in a timely manner in version 2.0.206, which was released on January 5.
Similar to the Log4j fix, this patch restricts JNDI URLs to only use the native Java protocol, preventing remote LDAP/RMI queries.
Catch up on the latest Log4J vulnerability news and analysis
The H2 warning warns that patching regardless “is a dangerous setting that should be avoided”.
But if the H2 console servlet is deployed on the web server, the user can add a security constraint to only allow certain users to access the console pages.
“To our knowledge, CVE-2021-42392 is the first JNDI-related unauthenticated RCE vulnerability released since Log4Shell, but we suspect it will not be the last,” Polkovnychenko and Menashe said.
Therefore, JFrog is continuing to explore similar flaws.
Incidentally, JNDI injection was exploited before Log4Shell by Taiwanese researcher Orange Tsai, who compromised internal Facebook systems in 2020 through a vulnerability in mobile device management platform MobileIron.
you might also like Java RMI services are often vulnerable to SSRF attacks – research
