Log4Shell漏洞(CVE-2021-44228)早在幾個多月前就被披露了，雖然已經出現了很多防御方法。但該漏洞的影響至今都在。CISA最近發出警告，攻擊者正在使用Log4Shell利用VMWare Horizon服務器來發起攻擊。

到目前為止，對 Log4Shell 的大量利用都集中在眾所周知的、廣泛部署的應用程序上，例如 VMware Horizon、VMware vCenter 和 Unifi Network 應用程序。但這只是冰山一角。可能有數千個 Java 應用程序受到 Log4shell 不同程度的影響，并且有數千個新的漏洞利用路徑有待發現。攻擊者只需將注意力轉移到企業運行的特定應用程序上，在一兩天內，一個漏洞就可能被開發和武器化。

研究人員將在下面詳細介紹利用過程，并針對幾個應用程序執行遠程代碼：VMware Site Recovery Manager、Elasticsearch 5 和 OpenNMS。這樣做的目的是介紹Log4Shell 的廣泛和長期影響以及開發漏洞利用的速度。最終，NodeZero 作為一種滲透測試工具的目標之一是揭示各種漏洞、漏洞配置和受損憑證的真正影響。研究人員相信這種影響最好通過實際利用的證據來證明。

一般來說，Log4Shell 的利用過程包括兩個步驟：

識別 JNDI 查找注入點：這是未經身份驗證的攻擊者向應用程序發送的網絡請求，該請求將導致應用程序使用易受攻擊的 Apache log4j2 庫記錄消息，進而導致應用程序對攻擊者托管的服務器進行JNDI查找。

確定從攻擊者托管的服務器提供的 Java 有效負載：這是由易受攻擊的應用程序通過 JNDI 查找檢索并反序列化以執行遠程代碼的有效負載。

第一步，為了驗證 JNDI 查找注入點，研究人員使用了 dnslog.cn 上的 DNSLog 服務來捕獲來自易受攻擊的應用程序的 DNS 回調。Burp Collaborator 或 Interactsh 服務器等其他工具也可用于此目的。

使用了以下工具利用：

https://github.com/pimps/JNDI-Exploit-Kit

https://github.com/veracode-research/rogue-jndi

https://github.com/pimps/ysoserial-modified

利用 VMware Site Recovery Manager

VMware Site Recovery Manager 是“業界領先的災難恢復 (DR) 管理解決方案，旨在最大限度地減少發生災難時的停機時間。”它是 VMware Log4Shell 公告中受 Log4Shell 影響的眾多 VMware 應用程序之一。研究人員在實驗室中安裝了 8.3.0 版本。該應用程序公開了兩個端口，443 用于 SRM 應用程序，5480 用于管理 SRM 設備。

檢測

為了快速獲得成功，研究人員最初嘗試將 JNDI 有效負載插入 SRM 應用程序登錄表單的用戶名字段，但未能獲得 DNS 回調。因此，研究人員從 SRM 設備中提取 jar 文件并對其進行反編譯，并開始探測未經身份驗證的攻擊者可以訪問的 API 端點。在研究人員使用 error 參數確定 OAuth2LoginServlet 中的注入點后不久。servlet 可在 /dr/authentication/oauth2/oauth2login 端點訪問。

研究人員通過發送這種形式的 HTTP GET 請求來驗證注入點：

并得到了預期的 DNS 回調：

開發

與 Horizon 和 vCenter 一樣，SRM 使用 Apache Tomcat 作為其應用服務器。無論 Java 運行時版本如何，易受 Log4Shell 攻擊的基于 Tomcat 的應用程序很容易被用于遠程執行代碼。此處描述了通用技術，并由 JNDI-Exploit-Kit 工具自動執行。

研究人員在攻擊者服務器上啟動了 JNDI-Exploit-Kit 以提供 bash 反向 shell 有效負載，以及一個netcat偵聽器來捕捉端口9999上的反向shell：

然后觸發 HTTP 請求以觸發對 JNDI-Exploit-Kit 服務器的回調：

并以tomcat用戶的身份獲得了一個shell：

NodeZero 自動化了上述所有步驟，從而產生了以下證明，證明了針對易受攻擊的 SRM 實例執行遠程代碼：

惡意影響

SRM 通常不在公網上。研究人員只發現其中約 20 個使用 Shodan 公開曝光。然而，研究人員確實偶爾會在內部滲透測試中看到它。研究人員建議根據 VMware 的建議將設備更新到最新版本或應用此處描述的解決方法。

利用 Elasticsearch 5

Elasticsearch 是一個流行的開源分布式搜索和分析引擎。Log4Shell 的 Elasticsearch 聲明稱，由于 Elasticsearch 使用 Java Security Manager鎖定權限的方式，只有 Elasticsearch 5 容易受到遠程代碼執行的影響。在易受攻擊的 Elasticsearch 版本 6 及更高版本中，應用程序將對攻擊者控制的主機名執行 DNS 查找，但不會啟動與攻擊者控制的服務器的任何 TCP 連接。DNS 查找可用于泄露環境變量等系統信息，但無法遠程執行代碼。這可以通過 5.6 版與 6.0 版的 security.policy 文件中的差異看出。

為了進行測試，研究人員從位于 docker.elastic.co/elasticsearch 的 Elasticsearch docker repo 中設置了各種版本的 Elasticsearch 5。

檢測

研究人員發現了一些通過 Elasticsearch REST API 觸發 JNDI 查找的方法，方法是創建類型等資源或觸發棄用警告。然而，研究人員發現這些方法破壞性太大/噪音太大，或者它們不能普遍適用于所有版本的 Elasticsearch 5。

