時間: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:\Windows\System32\calc.exe
:
HKEY_CLASSES_ROOT
calc
(Default) = "URL:Calc Protocol"
URL Protocol = ""
DefaultIcon
(Default) = "C:\Windows\System32\calc.exe,1"
shell
open
command
(Default) = "C:\Windows\System32\calc.exe" "%1"
補充一點:實際上,在 Windows 中有兩種添加
url scheme
的方式,以上是直接添加註冊表的方式(Pluggable Protocol),還有一種是異步可插拔協議(Asynchronous Pluggable Protocol),註冊的協議會記錄在
HKEY_CLASSES_ROOT\PROTOCOLS\
下。這裏就不展開了,詳情可以參考:
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
]
運行腳本程序,可以看到系統下有不少可以調用的
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 下運行結果如下:
其造成漏洞的原因是由於微軟通過安裝適用於 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:\Windows\WinSxS\amd64_microsoft-windows-a..nagement-appvclient_
bf3856ad364e35_10.0.17134.48_none_c60426fea249fc02\SyncAppvPublishingServer.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
,同樣也可以觸發遠程代碼執行。包括:
.wshfile
.wsffile
.vbsfile
.vbefile
.jsefile
還有在
C:\Windows\System32\
下也存在
SyncAppvPublishingServer.vbs
,同樣也可以利用,並且比漏洞作者所提供的更加可靠。
除了
SyncAppvPublishingServer.vbs
這個文件, 在
C:\Windows\System32\Printing_Admin_Scripts\zh-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
安全問題。
其構造的 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 發佈,如需轉載請註明來源。本文地址: https://paper.seebug.org/719/