從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 發布,如需轉載請註明來源。
歡迎關注我和專欄,我將定期搬運技術文章~
也歡迎訪問我們:知道創宇雲安全
推薦閱讀: