Windows 10中的 RCE漏洞：通過惡意鏈接發起

研究人員通過 IE11/Edge Legacy 和 MS Teams 在 Windows 10 上發現了一個驅動代碼執行漏洞，該漏洞由 Windows 10/11 默認處理程序ms-officecmd: URI中的參數注入觸發。

通過其他瀏覽器進行利用需要受害者接受一個不起眼的確認對話框，或者，惡意 URI 可以通過執行不安全 URL 處理的桌面應用程序傳送。

 利用過程

代碼執行由惡意網站觸發，該網站執行 Javascript 重定向到精心制作的 ms-officecmd: URI(Microsoft Office UWP 應用程序用于啟動其他 Office 桌面應用程序的方案)。研究人員利用 URI 處理程序中的參數注入漏洞并繞過 Electron 中的安全措施，通過 Microsoft Teams Electron 應用程序的 --gpu-launcher 參數注入任意操作系統命令。

通過 MS Edge 在 Windows 10 上驅動 RCE的視頻請點此。

這是上面視頻中使用的精心制作的 ms-officecmd: URI（注意，JSON進行了縮進）：

除Internet Explorer和Microsoft Edge Legacy之外的瀏覽器在打開惡意URI之前會顯示一個相當不顯眼的確認對話框：

顯示 IE 和 Edge Legacy 中缺少的確認對話框的不同瀏覽器

作為通過惡意網站進行利用的替代方法，精心制作的 ms-officecmd: URI 也可以通過執行不安全 URL 處理的桌面應用程序傳送。

此特定漏洞利用的先決條件是已安裝 Microsoft Teams 但未運行。在以下部分中，研究人員還將展示如何在MS Teams 幫助的情況下以其他方式濫用方案和參數注入。

雖然在進行本研究時 Windows 11 尚未發布，但它也仍然受到 ms-officecmd: URI 處理程序中相同參數注入漏洞的影響。

 改進惡意 URI 攻擊場景

2021 年 1 月，研究人員花了一些時間分析流行的桌面應用程序如何處理用戶提供的 URI，并在其中發現了代碼執行漏洞。

為了展示研究人員在 Windows 上的發現的利用他們主要利用文件相關方案(nfs、dav、file 等)以及托管在網上可訪問文件共享上的可執行文件/jar 文件。這些有效載荷的一個警告是，它們要么需要安裝 Java，要么需要一個對話框來運行要確認的可執行文件。

在此過程中，研究人員還在 WinSCP 的 URI 處理中發現了一個代碼執行漏洞。WinSCP實際上是在Windows上處理各種URI方案的標準，但它并沒有預裝在操作系統中。第三方URI處理程序的漏洞并不新鮮，之前的示例包括：

Steam 中的代碼執行：URI 處理程序(2012) ；

影響注冊自定義協議的 Electron 應用程序的代碼執行 (CVE-2018-1000006)]；

teamviewer10 中的代碼執行：URI 處理程序 (CVE-2020-13699)；

研究人員希望通過在 Windows 預裝的 URI 處理程序中找到代碼執行漏洞，進一步改進基于惡意 URI 的攻擊場景。

 在Windows 10中枚舉URI處理程序

Windows 10提供了大量與不同操作系統功能或其他 Microsoft 軟件相關的自定義 URI 處理程序。

出于研究目的，查找已注冊 URI 處理程序的一種非常方便的方法是在注冊表中重復搜索 'URL Protocol' ：

在 Windows 注冊表中查找 URI 處理程序

Computer\HKEY_CLASSES_ROOT\* 中的任何命中都意味著包含文件夾的名稱對應于已注冊 URI 處理程序的方案。注冊表還包含更多信息，例如用于調用相應處理程序的 shell 命令。一種非常簡單且更實用的方法來幫助找出與該方案相關的內容是將其輸入到瀏覽器地址欄中，然后輸入 :，最后按 Enter：

通過 Edge 的 `calculator:` 方案打開 calc.exe的視頻請點此。

 ms-officecmd：過于復雜

ms-officecmd: 該方案因其有名稱而立即引起了研究人員的注意：MS Office 是一個非常復雜的應用程序套件，具有許多遺留功能和悠久的可利用歷史。最重要的是，該方案以'command'的縮寫結尾，這表明注入的復雜性和潛力更大。

