MICROSOFT WINDOWS NFS V4中發現一個遠端程式碼執行漏洞

語言: CN / TW / HK

關於MICROSOFT WINDOWS NFS V4 的漏洞頻頻出現,七月份,趨勢科技研究團隊就公佈了一個CVE-2022-30136,該漏洞是在網路檔案系統 (NFS) 的實現中發現的,並且是由於對 NFSv4 請求的處理不當造成的。未經身份驗證的攻擊者可以利用此漏洞在 SYSTEM 上下文中執行任意程式碼。

NFS v4是NFS v3的繼承版本,主要針對WAN環境部署NFS做出改進並提出NFS分散式檔案系統方案。NFSv4為虛擬分配提供的新特性。隨著儲存虛擬分配功能的普及使用,nfsv4可以為預留固定大小的儲存空間;同樣在檔案系統上刪除檔案後,也能夠在儲存上面釋放相應空間。

趨勢科技研究團隊在最新Windows 網路檔案系統中發現一個遠端執行程式碼漏洞。該漏洞是由於 NFS 請求中的欄位驗證不正確造成的。遠端攻擊者可以通過向目標伺服器傳送惡意 RPC 呼叫來利用此漏洞。成功利用會導致在 SYSTEM 上下文中執行任意程式碼。不成功的利用可能會導致目標系統崩潰。

技術分析

Microsoft Windows 附帶了幾個旨在與非 Windows 檔案共享進行通訊和互動的網路功能。其中一個模組稱為網路檔案系統(NFS)。

網路檔案系統(NFS)是檔案系統之上的一個網路抽象,來允許遠端客戶端以與本地檔案系統類似的方式,來通過網路進行訪問。雖然 NFS 不是第一個此類系統,但是它已經發展並演變成 UNIX系統中最強大最廣泛使用的網路檔案系統。NFS 允許在多個使用者之間共享公共檔案系統,並提供資料集中的優勢,來最小化所需的儲存空間。

網路檔案系統(NFS)從1984 年問世以來持續演變,並已成為分散式檔案系統的基礎。當前,NFS(通過 pNFS 擴充套件)通過網路對分佈的檔案提供可擴充套件的訪問。

版本4由IETF開發,文件記錄在RFC 3010(2000年12月釋出)中,並在RFC 3530(2003年4月釋出)和RFC 7530(2015年3月釋出)中進行了修訂。NFS允許使用者像訪問本地檔案系統一樣訪問遠端檔案共享。共享可以設定不同的訪問級別和許可權,如讀寫、只讀。此外,還可以使用IP/UID/GID/Kerberos安全性。NFS使用ONC (Open Network Computing)遠端過程呼叫RPC (Remote Procedure Call)來交換控制訊息。ONC RPC最初是由Sun Microsystems開發的,也可以稱為Sun RPC。

當ONC RPC訊息通過TCP傳輸時,它們的前面有一個指定訊息長度的Fragment標頭結構。這允許接收方區分通過單個 TCP 會話傳送的多條訊息。 其他協議(如UDP)不使用該欄位。注意,所有多位元組值都是按照大端位元組順序編碼的。

一般ONC RPC請求訊息的結構如下:

Sun-RPC 訊息中的 Credentials 結構如下所述:

上述結構中的 Flavor 欄位用作 Contents 資料的型別識別符號。由於歷史原因,安全風格被稱為身份驗證風格。由於歷史原因,安全方法被稱為身份驗證方法。RPC規範中定義了多種安全規則,如AUTH_NONE(0)、AUTH_SYS(1)、AUTH_SHORT(2)、AUTH_DH(3)和RPCSEC_GSS(6)。

RPCSEC_GSS 的 Contents 欄位具有以下結構:

