標題：利用Apache Cassandra用戶定義函數實現遠程代碼執行

近日JFrog的安全研究團隊披露了Apache Cassandra中的一個RCE(遠程代碼執行)漏洞，該漏洞被分配給了CVE-2021-44521 (CVSS 8.4)。這個Apache安全漏洞很容易被利用，並且有可能對系統造成嚴重破壞，但幸運的是，它只體現在Cassandra 的非默認配置中。

Cassandra 是一個高度可擴展的分佈式NoSQL 數據庫，由於其分佈式特性的優勢，它非常受歡迎。 Cassandra 被Netflix、Twitter、Urban Airship、Constant Contact、Reddit、Cisco、OpenX、Digg、CloudKick、Ooyala 等企業使用。 Cassandra 在DevOps 和雲原生開髮圈中也非常受歡迎，這從它對CNCF 項目（例如Jaeger）的支持可以看出。

一些公司甚至提供基於Cassandra 的基於雲的一站式解決方案，例如DataStax（一種無服務器、多雲DBaaS）。

在這篇文章中，我們將介紹研究人員是如何發現RCE 安全漏洞的背景，提供有關PoC 漏洞利用的詳細信息，並分享建議的修復和緩解選項。

UDF 和NashornCassandra 提供了創建用戶定義函數(UDF) 以執行數據庫中數據的自定義處理的功能。

Cassandra UDF 默認可以用Java 和JavaScript 編寫。在JavaScript 中，它使用Java 運行時環境(JRE) 中的Nashorn 引擎，這是一個運行在Java 虛擬機(JVM) 之上的JavaScript 引擎。

在接受不受信任的代碼時，不保證Nashorn 是安全的。因此，任何允許此類行為的服務都必須始終將Nashorn 執行包含在沙箱中。

例如，運行以下Nashorn JavaScript 代碼允許執行任意shell 命令-

Cassandra 的開發團隊決定圍繞UDF 執行實現一個自定義沙箱，該沙箱使用兩種機制來限制UDF 代碼：

1.使用白名單和黑名單的過濾機制（只允許匹配白名單和不匹配黑名單的類）：

2.使用Java 安全管理器來強制執行代碼的權限（在默認配置中，不授予權限）

如NashornEscape項目實施沙箱來保護Nashorn 代碼執行。

通過Nashorn 訪問Java 類Nashorn 引擎通過使用Java.type 提供對任意Java 類的訪問。

例如： var System=Java.type('java.lang.System') 將允許我們使用System 變量訪問java.lang.System 數據包。

具有足夠權限的用戶可以使用create函數查詢創建任意函數。例如，此函數會將其輸入打印到控制台：

用戶可以使用以下SELECT 查詢調用該函數。

CVE-2021-44521什麼時候會被利用當我們研究Cassandra UDF 沙箱實現時，我們意識到特定（非默認）配置選項的混合可以讓我們濫用Nashorn 引擎、逃離沙箱並實現遠程代碼執行，這就是CVE-2021-44521 的漏洞。

當cassandra.yaml 配置文件包含以下定義時，Cassandra 部署容易受到CVE-2021-44521 的攻擊：

請注意，這些是唯一需要的非默認配置選項，因為啟用UDF 時，所有用戶都可以創建和執行任意UDF，這包括默認啟用的匿名登錄(authenticator=AllowAllAuthenticator)。

請注意，Cassandra 也可以通過Config.java 配置文件進行配置，該文件支持與上述相同的標誌。

前兩個標誌啟用對Java 和JavaScript的UDF 支持。

enable_user_defined_functions_threads 是利用CVE-2021-44521 的關鍵。

Cassandra 還支持在UDF 中使用的其他腳本語言，例如Python。

JFrog 產品是否容易受到CVE-2021-44521 的攻擊？

JFrog 產品不受CVE-2021-44521 攻擊，因為它們不使用Apache Cassandra。

解釋enable_user_defined_functions_threads

源代碼（Config.java）如下：

enable_user_defined_functions_threads 默認設置為true，這意味著每個調用的UDF 函數都將在不同的線程中運行，並且具有沒有任何權限的安全管理器，我們將在後面的部分中介紹針對此默認配置的DoS 攻擊。

當該選項設置為false 時，所有調用的UDF 函數都在Cassandra 守護程序線程中運行，該線程具有具有某些權限的安全管理器。我們將展示如何濫用這些權限來實現沙箱逃逸和RCE。

請注意，源代碼中的文檔暗示關閉該值是不安全的，但由於拒絕服務漏洞。我們將演示關閉此值直接導致遠程代碼執行。

RCE通過沙箱逃逸UDF 沙箱不會直接允許我們在服務器上執行代碼，例如通過調用java.lang.Runtime.getRuntime().exec()。

在研究沙箱實現時，我們發現我們可以使用至少兩種方式逃離沙箱：

濫用Nashorn 引擎實例；

java.lang.System 的load 和loadLibrary 函數；

由於Cassandra 的類過濾機制允許訪問java.lang.System，所以這兩種方法都可以用來逃避沙箱。