當研究人員開始使用它時，發現一個名為 LocalBridge.exe 的可執行文件，它會短暫運行，，但不會產生明顯的外部影響。為了更深入地了解發生了什么，研究人員查看了 Windows 事件日志，其中包含一些非常有用的信息：

.NET JsonReaderException 通過打開 URI `ms-officecmd:invalid` 被觸發

當打開一個由空的、有效的JSON有效載荷ms-officecmd:{}組成的URI時，沒有發生同樣的異常，這為研究人員提供了關于有效URI結構的第一個提示。

觀察到 URI 處理程序中的 JSON 解析最終證實 ms-officecmd: URI 有可能做非常復雜的事情，因此有必要弄清其功能。

反轉 LocalBridge.exe 和 AppBridge.dll

為了了解更多信息，研究人員決定從反編譯 LocalBridge.exe 開始：

`LocalBridge.exe` 的反編譯源：URI 驗證和 `LaunchOfficeAppValidated` 調用 (dotPeek)

C# 代碼包含有關有效 JSON 有效載荷結構的更多信息：

不幸的是，這并沒有引起 LocalBridge.exe 的任何可觀察到的行為。進一步分析AppBridge.dll，因為它包含LaunchOfficeAppValidated方法，JSON有效載荷最終會被傳遞給：

`LocalBridge.exe` 的反編譯源：從 `AppBridge.dll` (dotPeek) 導入的 `LaunchOfficeAppValidated`

研究人員通過反匯編原有AppBridge.dll 庫提取了更多潛在的 JSON 屬性名稱，但如何使用它們并不是很明顯。

`AppBridge.dll`：相關的 unicode 字符串

 調試 Office UWP 應用 (Electron PWA)

當對LocalBridge.exe/AppBridge.dll的分析沒有迅速產生預期的結果時，研究人員同時采用了另一種方法：與其剖析處理ms-officecmd: uri的應用程序，不如試著檢查生成這種uri的應用程序。

雖然研究人員不確定哪些應用程序會這樣做，但之前偶然發現的 Office UWP 應用程序可能是一個有用的應用程序：

該應用程序可以通過自定義方案 ms-officeapp: 打開，它看起來與研究人員研究的主題 ms-officecmd 非常相似：

該應用程序的行為與 https://www.office.com/ 上的 Office365 網絡界面幾乎相同，不同之處在于它允許打開一些無法從網絡打開的桌面應用程序

Office UWP 應用預裝在 Windows 10 上

根據經驗，每當Office UWP應用程序觸發一個Office桌面應用程序被打開時，就在內部使用ms-officecmd:方案。使用 Microsoft 自己的“Edge DevTools Preview”應用程序，研究人員能夠進入進程并調試 Office UWP 應用程序。

Microsoft Edge DevTools Preview（右）提供 Office UWP 應用（左）作為調試目標

獲取研究人員想要的信息既快速又簡單：

執行一個全局源代碼搜索(ctrl + shift + f)來找到scheme關鍵字'ms-officecmd'的出現：唯一找到的出現是launchProtocol常量的定義；

執行另一個搜索來發現launchProtocol常量的用法：第一個命中是在launchViaProtocol方法中發現的；

在launchViaProtocol中添加一個斷點并嘗試觸發它：點擊左側欄的Outlook圖標實現了這一點。

 從局部變量中提取 JSON 載荷結構

Office UWP 應用：`launchProtocol` 常量定義（Edge DevTools 預覽版）

Office UWP 應用：`ms-officecmd:` 從局部變量 `n` 中提取的 JSON 載荷（Edge DevTools 預覽版）

恢復 JSON 有效載荷的更快替代方法是使用 Microsoft Sysinternals Process Monitor 工具記錄與 LocalBridge.exe 關聯的 Process Create 事件：

`ms-officecmd:` 進程監視器顯示的 JSON 有效載荷

 ms-officecmd：基本的 JSON 載荷結構

使用提取的 JSON 載荷，就可以通過 ms-officecmd: URI 打開 Office 桌面應用程序。具體來說，從 Office UWP 應用中提取的載荷可用于打開 Outlook：

