深入分析H2数据库控制台中无需身份验证的RCE漏洞

简介

最近，JFrog安全研究团队披露了H2数据库控制台中的一个安全漏洞，其编号为CVE-2021-42392。这个安全漏洞与Apache Log4j中臭名昭著的Log4Shell漏洞（JNDI远程类加载）有着相同的根源。

H2是一个非常流行的开源Java SQL数据库，提供一个轻量级的内存解决方案，使得用户无需将数据存储在磁盘上。这使得它成为各种项目的首选数据存储解决方案：从Spring Boot等网络平台到ThingWorks等物联网平台。而com.h2database:h2包则是最流行的50个Maven包之一，具有近7000个工件依赖项。

由于目前任何与（Java）JNDI有关的东西都很敏感，所以，在介绍H2漏洞发现之旅之前，我们有必要先澄清一下成功利用该漏洞的前提条件和配置。

尽管这两个漏洞的根源相似，但由于以下因素，CVE-2021-42392漏洞并没有像Log4Shell（CVE-2021-44228）漏洞那样常见：

1、与Log4Shell不同，该漏洞的影响范围是“直接”的。这意味着，通常只有处理初始请求的服务器(H2控制台）才会受到该RCE的影响。与Log4Shell相比，这个漏洞的影响相对较小，因为易受攻击的服务器应该很容易找到。

2、在H2数据库的vanilla发行版上，默认情况下，H2控制台只监听本地主机连接：这使得默认设置是安全的。这与Log4Shell不同，Log4Shell在Log4j的默认配置中是可以利用的。然而，值得注意的是，H2控制台也可以很容易地被修改为监听远程连接。

3、许多供应商可能运行H2数据库，但并不会运行H2控制台。尽管除了控制台之外还有其他可利用这个漏洞的途径，但它们都严重依赖于上下文，所以不太可能暴露给远程攻击者。

也就是说，如果您运行的H2控制台暴露给了局域网（或者更糟糕的是，广域网），这个安全问题就很严重了（无需身份验证的远程代码执行漏洞），所以，您应该立即将H2数据库更新到2.0.206版本。

我们还发现，许多开发者工具都依赖H2数据库，并特意暴露了H2控制台（后面会举一些例子）。根据最近针对开发者的供应链攻击的趋势来看，如流行的存储库中的恶意包，应该提高对开发者工具对所有合理使用情况的安全性的重视。我们认为，依赖H2的开发者工具应尽快采用修复后的数据库版本，以提高其安全性。

【点击查看学习资料】或私信回复“资料”获取

我们为什么要扫描JNDI的漏洞？

我们从Log4Shell漏洞事件中得到的一个重要启示是，由于JNDI的广泛使用，必然会有更多的软件包受到与Log4Shell相同的根源的影响：接受任意的JNDI查找URLs。因此，我们调整了自动漏洞检测框架，将”javax.naming.Context.lookup“函数视为危险函数（sink），并将该框架释放到Maven仓库中，希望能找到与Log4Shell类似的安全漏洞。

我们得到的第一个有效命中点是关于H2数据库包的。在确认了这个问题后，我们把它报告给了H2的维护者，他们及时在新的版本中修复了这个问题，并在GitHub上发布了一个关键漏洞的公告。随后，我们也公布了一个高危漏洞，编号为CVE-2021-42392。

在这篇文章中，我们将介绍我们在H2数据库中发现的几个允许触发远程JNDI查询的攻击途径，其中一个途径可以实现无需身份验证的远程代码执行。

漏洞根源：JNDI远程类加载

简单来说，该漏洞的根本原因与Log4Shell类似：H2数据库框架中的几个代码路径将未经过滤的、攻击者控制的URL直接传递给了javax.naming.Context.lookup函数，这将允许远程加载代码库（又称Java代码注入，又称远程代码执行）。

具体来说，org.h2.util.JdbcUtils.getConnection方法需要一个驱动程序类名称和数据库URL作为参数。如果驱动程序的类可分配给javax.naming.Context类，则该方法会从中实例化一个对象并调用其查找方法：

else if (javax.naming