從CVE-2018-8495看PC端url scheme的安全問題
作者：0x7F@知道創宇404實驗室
時間：2018年10月18日0x00 前言
本文受 CVE-2018-8495 漏洞的啟發，以學習的目的，針對 PC 端 url scheme 的安全問題進行了分析研究。
說到 url scheme 的安全問題，這並不是一個新問題，早在 2008 年就有相關的研究和利用；如今 2018 年又陸續出現了安全問題，包括 1 月的 Electron 命令注入(CVE-2018-1000006) 以及 10 月的 Edge RCE(CVE-2018-8495)，可見 url scheme 的安全問題值得去一探究竟。
url scheme 也稱為 url protocol 或 url handler，本文使用 url scheme 這個名稱。
0x01 url scheme是什麼
常見的url scheme應用場景
在平時使用電腦的過程中，常常會發現點擊某一個鏈接就會嘗試啟動本地的應用程序，比如點擊類似 mailto://[email protected]，就會啟動郵件客戶端，點擊 thunder://xxxxx，就會啟動迅雷客戶端；這就是 url scheme 的應用。除此之外，我們使用瀏覽器也會發現地址欄中一些不同的前綴，常用的有 http://、https://、ftp:// 和 file://，這同樣是 url scheme 的應用場景。
各大操作系統開發商和瀏覽器開發商為了提高用戶體驗，豐富瀏覽器的功能，允許開發人員將 URI 與本地的應用程序進行關聯，從而在用戶使用瀏覽器時，可以通過點擊某一鏈接即可啟動應用程序；將這個功能簡稱為 url scheme。比如在 windows7 下使用 IE8 啟動默認郵件客戶端 outlook：
正因為 url scheme 這個優秀的功能設計，各大操作系統開發商都對此進行了支持，無論是 PC 端 Windows, MAC, Linux，還是移動端 iOS, Android 都有良好的支持。本文針對 PC 端下的 url scheme 的安全問題進行分析，移動端下同樣也有類似的問題，但利用方式不同，這裡就不展開了。
url scheme工作流程
在了解 url scheme 的功能後，可以大致理解到 url scheme 的工作流程；應用程序在操作系統中註冊 url scheme 項，當瀏覽器或其他支持 url 的應用訪問 特定的 url scheme 時，從系統中匹配相對應的 url scheme 項，從而啟動該應用程序；可見這是一個三方相互支持的功能。
正因如此，對於 url scheme 這個功能，在操作系統、瀏覽器(或其他支持 url 的應用)、應用程序這三個環節中，無論哪個環節出現了安全問題，或者是相互支持出現了問題，都將影響 url scheme 功能，最終給用戶帶來安全問題。
0x02 創建 url scheme
那麼 url scheme 功能是如何在操作系統中註冊的呢？不同的操作系統都有不同的實現方式，這裡以 Windows7 為例進行演示說明。
在 Windows7 上，url scheme 被記錄在註冊表 HKEY_CLASSES_ROOT 下，如 mailto 的相關欄位：
如果要創建一個新的 url scheme，直接在 HKEY_CLASSES_ROOT 添加即可，並在相應的欄位中填入對應的值。創建的子項名即為 url scheme 功能名，在該子項下還包含兩個項：DefaultIcon 和 shell，DefaultIcon 包含該功能所使用的默認圖標路徑；在 shell 項下繼續創建子項，例如: open，然後在 open 項下創建 command 子項，用於描述應用程序的路徑以及參數。
舉個例子，創建 calc 用於啟動 C:WindowsSystem32calc.exe：
HKEY_CLASSES_ROOT calc (Default) = "URL:Calc Protocol" URL Protocol = "" DefaultIcon (Default) = "C:WindowsSystem32calc.exe,1" shell open command (Default) = "C:WindowsSystem32calc.exe" "%1"
補充一點：實際上，在 Windows 中有兩種添加 url scheme 的方式，以上是直接添加註冊表的方式(Pluggable Protocol)，還有一種是非同步可插拔協議(Asynchronous Pluggable Protocol)，註冊的協議會記錄在 HKEY_CLASSES_ROOTPROTOCOLS 下。這裡就不展開了，詳情可以參考：https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/aa767916(v%3dvs.85)
0x03 安全隱患
對於 url scheme 功能，簡單來講就是「通過 url 可以啟動某一個本地的應用程序」，這無疑大大提高了用戶體驗，但同時引入一些安全隱患，比如用戶可以通過瀏覽器啟動一個惡意程序，或者用戶啟動的應用程序具有特殊的功能可以被調用(如：刪除文件、啟動網路連接)。
除此之外，對於包含 url 的的相關應用，用戶是往往作為一個使用者、閱讀者，而不是編輯者；也就是說 url 可以被攻擊者惡意構造，從而達到遠程啟動本地應用程序的效果。
那麼在操作系統中，有哪些 url scheme 是可以被調用的呢？這裡提供三個腳本用於導出三大 PC 系統下 url scheme：
Windows: [https://images.seebug.org/archive/duh4win.vbs]
MAC: [https://images.seebug.org/archive/duh4mac.m]Linux: [https://images.seebug.org/archive/duh4linux.sh]
(腳本來源於：https://www.blackhat.com/presentations/bh-europe-08/McFeters-Rios-Carter/Whitepaper/bh-eu-08-mcfeters-rios-carter-WP.pdf)
運行腳本程序，可以看到系統下有不少可以調用的 url scheme，其中包括操作系統默認支持的，如 http、ftp、mailto，也有第三方的應用程序，如 qq、thunder；如果這些應用程序出現安全問題，比如支持刪除文件、啟動另一個程序等敏感操作，最終在 url scheme 的幫助下，都將遠程觸發的安全問題。
除了應用程序可能出現的安全問題，瀏覽器(或其他程序)在進行 url 解析並啟動應用程序的過程也可以出現安全問題；並且這三方相互支持的過程中，仍然可能出現問題；無論是哪一個環節出現的安全問題，其危害最終都會在 url scheme 下被放大。
本文就這以上可能出現安全問題的環節進行分析，並舉例說明。
0x04 操作系統的問題
在 2007 年，Heise Security 公開了由 「url scheme 導致遠程命令執行」的漏洞，其出現在 Windows XP 下已安裝 IE7 版本的系統中，影響範圍包括所有支持 url scheme 的應用程序。
其構造的 PoC 如下：
mailto:test%../../../../windows/system32/calc.exe".cmd
在 Windows XP 下運行結果如下：
圖片來源於：http://www.h-online.com/security/news/item/URI-problem-also-affects-Acrobat-Reader-and-Netscape-733744.html
其造成漏洞的原因是由於微軟通過安裝適用於 Windows XP 的 IE7 改變了操作系統對 url 的處理，而應用程序直接將路徑傳遞給操作系統用於啟動，最終導致包含 ％ 字元的特殊鏈接導致啟動任意程序。
在漏洞公開後，微軟並沒有發布修復補丁，並且認為這不是 Windows XP 的原因，隨後各大應用程序開發人員對該漏洞進行了修復。當然，上層應用可以對輸入的參數進行檢查，但這裡也可以認為是操作系統方面的問題，導致了 url scheme 遠程命令執行。
0x05 瀏覽器的參數注入
2018 年，在 url scheme 的安全問題中，有兩個問題是由於 Windows 下的 IE 和 Edge 參數注入引發的，其中一個是 Electron 自定義協議命令注入(CVE-2018-1000006)，另一個是 Edge 遠程代碼執行(CVE-2018-8495)。
在 Windows 下 IE 和 Edge 對 url scheme 的處理方式有些不同，在瀏覽器接收到一個 url scheme後，訪問註冊表查詢對應的應用程序路徑，隨後進行 url 解碼，然後調用 ShellExecute 函數簇，啟動應用程序；正是因為 url 解碼這一步造成了雙引號閉合，從而引起了參數注入問題。示意圖如下：
Electron 自定義協議命令注入
2018 年 1 月，Electron 發布了由自定義協議而導致命令注入的安全公告(CVE-2018-1000006)，由於參數注入而引發的問題，構造的 PoC 如下：
chybeta://?" "--no-sandbox" "--gpu-launcher=cmd.exe /c start calc
使用 IE 瀏覽器訪問該鏈接，最終生成的啟動參數如下：
electron.exe "//?" "--no-sandbox" "--gpu-launcher=cmd.exe /c start calc"
通過參數注入，調用 electron 中支持的 --gpu-launcher 參數，傳入 cmd.exe 啟動計算器，如下圖：
圖片來源於：https://xz.aliyun.com/t/1990，詳情可以參考這個鏈接。
Edge 遠程代碼執行
2018 年 10 月，Edge 公開了遠程代碼執行的安全公告(CVE-2018-8495)，同樣也是利用參數注入，最終達到了遠程代碼執行的效果；整個利用過程頗具巧妙性，本文對此進行詳細的分析。
首先說一點的是，在 Edge 中居然可以打開一些不合法的 url scheme(沒有包含 URL Protocol 欄位)，比如 WSHFile 項：
當然在 Windows7 和 Windows8 下不能打開。
而恰恰 WSHFile 項指向了 wscript.exe，這個應用程序非常熟悉是Windows 內置的腳本解釋器，那麼可以利用 WSHFile 嘗試去運行一個腳本；除此之外，上文提到 Edge 瀏覽器中存在參數注入的問題，那麼是否有腳本可以接收參數並用於執行呢？
漏洞作者最終找到：
C:WindowsWinSxSamd64_microsoft-windows-a..nagement-appvclient_ 31bf3856ad364e35_10.0.17134.48_none_c60426fea249fc02SyncAppvPublishingServer.vbs
該腳本文件支持接收參數，並且會將命令直接拼接到字元串中，然後通過 powershell 進行執行。
psCmd = "powershell.exe -NonInteractive -WindowStyle Hidden-ExecutionPolicy RemoteSigned -Command &{" & syncCmd & "}"
最終構造的 PoC 如下：
<a id="q" href=wshfile:test/../../WinSxS/AMD921~1.48_/SyncAppvPublishingServer.vbs" test test;calc;">test</a> <script> window.onkeydown=e=>{ window.onkeydown=z={}; q.click() } </script>
以及執行後觸發的效果：
目前 Windows10 上已經發布了修復補丁，Edge 已經不能調用這種不合法的 url scheme 了。
除此之外，404實驗室的小夥伴在分析漏洞的過程中，也有一些額外的發現，如在註冊表 HKEY_CLASSES_ROOT 還發現了和 WSHFile 類似的 url scheme，都指向 wscript.exe，同樣也可以觸發遠程代碼執行。包括：
1.wshfile 2.wsffile 3.vbsfile 4.vbefile 5.jsefile
還有在 C:WindowsSystem32 下也存在 SyncAppvPublishingServer.vbs，同樣也可以利用，並且比漏洞作者所提供的更加可靠。
除了 SyncAppvPublishingServer.vbs 這個文件， 在 C:WindowsSystem32Printing_Admin_Scriptszh-CN 下的 pubprn.vbs 也同樣可以觸發代碼執行。
補充一點，在 Windows7 系統下 chrome 與 Edge 有相同的特性——會打開一些不合法的 url scheme，但由於 chrome 不存在參數注入的問題，所以可以暫且認為是安全的。
0x06 應用程序的問題
2017 年 12 月，macOS 上的 helpViewer 應用程序被公開由 XSS 造成文件執行的漏洞(CVE-2017-2361)，影響 macOS Sierra 10.12.1 以下的版本；該漏洞同樣也利用了 url scheme，攻擊者可以構造惡意頁面，從而發動遠程攻擊。這是典型的由於應用程序所導致的 url scheme 安全問題。
漏洞詳情可以參考：https://bugs.chromium.org/p/project-zero/issues/detail?id=1040&can=1&q=reporter%3Alokihardt%40google.com%20&sort=-reported&colspec=ID%20Status%20Restrict%20Reported%20Vendor%20Product%20Finder%20Summary&start=100
其構造的 PoC 如下：
document.location = "help:///Applications/Safari.app/Contents/ Resources/Safari.help/%25252f..%25252f..%25252f..%25252f..%25252f..%25252f.. %25252f/System/Library/PrivateFrameworks/Tourist.framework/Versions/A/ Resources/en.lproj/offline.html?redirect=javascript%253adocument.write(1)";
在這個漏洞的利用過程中，可以發現操作系統和瀏覽器並沒有出現問題，而是通過 url scheme 打開的應用程序出現了問題。通過對利用鏈的分析，可以了解到其中幾個巧妙的點：
- 利用
url scheme中的 help 協議打開應用程序 Safari.help - 使用雙重 url 編碼繞過 helpViewer 對路徑的檢查，打開一個可以執行 JavaScript 的頁面
- 使用 helpViewer 的內置協議
x-help-script打開應用程序(PoC不包含)
0x07 總結
url scheme 功能的便捷性得力於操作系統、瀏覽器(或其他支持 url 的應用)以及應用程序三方的相互支持；要保證 url scheme 功能安全可靠，就必須牢牢把關這三方的安全。
除此之外，不同的操作系統對 url scheme 實現方式不同，不同的瀏覽器也有自己的特性，應用程序也各有各的處理方式，多種組合的結果，就有可能出現一些意料之外的安全問題。
最後感謝 404 實驗室小夥伴 @LoRexxar 與 @dawu 在分析過程中給我的幫助。
References:
- CVE-2018-8495分析: https://leucosite.com/Microsoft-Edge-RCE/
- Seebug.paper: https://paper.seebug.org/515/
- 先知: https://xz.aliyun.com/t/1990
- electronjs: https://electronjs.org/blog/protocol-handler-fix
- blackhat: https://www.blackhat.com/presentations/bh-europe-08/McFeters-Rios-Carter/Whitepaper/bh-eu-08-mcfeters-rios-carter-WP.pdf
- blackhat: https://www.blackhat.com/presentations/bh-dc-08/McFeters-Rios-Carter/Presentation/bh-dc-08-mcfeters-rios-carter.pdf
- oreilly: https://www.oreilly.com/library/view/hacking-the-next/9780596806309/ch04.html
- Github: https://github.com/ChiChou/LookForSchemes
- MSRC.CVE-2018-8495: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-8495
- Microsoft: https://docs.microsoft.com/en-us/windows/uwp/launch-resume/reserved-uri-scheme-names
- Microsoft: https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/aa767914(v=vs.85)
- Microsoft: https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/platform-apis/aa767916(v%3dvs.85)
- h-online: http://www.h-online.com/security/news/item/URI-problem-also-affects-Acrobat-Reader-and-Netscape-733744.html
- chromium: https://bugs.chromium.org/p/project-zero/issues/detail?id=1040&can=1&q=reporter%3Alokihardt%40google.com%20&sort=-reported&colspec=ID%20Status%20Restrict%20Reported%20Vendor%20Product%20Finder%20Summary&start=100
本文由 Seebug Paper 發布，如需轉載請註明來源。
歡迎關注我和專欄，我將定期搬運技術文章～
也歡迎訪問我們：知道創宇雲安全
推薦閱讀：