第一種方法：濫用Nashorn 引擎實例為了完全逃離沙箱，我們必須：

1.禁用類過濾機制；

2.在沒有安全管理器的情況下運行；

當enable_user_defined_functions_threads 設置為false 時，我們的UDF 代碼運行在daemon 線程中，該線程具體有調用setSecurityManager 的權限！這立即允許我們關閉安全管理器，所以現在我們只需要繞過類過濾機制。

在Nashorn 上運行JavaScript 代碼時，我們可以使用this.engine 來訪問Nashorn 實例引擎。正如Beware the Nashorn 博客中所述，這實際上允許我們通過創建一個不受類過濾機制限制的新腳本引擎來繞過任何類過濾器。

但是，較新的Java 版本（8u191 及更高版本）已收到緩解措施，可在安全管理器處於活動狀態時阻止訪問this.engine。

我們可以調用setSecurityManager 來禁用安全管理器，然後訪問this.engine。

PoC 查詢結果如下所示：

此查詢將關閉安全管理器，將其設置為空，然後創建一個不受類過濾機制限制的新腳本引擎，在Cassandra服務器上運行任意shell命令。

執行PoC 是為了在Cassandra 服務器上創建一個名為“hacked”的新文件：

第二種方法：java.lang.System的load和loadLibrary函數除了Nashorn 轉義技術之外，還有更多的庫函數未被類過濾器過濾，並且在安全管理器關閉時可能被濫用於代碼執行。

例如，java.lang.System 的load 方法允許我們通過指定絕對路徑來加載任意共享對象。

假設攻擊者可以以某種方式將惡意共享對象文件上傳到易受攻擊的系統（只要攻擊者知道上傳文件的完整路徑，受害者設備上的上傳目錄是什麼並不重要），可以使用加載方法加載庫，它可以運行任意代碼作為其入口例程的一部分。

其他值得注意的漏洞當我們在一些非默認配置(儘管合理)上運行Cassandra和相關工具)時，我們發現並披露了一些值得一提的漏洞。這些選項被記錄為不安全，但我們想強這些漏洞及其確切影響，以便供應商不要在可公開訪問的網絡中部署此類配置。

Cassandra UDF 拒絕服務當啟用UDF函數並將enable_user_defined_functions_threads標誌設置為true(默認值)時，惡意用戶可以創建一個將關閉Cassandra守護進程的UDF，這是由UDF超時機制的行為引起的，該機制由user_defined_function_fail_timeout標誌控制。

如果UDF 函數運行超過分配的時間，則整個Cassandra 守護程序將被閉（不僅僅是運行UDF 的線程）。儘管這是記錄在案的行為，但攻擊者可以通過創建一個使用while(true) 永遠循環的函數來輕鬆地對整個數據庫進行DoS。

目前還沒有什麼直接方法緩解此漏洞（將user_function_timeout_policy 標誌從die 更改為ignore 可能會導致更嚴重的DoS），儘管可以通過確保低權限用戶無法創建任意UDF 來間接緩解該漏洞。

通過不安全對象反序列化的StressD RCECassandra 包含一個名為cassandra-stressd 的工具，用於對數據庫進行壓力測試。該工具已被Apache 記錄為“不安全”工具；

這是一個面向網絡的工具，默認情況下只監聽localhost 接口；

但是，這個工具可以通過提供-h標誌和IP地址來監聽任何接口；

來自套接字的輸入直接由StressServer.java 反序列化，這意味著攻擊者可能會提供一個序列化的“gadget”對象，導致反序列化時執行任意代碼：

這個漏洞的利用取決於正在運行的Cassandra 實例的類路徑中的可用類。

我們敦促用戶確保他們沒有運行帶有指向外部接口的-h 標誌的cassandra-stressd 工具。

如何修復CVE-2021-44521？我們強烈建議所有Apache Cassandra 用戶升級到以下版本，它可以緩解CVE-2021-44521：

3.0.x 用戶應升級到3.0.26

3.11.x 用戶應升級到3.11.12

4.0.x 用戶應升級到4.0.2

Apache 的修復添加了一個新標誌——allow_extra_insecure_udfs（默認為false），它不允許關閉安全管理器並阻止對java.lang.System 的訪問。

如果用戶希望他們的udf與沙箱外的元素交互(並且不介意潛在的安全風險)，可以打開該標誌來恢復原來的行為(不推薦!)。

如何緩解CVE-2021-44521？對於無法升級Cassandra實例的用戶，我們建議採取以下緩解措施：

如果UDF沒有被積極使用，可以通過將enable_user_defined_functions設置為false(這是默認值)來完全禁用它們；

如果需要UDF，請將enable_user_defined_functions_threads 設置為true（這是默認值）；

通過刪除以下權限來刪除為不受信任的用戶創建、更改和執行函數的權限：ALL FUNCTIONS、ALL FUNCTIONS IN KEYSPACE 和FUNCTION 用於CREATE、ALTER 和EXECUTE 查詢。

這可以使用以下查詢來完成，方法是將role_name替換為所需的角色。

總結最後，我們強烈建議將Cassandra 升級到最新版本，以避免CVE-2021-44521威脅。