仔細查看 Github 上的源代碼和問題，研究人員發現了一個問題，表明在搜索請求中發送格式漏洞的 JSON 會觸發內部服務器漏洞，然后記錄下來。我們驗證了這在Elasticsearch 5的所有版本以及超過7.6的版本上都可以使用。例如：

觸發此漏洞：

這會導致 DNS 回調：

漏洞利用

Elasticsearch 在 Netty 框架上運行，因此針對 VMware Site Recovery Manager 的基于 Tomcat 的漏洞利用不適用于這里。研究人員決定找出一個最佳選擇，這是針對運行 Java 運行時版本 < 8u191 的應用程序的遠程類加載攻擊。這種遠程類加載攻擊由 rogue-jndi 等工具自動執行。

研究人員從 docker.elastic.co/elasticsearch 存儲庫中提取了一堆不同版本的 Elasticsearch 5，以了解它們捆綁的 Java 運行時版本。研究人員發現從 5.0.0 到 5.6.12 的所有版本都運行 Java 運行時版本 < 8u191，而從 5.6.13 到 5.6.16 的版本運行 Java 運行時 >= 8u191。雖然不是每個人都使用來自 docker.elastic.co/elasticsearch 的 Docker 鏡像來運行 Elasticsearch，但研究人員推測，大多數在野外運行的 Elasticsearch 5 實例都可以利用遠程類加載攻擊來遠程執行代碼。

研究人員發現，遠程代碼執行與任意代碼執行是不同的。特別是，由于Elasticsearch使用了Security Manager，可以直接使用Runtime運行主機命令。無法執行exec或ProcessBuilder，并且對文件系統的訪問受到限制。研究人員確實發現可以進行任意網絡調用，從 /tmp 之類的幾個目錄讀取/寫入，以及像加密礦工一樣在內存中運行東西。

例如，為了向托管在 10.0.220.54 的內部服務器發送網絡請求并將響應發送回攻擊者的服務器的 9999 端口，研究人員修改了 rogue-jndi 中的 HTTPServer 類以使用以下有效負載：

研究人員在 10.0.220.54 上設置了一個簡單的測試內部服務器：

然后在 9999 端口啟動 rogue-jndi 和 netcat 監聽器：

并發送請求以觸發 JNDI 查找：

導致從內部服務器竊取數據：

NodeZero自動執行上述所有步驟，從而產生了以下證明，展示了針對易受攻擊的 Elasticsearch 實例執行遠程代碼：

要利用運行 Java >= 8u191 的 Elasticsearch 5 版本，必須在 Elasticsearch 應用程序的類路徑中的庫中找到反序列化小工具。研究人員注意到 Elasticsearch 5 引入了 groovy-2.4.6-indy.jar 庫，該庫容易受到 CVE-2016-6814 的攻擊，并且可以使用此處描述的技術進行利用。但是，研究人員被Security Manager阻止執行此小工具，因此沒有進一步利用。

漏洞影響

使用 Shodan API，研究人員發現總共有 22914 臺 Elasticsearch 服務器未經身份驗證暴露在互聯網上。其中，1275 臺運行 Elasticsearch 5，其中 955 臺服務器運行版本 <= 5.6.12，因此很可能運行 Java 運行時<8u191。基于此，研究人員估計公網上大約有 900-1000 臺 Elasticsearch 5 服務器可利用上述技術進行遠程代碼執行。當然，在公網上擁有一個開放的 Elasticsearch 服務器已經很糟糕了。現在這些服務器也可以被濫用以轉入內部網絡。如果你運行的是易受攻擊的 Elasticsearch 版本，研究人員建議你遵循 Elasticsearch 公告中的修復指南更新到最新版本。

利用 OpenNMS

OpenNMS 是一個開源的網絡監控解決方案。研究人員使用此處的 docker-compose 模板安裝了OpenNMS Horizon 26.2.2版本。

檢測

為了快速獲得成功，研究人員嘗試將 JNDI 有效負載注入登錄表單的用戶名字段，并且成功了。

DNS回調：

使用cur：

研究人員檢查了日志，發現用戶名正在被HybridOpenNMSUserAuthenticationProvider類記錄。

在 Github 中：

漏洞利用

研究人員使用的 OpenNMS 版本使用 Java 11.07 運行，使用 Jetty 作為應用服務器。這意味著研究人員針對 VMware Site Recovery Manager 使用的基于 Tomcat 的漏洞利用以及針對 Elasticsearch 5 使用的基于 JVM 的舊漏洞利用將無法正常工作。不過利用option 3: 在本地 OpenNMS 中提取的一個庫中找到反序列化小工具。通過查看這些jar文件，研究人員找到了 commons-beanutils-1.9.4.jar，其中有一個眾所周知的反序列化小工具可以使用 ysoserial。

使用 ysoserial-modified 項目，研究人員創建了反向 shell 有效負載：

然后使用 JNDI-Exploit-Kit 為它提供服務，并在端口 9999 上啟動了一個 netcat 偵聽器：

然后發送 curl 請求來觸發漏洞利用：

并得到了反向shell：

NodeZero 自動化了上述所有步驟，從而產生了以下證明，展示了針對易受攻擊的 OpenNMS 實例執行遠程代碼：

OpenNMS 通常不部署為面向在公網，從攻擊者的角度來看，網絡監控解決方案通常是有吸引力的攻擊目標，因為它們通常存儲用于訪問環境中其他基礎設施的憑據。研究人員建議根據 OpenNMS 公告更新到最新版本。

總結

攻擊者是機會主義的。正如研究人員上面所展示的，Log4shell 是一個可以帶來很多機會的漏洞。普通攻擊者通常很難（如果不是不可能）發現導致已建立應用程序中未經身份驗證的遠程代碼執行的漏洞。Log4Shell 可以在許多應用程序中實現這一點，而且攻擊者可以輕松地將其作為武器。