在隨后的測試中，很明顯有兩個屬性可以被操縱，產生立即可見的效果：

appId：要打開的Office桌面應用程序；

filename：要在指定應用程序中打開的文件的文件路徑或URL；

name 和 command 屬性被驗證并以較低的優先級處理；

在安裝了基本 Office 的計算機上，研究人員列舉了以下 appId 映射：

• 1: Access
• 2: Excel
• 5: Teams
• 6: Skype for Business
• 7: One驅動
• 8: Outlook
• 10: PowerPoint
• 12: Publisher
• 14: Word
• 18: OneNote
• 21: Skype

 Outlook 網絡釣魚問題

第一個值得注意的發現是，當在filename屬性中提供 http(s)URL 時，Outlook 將在 IE11 驅動的嵌入式 web 視圖中呈現相應的網頁。沒有說明網頁的來源，甚至沒有提供顯示內容源自外部網頁的事實。這種行為可能會被濫用來發起非常可信的網絡釣魚攻擊，尤其是因為 mailto: 鏈接根據本地配置預計會打開用戶的電子郵件程序：

使用 `ms-officecmd:` 和 Outlook 進行網絡釣魚攻擊：Outlook 窗口內顯示的登錄表單是攻擊者控制的網頁，相關視頻請點此。

 Outlook 代碼執行問題

Outlook 的意外打開行為也可能被濫用，以通過更多用戶交互實現代碼執行。雖然 Outlook 不允許 file:// URL，但允許使用 C:// "url scheme" ，然后作為本地路徑的驅動號。此外，我們在AppBridge.dll中添加了一個繞過文件擴展名檢查的尾隨/，但稍后在打開可執行文件時將被忽略。

這個 PoC 要求用戶確認一個額外的警告對話框，但研究人員認為上下文足以誤導一些更高級的用戶接受：

使用 `ms-officecmd:` 和 Outlook 從 Chrome 進行用戶交互的 RCE 攻擊，詳細視頻請點此。

以下是點擊惡意網頁上的鏈接時發生的情況：

通過動態添加iframe指向outlook.exe(在本文中，這是一個重命名為“PuTTY”的可執行文件)，一個名為outlook.exe的惡意可執行文件被保存到受害者的下載文件夾中。

看似無害的mailto: link目標被替換為一個惡意的ms-officecmd: URI，它在其filename屬性中引用下載的可執行文件(注意左下角的懸浮鏈接預覽)；

用戶確認“Open LocalBridge?”對話框(不是明確的安全警告)；

當 Outlook 啟動時，它會顯示一個關于打開潛在不安全超鏈接的警告對話框。用戶確認打開本地“outlook.exe”文件，因為他們希望outlook被打開；

執行下載的文件(彈出PuTTY窗口)；

 filename屬性參數注入

上面顯示的問題濫用了filename屬性，因為它提供了僅在Outlook應用程序上下文中未預料到的和錯誤處理的值，但在ms-officecmd: URI處理程序的更抽象的上下文中是完全有效和預期的：除了具有多種不同文件擴展名的本地文件路徑外，大多數Office應用程序還允許通過http(s)url直接打開托管在 Web 上的文檔，就像Microsoft SharePoint/OneDrive中的文件一樣。

下一個發現是通過攻擊 URI 處理程序本身處理filename屬性的方式，進一步推動了濫用的可能性。即使沒有完全詳細了解 AppBridge.dll 的內部工作原理，也可以假設，為了使用指定參數打開指定的 Office 應用程序，URI 處理程序最終要么生成并執行 shell 命令，要么運行它的可執行文件直接。在任何情況下，攻擊者控制的filename屬性都需要作為 shell 命令的一部分或參數傳遞。當研究人員嘗試使用常見的命令和參數注入技術時，研究人員發現可以使用簡單的 "(雙引號+空格)序列來突破filename規范。

此參數注入代表了此處概述的發現的核心中最重要的問題。在研究人員開始實際利用之前，這里有一個視頻演示了最基本的參數注入：

使用 `filename` 參數注入來注入 `/q` 開關：注意打開第二個 URI 時沒有藍色啟動（加載）屏幕，詳細視頻請點此。

這是視頻中使用的 URI（需要對引號進行轉義以免破壞 JSON）：

 加載惡意 Word/Excel 插件

在發現可以將參數注入 Office 應用程序的啟動命令后，下一步自然是檢查哪些類型的參數可供研究人員使用。在已記錄的 Microsoft Office 產品命令行開關中，與在啟動時加載插件有關的命令行開關似乎最有希望。

研究人員試驗了以下插件類型：

普通 .dll 和 .wll 文件；

VSTO 插件；

“Office”（網絡）插件；

不幸的是，研究人員無法使應用程序在啟動時正確加載任何插件。

嘗試使用“-l”開關加載 Word 插件失敗，因為應用程序似乎將其解釋為要打開的文檔文件

 Teams MITM，使用 --host-rules 進行身份驗證泄漏

雖然研究人員對以文檔為中心的 Office 應用程序的參數注入實驗并沒有產生更多對現實世界攻擊者很感興趣的發現，但還有另一組應用程序顯示了巨大潛力：Microsoft Teams 和 Skype 是基于Electron 框架的，因此配備了大量有用的 Electron 命令行參數和 Node.js 命令行參數。

具有濫用潛力是 --host-rules，此參數可用于重新映射 IP 地址和主機名，從而將應用程序的所有相關網絡流量定向到所選目標。使用新域作為映射目標時，只要為新域正確設置了 TLS，就不會出現 TLS 錯誤。通過添加 --ignore-certificate-errors 開關，甚至不需要這樣做。借助反向代理，甚至只是偵聽 Web 服務器，攻擊者可以提取發送到 Microsoft Teams 后端服務的所有敏感信息，包括身份驗證令牌和消息。還可以利用反向代理來修改 API 響應，并向受害者冒充任何MS Teams 用戶。

當研究人員試圖制作一個有效的有效載荷以注入這些參數時，它們不得不克服另外兩個障礙：

作為對關鍵 CVE-2018-1000006 的修復，Electron 更改了他們的命令行解析邏輯，以在 URI 之后刪除其他參數。檢查源代碼，研究人員發現了 1-letter URI 方案的異常，以跳過對包含驅動號(即 C:/)的 Windows 文件路徑的過濾。這允許研究人員在像 a:/b/ 這樣的虛假filename前綴之后注入 Electron 參數，這是被Electron和AppBridge.dll所接受的。

MS Teams有時不會為包含的filename參數啟動.(句號)字符由于在AppBridge.dll中檢查文件擴展名。在下面的視頻中，通過將目標IP地址3.64.176.207轉換為其整數格式54571215來繞過此檢查。

使用注入的 `--host-rules` 和 `--ignore-certificate-errors` 參數將 MS Teams https 流量重定向到研究人員自己的服務器，詳細視頻請點此。

請注意，在這個演示視頻中，請求沒有轉發到Team的實際后端，從而導致連接錯誤。

這是視頻中使用的 URI：

通過 --inspect 調試器從本地網絡執行 Teams/Skype 代碼

另一個有希望的參數是 Node.js --inspect 參數，它可用于調試 Node.js Javascript 環境。該參數指定可用于連接調試器的網絡接口和端口號。出于安全原因，默認情況下只能通過本地接口 127.0.0.1 進行調試。在下面的視頻中，研究人員通過 --inspect="0.0.0.0:28966" 開關覆蓋了該設置，以便在端口 28966 上為任何網絡接口接受調試器連接。連接調試器后，研究人員使用標準的 Node.js 庫來執行命令：require("child_process").exec("")

再次制作有效的有效載荷需要一些技巧：

由于Skype這樣打開時filename參數的處理方式，所以在注入其他參數之前，需要在假filename后面多加一個"字符

指定偵聽接口時，不接受 IP 地址整數格式，迫使研究人員將 .人物。因此，這一次，研究人員通過在惡意filename有效載荷的末尾添加一個 / 字符來繞過 AppBridge.dll 中的文件擴展名檢查。

通過單擊 VM 內的惡意鏈接并將調試器從主機系統連接到 Skype 進程來展示本地網絡漏洞，視頻請點此。

這是視頻中使用的 URI：

請注意，對于易受攻擊的設置，此攻擊還可以與例如 DNS 重新綁定或（最近改進的）NAT Slipstreaming 技術相結合，以通過瀏覽器實現 RCE，而無需本地網絡訪問。