GSS Procedure欄位定義了四種類型:RPCSEC_GSS_DATA(0)、RPCSEC_GSS_INIT(1)、RPCSEC_GSS_CONTINUE_INIT(2) 和 RPCSEC_GSS_DESTROY(3)。另外,對於GSS Service欄位,有 rpc_gss_svc_none(1)、rpc_gss_svc_integrity(2) 和 rpc_gss_svc_privacy(3) 三種類型。在使用RPCSEC_GSS認證RPC客戶端時,必須使用RPCSEC_GSS_INIT和RPCSEC_GSS_CONTINUE_INIT RPC訊息建立安全上下文。首先,RPC 客戶端傳送一個 RPCSEC_GSS_INIT 訊息開始建立上下文。然後,RPC 伺服器決定是否需要另一個令牌來建立。如果是這樣,伺服器返回一個GSS_S_CONTINUE_NEEDED訊息,而客戶端需要傳送一個RPCSEC_GSS_CONTINUE_INIT訊息來繼續。

如果GSS Service欄位設定為2 (rpc_gss_svc_integrity),則Program-specific data欄位的字首結構如下:如果GSS Service欄位設定為3 (rpc_gss_svc_privacy),則對Program-specific data欄位進行加密。

當Program欄位設定為100003 (NFS), 並且Procedure欄位設定為1 (Compound)時,Program-specific data欄位具有如下結構:

在請求資料中,對於訊息中的每個操作:

操作碼 OP_CREATE(6) 的操作資料;

操作碼 OP_OPEN(18) 的操作資料;

操作碼 OP_SETATTR(34) 的操作資料;

Data (fatattr4)的格式如下:

ACL 的屬性資料(Bit12, 0x1000);

NFS 的 Windows 實現中存在緩衝區溢位漏洞。該漏洞是由於在處理 Nfs4SrvAclBuildWindowsAclsFromNfsAcl 中的 ACL 屬性資料時對 ACE_Count 欄位的錯誤驗證造成的。

只有在使用操作碼6、18、34設定ACL屬性資料時,該函式才容易受到攻擊。

伺服器分配一個大小為 (ACE_Count << 5) 的響應緩衝區。此大小在 Nfs4SrvAclBuildWindowsAclsFromNfsAcl 中儲存為 uint64_t。這種大小的緩衝區是使用 NfsMemMgrBufferAllocate 建立的。然而,NfsMemMgrBufferAllocate只接受uint32_t的緩衝區大小,所以請求大小的上32位被忽略。

這允許攻擊者指定一個 ACE_Count,這樣(ACE_Count << 5) & 0xFFFFFFFF < ACE_Count。這將導致函式稍後在使用緩衝區時發生緩衝區溢位。

特別是,ACE_Count值高於0x8000000將觸發此漏洞。

注意,ACE_Count = 0x8000000本身不容易受到攻擊,因為當請求的長度為零時,NfsMemMgrBufferAllocate將出錯。

攻擊者可以利用此漏洞溢位堆緩衝區。成功利用可能會導致在 SYSTEM 上下文中執行任意程式碼。不成功的利用將導致目標系統崩潰。

檢測攻擊

檢測裝置需要檢查RPC請求訊息中的Program欄位是否為100003(NFS),Procedure欄位是否為1(COMPOUND),Program Version欄位是否為4(NFS4)。如果找到,裝置必須檢查 ONC RPC 訊息中的程式特定資料。

檢測裝置應在每次操作中檢查易受攻擊的操作碼(6、18、34)。如果存在,裝置應檢查 ACL 屬性資料的操作。如果存在 ACL 屬性資料,則裝置應檢查 0x8000000 以上的 ACE_Count 欄位。

訊息中沒有固定的偏移量可用於忽略非易受攻擊的操作碼,因為 NFS 操作不會始終包含操作資料的長度。必須處理完整的訊息以確定是否有任何 ACL 屬性資料。

如果 ACE_Count 欄位大於 0x8000000,則應認為該流量是可疑的,可能有攻擊者在利用此漏洞。

總結

微軟已在2022年8月修復此漏洞。在他們介紹的辦法中,他們還列出了一種禁用NFSv4.1作為減少攻擊的方法。然而,這可能會導致有關功能的喪失。