.png.c9b8f3e9eda461da3c0e9ca5ff8c6888.png)
本文我們將介紹通過Safari UXSS 獲得未經授權的攝像頭訪問權限，以及如何進一步利用一個共享iCloud 文檔攻擊你訪問過的每個網站。
本次是利用發現的Safari中的7個0 day漏洞（CVE-2020-3852，CVE-2020-3864，CVE-2020-3865，CVE-2020-3885，CVE-2020-3887，CVE-2020-9784和CVE- 2020-9787），其中三個用於構造利用鏈劫持訪問攝像頭。
簡而言之，該漏洞使蘋果認為惡意網站實際上是值得信賴的網站，它通過利用Safari如何解析URI，管理WebOrigin以及初始化Secure_Contexts的一系列漏洞來實現劫持。如果惡意網站將這些漏洞利用串在一起，則可以使用JavaScript 直接訪問受害者的網絡攝像頭，而無需徵求許可。任何具有創建彈窗功能的JavaScript代碼都可以發起此攻擊。
而在本次嘗試中。我成功地利用了iCloud Sharing和Safari 15的一系列漏洞，來獲得了未經授權的攝像頭訪問權限。雖然這個漏洞確實需要受害者點擊“打開”從我的網站彈出的窗口，但它導致的不僅僅是多媒體權限劫持。這一次，該漏洞使攻擊者可以完全訪問受害者曾經訪問過的每個網站。這意味著除了打開你的攝像頭之外，我的漏洞還可以破解你的iCloud、PayPal、Facebook、Gmail 等帳戶。
本次共使用了4個發現的0 day漏洞(CVE-2021-30861、 CVE-2021-30975， 另外2個並沒有CVE)，其中2 個被用於黑入攝像頭。我已向蘋果報告了這個漏洞鏈條，並獲得了100500美元的賞金。
背景介紹蘋果通過增加攝像頭訪問的難度，修復了我上一次報告的漏洞鏈(CVE-2020-3852 + CVE-2020-3864 + CVE-2020-3865)。在這次賞金計劃中，該漏洞鏈會讓蘋果認為惡意網站實際上是值得信賴的網站，它通過利用Safari如何解析URI，管理WebOrigin以及初始化Secure_Contexts的一系列漏洞來做到這一點。如果惡意網站將這些漏洞利用串在一起，則可以使用JavaScript 直接訪問受害者的網絡攝像頭，而無需徵求許可。任何具有創建彈窗功能的JavaScript代碼都可以發起此攻擊。 iOS和macOS中的攝像頭安全模型非常嚴格，簡而言之，必須為每個應用程序明確授予攝像頭/麥克風許可，這由操作系統通過標準警報框處理。但是這個規則有一個例外。蘋果自己的應用程序可免費使用攝像頭，因此，Mobile Safari從技術上無需詢問即可訪問攝像頭。此外，諸如MediaDevicesWeb API（通常用於WebRTC傳輸）之類的新網絡技術使網站可以利用Safari的許可直接訪問攝像頭。但當時蘋果認為此漏洞屬於“無用戶交互的網絡攻擊：對敏感Data的零點擊未授權訪問” 類別， 並獎勵了我75000美元。
現在多媒體訪問只允許協議為“https:”，並且域匹配你保存的設置。這意味著巧妙地格式漏洞的URI 將不再適用，之前我專門講了file:我使用的下一個方案是file:該方案不包含有意義的主機名，我深入探究RFC，實際上偶然發現了file: URI的一個變化中確實包含主機名的URI。這種URI實際上指定了一個遠程服務器，類似於FTP，但是此規範未定義對存儲在遠程計算機上的文件的檢索機制，搜索了一段時間後，我找不到任何實際上支持這種的URI類型的用戶代理。
file：//host.example.com/Share/path/to/file.txt出於好奇，我檢查了Safari如何在內部解析普通文件URI。
果然主機名為空，接著我使用JavaScript指定主機，看看會發生什麼。
該頁面竟將該URI視為有效，並重新加載了相同的內容。這意味著我只是使用了一個技巧就更改了document.domain（CVE-2020-3885）。
果然，Safari認為在skype.com上，可以加載一些惡意的JavaScript。當你打開本地HTML文件時，攝像頭，麥克風和屏幕共享都會受到損害。 Safari似乎也使用這種惰性主機名解析方法來填充密碼的自動完成功能，因此，如果你接受自動完成功能，就可以竊取純文本密碼。
此攻擊需要受害者打開本地HTML文件。另外，它在iOS上不起作用，因為通過Mobile Safari下載的本地文件在沒有JavaScript引擎的情況下以預覽樣式的嵌入式視圖顯示。
現在我們需要真正將我們的惡意代碼注入目標源，換句話說，我們需要找到一個通用跨站腳本(UXSS) 漏洞。
那麼UXSS與通常的XSS區別是什麼？因為同源策略，即使一個漏洞頁面存在XSS，我們可以訪問用戶會話信息卻無法訪問其他域的相關的會話信息，而因為UXSS是利用瀏覽器本身或者瀏覽器擴展程序的漏洞，所以對於攻擊發起時瀏覽器打開或緩存的所有頁面（即使不同域的情況）的會話信息都可以進行訪問。簡單的說，UXSS不需要一個漏洞頁面來觸發攻擊，它可以滲透入安全沒有問題的頁面，從而創造一個漏洞，而該頁面原先是安全無漏洞的。
因為UXSS攻擊不需要頁面本身存在漏洞，同時可能訪問其他安全無漏洞頁面，使得UXSS成為XSS裡危險和最具破壞性的攻擊類型之一。
同樣，我們可以建立一個網站，它可以跳轉到https://zoom.com打開攝像頭，跳轉到https://paypal.com轉賬，並劫持https://gmail.com來竊取電子郵件。
在繼續之前，我應該澄清一個事情。本文講的這個漏洞與我的上一篇講的Safari攝像頭被攻擊到底有什麼不同？該漏洞會專門針對存儲的多媒體權限。它沒有給我在任意原點上執行代碼的能力。查看我的攻擊圖，看看哪些來源被使用。換句話說，本文的攻擊鏈只會讓我利用Skype的攝像許可，但不會讓我竊取Skype的cookie。
首先讓我們嘗試在Safari最新版本(撰寫本文時為Safari v15 beta版)中找到一個UXSS漏洞。和往常一樣，第一步首先是要做大量的研究。
攻擊計劃在閱讀了大量關於Safari UXSS漏洞補丁的文章後，我決定將研究重點放在webarchive 文件上。 webarchive 文件是Mac 系統Safari 瀏覽器的存檔文件，是保存網頁內容的特殊文件格式Mac OS X 系統帶有文件轉換功能，可以把webarchive 文件變成html 文件。當用戶在本地保存網站時，這些文件是由Safari創建的，作為HTML的替代品。
Safari瀏覽器將網站保存為webarchival文件
這些文件的一個令人吃驚的特點是，它們指定了內容應該呈現的網絡來源。
Webarchive文件格式
這是一個很棒的技巧，可以讓Safari重建保存的網站的上下文，但正如Metasploit開發者在2013年指出的那樣，如果攻擊者能夠以某種方式修改這個文件，他們就可以有效地實現設計好的UXSS。
根據Metasploit 的說法，蘋果並不認為這種攻擊場景真的可以實現，因為“webarchive必須由客戶端下載並手動打開。”當然，這個決定是在近十年前做出的，當時瀏覽器安全模型還沒有今天那麼成熟。
蘋果決定支持這種超級強大的文件類型，這樣攻擊就會嘗試在受害者的設備上強行打開它們。攻擊可以分為兩個步驟：
1.強行下載一個惡意的webarchive 文件；
2.強行打開它；
直到最近，還沒有任何保護措施來阻止第一步。在Safari 13之前，網站在下載任意文件之前甚至不會向用戶顯示任何警告。所以植入webarchive文件很容易。自從出現了Safari 13以上的版本，每次下載前都會提示用戶。
而強行打開wearchive文件則更加困難，但仍然可以通過以某種方式導航到file://URI 方案來管理。當Safari的存在漏洞頁面出現在file://scheme中時，就會發現如何故意調用漏洞頁面來改變它的路徑名，這種攻擊方法被戲稱為“Errorjacking”，先後出現過兩種變體（1，2）。另一種在當時有效的方法是簡單地將標記設置為file://。
但到了2022年，該技巧就不靈了。不僅默認情況下會阻止自動下載，而且webarchive文件被macOS Gatekeeper認為是惡意應用程序。這意味著用戶甚至不能自己手動打開國外的webarchive。目前，蘋果似乎已經改變了他們在2013年對這些文件有多危險的看法。
Safari 13以上版本中的下載提示
Gatekeeper預防策略
儘管如此，webarchive文件看起來還是太有趣了，讓人無法放棄。讓我們來探索一下，這種老式的攻擊攻擊方式是如何在最新的Safari 和macOS 版本上發生的。
探索自定義URI 方案通過深入研究IANA 註冊的官方URI 方案，我在上一個Safari 攝像頭攻擊項目中取得了成功。該項目在很大程度上受到RFC 和公共文檔的指導。但是我忽略了整個自定義URL 方案的世界。這些非官方和大部分未記錄的方案通常被第三方iOS/macOS 應用程序用作深度鏈接的一種形式。
有趣的是，Apple Help Viewer (help://)、FaceTime (facetime-audio://) 和Apple Feedback (applefeedback://) 等多個系統應用程序也支持自定義URI 方案。在Safari 的網站上濫用這些方案並不是一種新技術。事實上，一段時間以來，攻擊一直在尋找使用自定義方案來啟動並利用其中的漏洞系統應用程序的方法。攻擊範圍包括煩人的撥打電話、協助社會工程到任意文件執行。
為了幫助對抗這些攻擊，Safari 的現代版本會在盲目啟動輔助應用程序之前警告用戶。也就是說，除非它們是Blackhat 演示中確定的硬編碼異常之一。
Safari 將在沒有提示的情況下啟動的自定義URI 方案
所有這些方案都在Launch Services 中註冊，因此你可以通過以下命令列出它們：
/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister-dump|grep-B6bindings:*:|grep-B6apple-internal在仔細研究了蘋果的內部方案後，並將它們與Safari信任的方案進行交叉比對後，我發現了一個吸引我眼球的方案——“icloud-sharing：”。這個方案似乎是由一個名為“ShareBear”的iCloud共享應用程序註冊的。
關於icloud-sharing的LaunchServices數據
我對ShareBear很感興趣，因為分享iCloud文件似乎是下載和發布webarchive文件的可行途徑。我找不到任何關於這個計劃的公開文檔或研究，所以我就自己開始研究它。