通過 --inspect 調試器和 MITM 與 SOP 繞過團隊代碼執行；

研究人員實際上還沒有確認這個潛在的漏洞可以運行，但無論如何都想分享它的想法，因為它的設置很有趣。這個想法是將上面部分中的 --host-rules 和 --inspect 開關與 --disable-web-security Chromium 開關結合起來，這應該允許研究人員利用它們對 Chromium Javascript 上下文的控制來連接到節點.js 調試器并執行任意命令：

1.MS Teams 是通過惡意網站啟動的，并注入了以下參數：

• --host-rules="MAP
• --ignore-certificate-errors
• --inspect=1337
• --disable-web-security

2.在啟動期間，位于

3.Electron Chromium 瀏覽器中的惡意Javascript 請求位于 http://127.0.0.1:1337/json/list 的 Node.js 調試器元數據終端，以檢索調試器連接所需的

4.Electron Chromium 瀏覽器中的惡意 Javascript 連接到位于 ws://127.0.0.1:1337/

 通過 --gpu-launcher 命令注入執行團隊代碼

根據研究人員在開始向 Microsoft 提交報告之前所做的最后一項發現，他們終于通過惡意 ms-officecmd: URI 實現了任意代碼執行。此 PoC 的先決條件是安裝了 MS Teams 但未運行。

研究人員的惡意載荷基于 CVE-2018-1000006 的漏洞利用，它利用 --gpu-launcher 參數注入在 Electron 應用程序啟動時執行的任意命令。為了利用研究人員的參數注入和 MS Teams 進行漏洞利用，研究人員需要：

1.使用 1 個字符的 URI 方案啟動filename參數以通過 AppBridge.dll 驗證，但也不會遇到針對 CVE-2018-1000006 的 Electron 修復（Electron 仍然允許在 Windows filename之后添加其他參數，例如“C:”）；

2.注入額外的 --disable-gpu-sandbox 參數；

3.繞過AppBridge.dll中的文件擴展名檢查.字符或在惡意filename值后附加/

4.添加一個shell指令，它可以用來將諸如&&這樣的命令鏈在注入命令的末尾，以保持有效的語法。

通過 MS Edge 和 Teams 與用戶交互的任意代碼執行視頻請點此。

有效載荷可能如下所示：

Skype 預裝在 Windows 10 上，可以通過在啟動命令中添加 --secondary 參數來并行啟動多個 Skype 實例。因此，如果發現有效載荷通過 Skype 應用程序利用此問題，它應該可以在沒有任何先決條件的情況下在默認的 Windows 10 安裝上運行。研究人員試圖為 Skype 找到一個有效載荷，但沒有成功。當發現 Skype 易受 CVE-2018-1000006 攻擊時，它似乎有可能實施了額外的安全措施。

 通過 --gpu-launcher 命令注入對 IE11/Edge Legacy 進行驅動利用

現在研究人員開始為 Microsoft 編寫錯誤報告，當他們提交報告時，研究人員注意到 MSRC 報告進程包括一個強制性的下拉選項，用于指定是否可以在最新的 Windows 版本的“Windows Insider Dev Channel”上重現報告的漏洞。

MSRC 報告進程詢問“此是否在 Windows Insider Dev Channel 上重現？”

令研究人員驚訝的是，該漏洞不僅有效，而且通過簡單地添加一些點擊惡意鏈接的 JavaScript，預裝的 Internet Explorer 11 和MS Edge （現已過時的）的“舊版”版本可能會被濫用以觸發代碼執行除了瀏覽惡意網站之外，沒有任何用戶交互。由于研究人員最初的動機是改進他們之前涉及打開任意 URI 的桌面應用程序的攻擊場景，因此并沒有過多考慮瀏覽器利用問題，只是假設所有現代瀏覽器在處理諸如ms-officecmd。事實證明，該假設是錯誤的，正如 MS Edge Legacy 所證明的那樣。通過 MS Edge 在 Windows 10 上驅動 RCE的視頻請點此。

這是上面視頻中使用的有效載荷：

有了這個視頻證據，研究人員提交了他們的報告。

參考及來源：

https://positive.security/blog/ms-officecmd-rce