研究團隊發現Eltima SDK 嚴重漏洞，影響多款云廠商產品

Sentinelabs研究團隊在驅動軟件中發現了許多嚴重的漏洞，影響了許多云服務。

像Amazon Workspaces這樣的云桌面解決方案依賴于包括Eltima SDK在內的第三方庫，提供“以太網USB”功能，允許用戶連接和共享本地設備，如網絡攝像頭。這些云服務被全球數以百萬計的客戶使用。

這些漏洞允許攻擊者升級特權，使他們能夠禁用安全產品、覆蓋系統組件、破壞操作系統或任意執行惡意操作。

SentinelLabs 的調查結果在 2021 年第二季度主動報告給易受攻擊的供應商，漏洞被跟蹤為 CVE-2021-42972、CVE-2021-42973、CVE-2021-42976、CVE-2021-42977、CVE-20291-4297 -2021-42980、CVE-2021-42983、CVE-2021-42986、CVE-2021-42987、CVE-2021-42988、CVE-2021-42990、CVE-2021-42992、CVE-2021-42992、CVE-2021-42992、CVE-2021-42924 -42996、CVE-2021-43000、CVE-2021-43002、CVE-2021-43003、CVE-2021-43006、CVE-2021-43637、CVE-2021-43638、CVE-26282、CVE-26282 、CVE-2021-42683、CVE-2021-42685、CVE-2021-42686、CVE-2021-42687、CVE-2021-42688。

供應商已發布安全更新以解決這些漏洞。其中一些是自動應用的，而另一些則需要客戶操作。

目前，SentinelLabs 還沒有發現野外濫用的證據。

在2020-2021年期間，世界各地的組織需要采用新的工作模式，包括遠程工作，以應對疫情。這要求組織使用各種解決方案，允許遠程工作員工安全地訪問其組織的資產和資源。因此，遠程工作市場已經有了巨大的增長，但安全性并沒有相應的發展。

在這篇文章中，研究人員在主要云服務中發現的多個漏洞的細節，包括：

需要注意的是：

這些漏洞源于Eltima開發和提供的一個庫，多個云提供商正在使用這個庫。

最終用戶(本例中為AWSWorkSpaces客戶端)和云服務(運行在AWS云中的AWSWorkSpaces)都容易受到研究人員下面將討論的各種漏洞的影響。這種特性可以歸因于服務器端和客戶端應用程序之間的代碼共享。

雖然研究人員已經確認了AWS、NoMachine 和 Accops 的這些漏洞，但測試范圍僅限于這些供應商，研究人員相信使用相同庫的其他云提供商也很有可能存在這些漏洞。

此外，在測試的供應商中，并不是所有的供應商都測試了客戶端和服務器端的漏洞，因此，還可能存在更多的漏洞實例。

技術細節

雖然這些漏洞影響多個產品，但下面的技術細節將主要以 AWSWorkSpaces作為示例。這就是研究起點，所有提到的產品的漏洞本質上都是一樣的。

Amazon WorkSpaces 是一項完全托管且持久的桌面虛擬化服務，使用戶能夠從任何受支持的設備隨時隨地訪問所需的數據、應用程序和資源。WorkSpaces 支持配置 Windows 或 Linux 桌面，并且可以快速擴展以向全球員工提供數千個桌面。

WorkSpaces通過將數據保存在終端用戶的設備上，并通過AWS云的強大功能提高可靠性，從而提高安全性。AWS云對于不斷增長的遠程勞動力來說是一項越來越有價值的服務。

如上所示，身份驗證和會話編排是通過HTTPS完成的，而數據流是PCoIP (PC over IP)或WSP (WorkSpaces Streaming Protocol)，這是一種私有協議。

它們之間的主要區別在于，在 Amazon WorkSpaces 上，只有 WSP 支持設備重定向，例如智能卡和網絡攝像頭，這就是漏洞所在。

WSP協議由幾個庫組成，其中一些是由第三方提供的。其中之一是Eltima SDK。Eltima開發了一個名為“USB Over Ethernet”的產品，它支持遠程USB重定向。

Amazon WorkSpaces 使用經過一些修改的相同產品，使其用戶能夠將 USB 設備重定向到其遠程桌面，從而允許他們將 USB 網絡攝像頭等設備直接從遠程桌面連接到 Zoom調用。

該程序與“客戶端”(連接到其他共享設備)和“服務器”(通過互聯網共享設備)捆綁在一起：

USB Over Ethernet 屏幕截圖

負責 USB 重定向的驅動程序是 wspvuhub.sys 和 wspusbfilter.sys，這兩個驅動程序都很容易受到攻擊，并且似乎自 2020 年初宣布 WSP 協議以來一直在使用。

在討論這些漏洞之前，了解Windows Kernel IO Manager (IOMgr)的工作原理是很重要的。當用戶模式線程發送 IRP_MJ_DEVICE_CONTROL 數據包時，它會在用戶模式和內核模式之間傳遞輸入和輸出數據，具體取決于調用的 I/O 控制 (IOCTL) 代碼。根據微軟的文檔，“一個 I/O 控制代碼是一個由多個字段組成的 32 位值”，如下圖所示：

輸入/輸出控制代碼結構

出于本文的目的，我們將重點關注兩個最低有效位 TransferType。文檔告訴我們，這些位指示系統將如何在 NtDeviceIoControlFile 系統調用的調用者和處理 IRP 的驅動程序之間傳遞數據。

使用IRP在內核模式和用戶模式之間交換數據有三種方式：

METHOD_BUFFERED——被認為是最安全的。使用此方法 IOMgr 會將調用者輸入數據從提供的調用者輸出緩沖區中復制出來，然后再復制到提供的調用者輸出緩沖區中。

METHOD_IN/OUT_DIRECT——根據數據方向，IOMgr 將提供一個描述緩沖區的 MDL，并確保執行線程對緩沖區具有讀/寫訪問權限，IOCTL 例程然后可以將緩沖區鎖定到內存。

METHOD_NEITHER——被認為更容易出現故障。IOMgr 不映射/驗證提供的緩沖區，IOCTL 處理程序接收用戶模式地址，這主要用于高速數據處理。

易受攻擊的 IOCTL 處理程序是 0x22005B 和 0x22001B，其中包含多個漏洞并且在所有易受攻擊的產品中都是相同的。

此代碼處理類型為 METHOD_NEITHER (Type3InputBuffer) 的用戶緩沖區

這意味著 IOCTL 處理程序負責根據用例驗證、探測、鎖定和映射緩沖區本身。

這為利用該設備提供了許多可能性，例如雙重提取和任意指針取消引用，這也可能導致其他漏洞。在下圖中，可以看出這段代碼中根本不存在緩沖區驗證：

IOCTL 0x22001B 處理程序

下面是這段代碼的簡要解釋：

首先，例程檢查調用進程是32位還是64位(紅色箭頭)。

然后，它根據第一次檢查的結果(藍色箭頭)決定是使用alloc_size_64bit還是alloc_size_32bit。

接下來，使用用戶控制的大小參數(粉色箭頭)調用ExAllocatePoolWithTag_wrapper。

此時，代碼繼續處理處理32位memmove(黃色箭頭)和64位memmove(綠色箭頭)的塊。從圖中可以看出，在這個階段存在對用戶控制的數據進行不安全的算術操作的情況，在計算副本大小時沒有進行溢出檢查，這可能導致整數溢出，最終可能導致任意代碼執行。

一般來說，訪問(讀/寫)用戶模式地址需要探測。處理Type3InputBuffer還需要將頁面鎖定到內存中，并且只獲取一次數據。

導致此代碼溢出的最簡單方法是為分配和復制函數傳遞不同的參數。這可以通過制作一個特殊的 IRP 來完成：

其中copy_size_64位或copy_size_32位大于alloc_size_32位或alloc_size_64位

即使副本大小和分配大小是完全相同的參數，由于在計算 memmove 大小參數時存在不安全的算術運算，代碼仍然可以被利用。

在簡化版本中，為了觸發該漏洞，攻擊者可能會發送以下IOCTL（假設運行64位進程）：

此代碼將導致分配 0x20 字節：

以及0x435字節的復制：

由于研究人員同時控制數據和大小，這使得在內核模式下實現代碼執行是一個非常強大的原語。

BSoD 概念驗證

使用來自OSR的DeviceTree工具，研究人員可以看到這個驅動程序在沒有ACL強制的情況下接受IOCTLs(注意：某些驅動程序在 IRP_MJ_CREATE 例程中獨立處理對設備的訪問):

使用DeviceTree軟件檢查設備的安全描述符

這意味著該漏洞可以從沙箱中觸發，并且可能在本地權限升級之外的上下文中被利用。例如，它可能被用作第二階段的瀏覽器攻擊(盡管大多數現代瀏覽器都有一個允許IOCTLs請求的列表)或其他類似的沙箱。

攻擊目標

使用上述客戶端版本的用戶容易出現漏洞，如果成功利用這些漏洞，可能會被用來獲得高權限。由于易受攻擊的代碼同時存在于遠程和本地端，因此遠程桌面也會受到此漏洞的影響。

這些高度嚴重的漏洞可能允許計算機上的任何用戶(即使沒有特權)升級特權并以內核模式運行代碼。這些漏洞的明顯弊端之一是，它們可以被用來繞過安全產品。訪問組織網絡的攻擊者還可以訪問未打補丁的系統上的執行代碼，并利用此漏洞獲得本地權限提升。然后攻擊者可以利用其他技術來轉向更廣泛的網絡，比如橫向移動。

目前，Accops和NoMachine都進行了回應。

參考及來源：

https://www.sentinelone.com/labs/usb-over-ethernet-multiple-privilege-escalation-vulnerabilities-in-aws-and-other-major-cloud-services/