.png.c9b8f3e9eda461da3c0e9ca5ff8c6888.png)
ShareBear應用程序至此，我們已經確定了一個可以由Safari自動啟動的應用程序，但是我們還不知道如何正確地打開它。幸運的是，這很簡單。
研究表明，iCloud文件共享可以生成一個公共共享鏈接。
創建公共iCloud共享鏈接
這些共享鏈接看起來如下所示：https://www.icloud.com/iclouddrive/01fooriERbarZSTfikqmwQAem。
只需簡單地將“https”替換為“icloud-sharing”，就可以讓Safari自動打開ShareBear，並將該文件作為參數。
evil.html
太好了，那麼ShareBear 現在做了什麼？一些快速測試顯示了這種行為：
ShareBear行為流程圖
這種行為存在一個微妙但卻極具影響力的設計漏洞。讓我們研究一下如果用戶之前沒有打開過這個文件會發生什麼，用戶將看到一個類似於下面的提示。
ShareBear打開提示
這個無關緊要的小提示符，默認值為“Open”，看起來非常簡單。如果用戶同意，應該會打開圖片example.png。但實際上，他們達成的協議遠不止這些。
一旦用戶點擊“Open”，文件就會被下載到受害者的設備/Users/user /Library/Mobile Documents/com~apple~CloudDocs，然後通過Launch Services 自動打開。這樣用戶就再也看不到這個提示符了。此後，ShareBear以及Safari 中的任何網站將能夠自動啟動該文件。這個協議真正有漏洞的部分是，任何具有寫入訪問權限的人都可以更改文件。例如，在你同意打開文件後，文件的所有者可以更改整個字節內容和文件擴展名。然後ShareBear將下載並更新受害者設備上的文件，而無需任何用戶交互或通知。
實際上，受害者已經允許攻擊者在他們的設備上植入多個文件，並允許攻擊者在任何時候遠程啟動它。 PNG文件是一個可執行的二進製文件，只要我想，它就會自動啟動。
根據我反饋的報告，蘋果在macOS Monterey 12.0.1中修復了這一行為，但沒有發布CVE，因為這頂多是一個設計漏洞。
躲避Iframe沙盒檢測在對icloud-sharing://方案進行模糊測試時，我偶然發現了一個與UXSS 搜索無關的有趣漏洞。在執行上述行為之前，ShareBear 似乎會檢查“/iclouddrive/*”的URL 路徑。如果路徑恰好是“/photos/*”，那麼ShareBear 會犯一個非常愚蠢的錯誤。它會告訴Safari 打開一個指向iCloud Web 應用程序的新選項卡，但它不會驗證域名是否真的是iCloud Web 應用程序。
在正常操作中，用戶只看到網站“https://photos.icloud.com”。然而，由於該域名從未經過驗證，我們可以欺騙ShareBear 指示Safari 打開任何網站的新標籤頁。
這種行為的影響可能並不明顯。因為它似乎與通常調用window.open('https://example.com')沒有什麼不同。然而，有些情況下，網站是不允許這樣做的。一個示例是是否啟用了彈出窗口阻止程序。另一個更狡猾的例子是當你的網站位於沙盒iframe 中時。
當你想在你的網站上嵌入不可信的第三方內容時，通常會使用sandbox iframe屬性。例如，你可能想在你的博客上顯示一個廣告橫幅，但你不希望這個廣告能夠運行JavaScript。
沙盒iframe的一個重要規則是，從該iframe打開的新窗口應該繼承與iframe本身相同的限制。否則，逃離沙盒就像打開一個彈出窗口一樣簡單。
這個漏洞會誘使Safari 打開一個沒有任何沙盒限制的新標籤！
網站被困在沙盒iframe 中
所以ShareBear忽略了驗證域，這給了我們一個簡單的彈出框攔截程序和一個iframe沙盒逃逸。 （在未分配CVE 的情況下在Safari 15.2 中修復）在BugPoC上的演示視頻鏈接為https://bugpoc.com/poc#bp-S4HH6YcO PoC ID: bp-S4HH6YcO，密碼：loVEDsquId01。請注意，這個演示只適用於Safari 15.2之前版本的macOS Monterey 12.1。
現在返回Camera/UXSS 搜索話題。
Quarantine 和Gatekeeper我們的網站可以提示用戶打開一個共享的PNG文件。如果用戶同意，我們可以在將來的任何時候自動啟動這個文件，即使我們改變了文件的內容和擴展名。
然後，攻擊者可以在自己的設備上修改文件，而ShareBear將負責在受害者的設備上更新它。
攻擊者的設備和受害者的設備上的操作過程：
改變polymorphic文件
然後，攻擊者的網站可以使用與顯示原始提示符相同的icloud-sharing://URL自動啟動這個新更新的文件。
這似乎非常接近我們強制下載和打開一個惡意webarchive文件的目標，我們可以將puppy.png的內容替換成一個webarchival文件，並將其重命名為“evil.webarchive”，不幸的是，討厭的macOS Gatekeeper不允許這樣做。
Gatekeeper預防策略
看來ShareBear 正確地為下載的文件提供了'com.apple.quarantine' 屬性，並且根據Apple 的說法，“Gatekeeper 阻止了被隔離的可執行文件和其他類似文件（shell 腳本、webarchive等）打開或執行。”要深入了解macOS 如何處理此屬性，以及Gatekeeper 如何執行代碼簽名，請查看本文。
就滲透測試而言，此操作系統保護引入了兩大限制：
1.我們不能運行自己的應用程序；
2.我們不能直接打開webarchive文件；
側邊欄——雖然我們不能運行自己的應用程序，但啟動現有的、經過批准的應用程序是微不足道的。只需使用fileloc指向本地應用程序(這種技術很常見)。這種攻擊有時被稱為“任意文件執行”，並且經常被誤解，因為它看起來很可怕。
指向macOS 計算器的fileloc
使用icloud-sharing://方案啟動fileloc
雖然這種攻擊可能看起來很可怕，但啟動一個已經批准的應用程序不會有太大的影響。讓我們專注於打開webarchive。
快捷鍵上述打開本地應用程序的技術讓人想起老式的符號鏈接攻擊，它基本上只是使用“快捷方式”來欺騙軟件打開它不期望的東西。
多年來，許多不同的操作系統和應用程序在快捷方式方面進行了重新設計。現在，術語“快捷方式”可以指一個Unix符號鏈接、一個macOS別名、一個windows的鏈接文件、一個Safari的webloc、一個Edge的書籤等。
我希望我可以使用這個技術來繞過Gatekeeper，打開一個webarchive文件。這個想法對我來說似乎很有希望，因為我想要打開的實際應用程序是Safari(一個已存在的、已批准的應用程序)。 Gatekeeper 對我啟動Safari 沒有問題，當我嘗試打開任何以“.webarchive”結尾的文件時，它只會感到不安。
因此，我需要找到一個啟動Safari的快捷方式文件類型，然後告訴Safari打開一個不同的文件。經過反複試驗，我發現了古老的Windows URL 文件！
evil.url 文件指向本地webarchive
啟動evil.url 成功打開Safari 並指示它加載webarchive 文件而無需請求Gatekeeper 許可！ (CVE-2021-30861) 只有一個小漏洞，我需要知道webarchive 文件的完整路徑。假設webarchive 是通過ShareBear 下載的，它將存在於/Users/user /Library/Mobile Documents/com~apple~CloudDocs中，其中包括受害者的用戶名（不是一個非常可擴展的攻擊）。
幸運的是，有一個巧妙的技巧可以規避這個要求——我們可以使用DMG 文件將webarchive 文件掛載到已知的/Volumes/目錄中。
使用icloud-sharing://方案掛載dmg
現在我們確切地知道webarchive 文件所在的位置。這意味著下面的evil.url 文件每次都可以使用。
evil.url 文件指向一個已知位置的本地webarchive
使用icloud-sharing://方案啟動evil.url 以打開evil.webarchive
就像這樣，我們在任何我們想要的地方執行JavaScript 代碼。上面的屏幕錄像在https://google.com 中註入了“alert(origin)”。
讓我們將其組合成最後一次攻擊。
完整的攻擊鏈使用ShareBear為我們下載和打開一個webarchive文件，可以分為3個步驟：
1.誘騙受害者給予我們植入polymorphic文件的權限。
2.把puppies.png 變成evil.dmg 並啟動它。
3.將evil.dmg 變成evil.url 並啟動它。
當然把文件A轉換成三個不同的有效載荷需要一些服務器端協調。另一種(不那麼有趣的)實現這種攻擊的方法是讓受害者同意打開一個已經有所有文件的共享文件夾。
通過查看iCloud 共享文件夾對UXSS 進行屏幕錄製
在上面的屏幕錄製中，受害者同意查看一個包含一些PNG圖像的文件夾。這個文件夾還有兩個隱藏文件：evil。 dmg .evil.url。
該網站使用icloud-sharing://URL方案自動啟動兩個隱藏文件，成功繞過Gatekeeper，並打開一個webarchive文件。請注意，在受害者同意查看共享文件夾後，不會向他顯示額外的提示。上面的示例webarchive 文件將代碼注入https://www.icloud.com 以竊取受害者的iOS 攝像頭記錄。
當然，這只是一個例子，這種UXSS攻擊允許攻擊者將任意代碼注入到任意源。在劫持https://zoom.us 或https://facetime.apple.com 等受信任的視頻聊天網站時，注入JavaScript 代碼以打開網絡攝像頭同樣容易。
UXSS 劫持Zoom 網站以打開網絡攝像頭
漏洞修復那麼蘋果是如何解決這些漏洞的呢?
第一個修復是讓ShareBear只顯示文件而不是啟動它們(在macOS Monterey 12.0.1中修復，沒有分配CVE)。
第二個修復是阻止WebKit打開任何被隔離的文件(在Safari 15中修復為CVE-2021-30861)。
總結在我發現evil.url 技巧之前，我實際上找到了一種不同的方法來欺騙Launch Services （間接）打開一個webarchive 文件。我在Safari 的最新公開版本(v14.1.1) 中發現了這個漏洞。在向Apple 報告此漏洞幾天后，他們告訴我beta 版Safari v15 沒有這個漏洞。似乎不相關的代碼重構使v15 無法滲透。
通過啟動服務打開Safari的明顯方法是使用本地html文件。一旦打開，這個頁面將有file://URI 方案。這樣，JavaScript被允許導航到其他file://URI 。
本地HTML文件導航到另一個本地文件
那麼，如果我們要導航到的文件是一個webarchive，會發生什麼呢？此時，Safari只是掛著。
Safari拒絕出現webarchive的屏幕記錄
當目標文件是webarchiving時，這種掛起發生在我能想到的所有類型的頁面導航(anchor href, iframe src, meta redirect等)。
然後我發現了這個漏洞：
本地HTML文件導航到本地webarchive文件
當file://URL 中有主機值時，Safari 忘記執行webarchive 檢查！有趣的是，這個漏洞似乎是在Apple 修復我的舊file://漏洞(CVE-2020-3885) 時引入的。
當蘋果公司通知我Safari Beta v15不存在漏洞時，我重新檢查了一下，還是發現了evil.url。
在我完成UXSS 鏈後，還有一件事困擾著我，它不能用來竊取本地文件。當然，UXSS 可用於通過將代碼注入https://dropbox.com 或https://drive.google.com 來間接竊取文件，但無法獲取受害者硬盤上的文件。
我前面提到的出色的Blackhat Presentation啟發了我去尋找其他系統應用程序，它們可以在比Safari更優越的環境中運行我的JavaScript。在深入研究了一段時間後，我偶然發現了一個模糊的文件類型，它可以識別我的macOS腳本編輯器，名為“腳本添加”(.osax)。這些文件（或者更確切地說是“捆綁包”）包含一個嵌套的基於xml 的文件，稱為“Dictionary Document”(.sdef)。這個字典文檔用於顯示AppleScript應用程序使用的、人類可讀的、開發人員定義的術語。
重要的發現是允許這些基於xml 的文件包含HTML。事實證明，HTML呈現器也有一個JavaScript引擎，而且這個引擎不強制執行SOP！ （在macOS Big Sur 11.6.2 中修復為CVE-2021-30975）這意味著竊取/etc/passwd 很容易。
evil.sdef 顯示/etc/passwd 的內容
幸運的是，Gatekeeper 不介意我們打開腳本添加文件。所以我們只需將evil.sdef 打包到evil.osax 中，然後通過ShareBear 將其發送給受害者。然後我們的icloud-sharing://URI 可以在腳本編輯器中自動啟動它。
ShareBear 打開evil.osax 竊取/etc/passwd 的屏幕錄像
所以現在除了UXSS，這個攻擊還可以繞過沙盒限制和竊取本地文件！
最後的話這個項目是對一個應用程序中的設計缺陷如何使其他各種不相關的漏洞變得更加危險的有趣探索。這也是一個很好的例子，說明即使macOS啟用了Gatekeeper，攻擊者仍然可以通過欺騙已批准的應用程序進行惡意操作來實現許多惡意操作。