建站
咨詢
售后
建站咨詢
新聞中心
我們會在本文詳細介紹如何使用不同的方法利用CVE-2022-22583的技術(shù)細節(jié)。我們還在本報告中討論了CVE-2022-32800的技術(shù)細節(jié)。
創(chuàng)新互聯(lián)建站憑借專業(yè)的設(shè)計團隊扎實的技術(shù)支持、優(yōu)質(zhì)高效的服務(wù)意識和豐厚的資源優(yōu)勢，提供專業(yè)的網(wǎng)站策劃、成都網(wǎng)站設(shè)計、成都網(wǎng)站建設(shè)、網(wǎng)站優(yōu)化、軟件開發(fā)、網(wǎng)站改版等服務(wù)，在成都10年的網(wǎng)站建設(shè)設(shè)計經(jīng)驗，為成都成百上千中小型企業(yè)策劃設(shè)計了網(wǎng)站。
2022年1月26日，蘋果公司修復(fù)了PackageKit框架中的系統(tǒng)完整性保護(SIP)繞過漏洞，該漏洞被識別為CVE-2022-22583。
Perception Point發(fā)布了一篇關(guān)于該漏洞及其利用細節(jié)的文章后，我們確定我們利用該漏洞的方法與他們的不同。在深入挖掘CVE-2022-22583之后，我們還發(fā)現(xiàn)了一個新的漏洞CVE-2022-32800。
這篇文章討論了我們?nèi)绾问褂貌煌姆椒ɡ肅VE-2022-22583的技術(shù)細節(jié)。關(guān)于SIP和特殊守護進程服務(wù)的權(quán)利的更多詳細信息可以在我們上個月的文章中找到。我們還會討論在2022年社區(qū)力量安全會議（POC2022）期間向蘋果披露的15個以上關(guān)鍵SIP繞過漏洞中的幾個。
CVE-2022-22583
CVE-2022-22583的安全漏洞
我們通過進程監(jiān)控發(fā)現(xiàn)了這個漏洞。當我們將apple簽名的軟件安裝包(PKG)文件安裝到root volume時，我們注意到以下腳本是由特權(quán)“system_install”服務(wù)生成的：
因為“system_installd”服務(wù)具有特殊的“com.apple.rootless.install.heritable”權(quán)限，所以這兩個腳本將在SIP繞過上下文中執(zhí)行。
在看到這兩個腳本位于“/tmp/PKInstallSandbox.l57ygT”目錄后，我想到了以下問題：
我們可以修改臨時位置內(nèi)的腳本嗎？
誰創(chuàng)建了帶有隨機后綴的臨時文件夾“PKInstallSandbox”？
新創(chuàng)建的文件夾是否受SIP保護？
在這些問題的啟發(fā)下，我們開始了調(diào)查。
通過反轉(zhuǎn)和調(diào)試，我們發(fā)現(xiàn)臨時文件夾是由" -[PKInstallSandbox prepareForCommitReturningError:] "函數(shù)創(chuàng)建的：
“prepareForCommitXXX”函數(shù)的實現(xiàn)
在第16行，它調(diào)用另一個函數(shù)“-[PKInstallSandbox _createDirectory:uniquifying:error:]”，該函數(shù)在內(nèi)部調(diào)用API“mkdtemp”來不受任何限制地創(chuàng)建文件夾。
“_createDirectory:uniquifying:”函數(shù)的實現(xiàn)
在看到“PKInstallSandbox.XXXXXXX”文件夾未受保護后，我們最初認為它可以被利用和操縱。然而，我們未能直接修改文件夾中的腳本。這是因為子文件夾“Scripts”受到限制，它從受限制的沙盒路徑中移動，如上第25行所示。
至少有兩種不同的方法來克服這個特殊的挑戰(zhàn)并利用這個安全漏洞。
漏洞1：使用掛載技巧
第一個漏洞使用掛載技巧。Perception Point在其文章中對此進行了詳細討論。根據(jù)調(diào)查，掛載技巧可以通過以下步驟完成：
創(chuàng)建虛擬映像文件并將其裝載到“/private/tmp”上；
使用安裝后腳本安裝Apple簽名的軟件包；
等待安裝程序完成腳本目錄的提取，并收集提取路徑的隨機部分；
卸載映像文件，這將恢復(fù)到提取前的“/private/tmp”內(nèi)容；
創(chuàng)建腳本目錄（使用我們之前獲得的隨機路徑），并將我們想要的任何腳本放入其中。
Perception Point的文章還指出，這里討論的漏洞取決于時間，可能不會一直成功。
漏洞2：使用符號鏈接
我們的漏洞使用了另一種方法：符號鏈接。此漏洞可通過以下步驟實現(xiàn)：
監(jiān)視“/tmp/PKInstallSandbox.XXXXXXX”目錄的創(chuàng)建，并將其替換為指向另一個“/tmp/fakebox”位置的符號鏈接，以將受限制的腳本重定向到那里；
一旦腳本位于“/tmp/fakebox”中，請刪除符號鏈接并重新創(chuàng)建相同的“/tmp/PKInstallSandbox.XXXXXXX”目錄，然后將有效負載腳本放在“/tmp/pKInstallSandox.XXXXXXX/scripts/pkgid.XXXXXX/”目錄中；
等待有效負載腳本執(zhí)行；
此漏洞的完整概念證明已上傳到了GitHub上。我們的概念驗證演示也可以在下圖中看到。
使用symlink的漏洞演示
即使我們是root用戶，也無法在受限目錄“/Library/Apple”中創(chuàng)建文件，因為SIP狀態(tài)已啟用。但是在利用程序的幫助下，我們可以在SIP繞過上下文中執(zhí)行任意命令，并在受限目錄中成功創(chuàng)建文件。
蘋果CVE-2022-22583的補丁
“installd”服務(wù)和“system_installd”服務(wù)的操作方式有點混亂。在下圖中，我們可以看到第17行和第18行的補丁代碼區(qū)分了這兩種服務(wù)：
CVE-2022-22583的補丁
對于蘋果簽署的軟件包，該補丁使用“OpenPath”及其自己的受限沙盒路徑。對于其他包，它仍然使用“/tmp”目錄中的隨機路徑。
安裝沙盒
在介紹CVE-2022-32800之前，我們需要了解一些與“安裝沙盒”相關(guān)的概念。
Sandbox Repository
首先，讓我們看一下“Sandbox Repository”，這是一個由“-[PKInstallSandboxManager _sandboxRepositoryForDestination:forSystemSoftware:create:error:]”函數(shù)返回和創(chuàng)建的目錄。
“_sandboxRepositoryForDestination:XXX”函數(shù)的實現(xiàn)
總之，有四種Sandbox Repository：
安裝目標為root volume“/”:
a.對于Apple簽名的pkg: /Library/Apple/System/Library/InstallerSandboxes/.PKInstallSandboxManager-SystemSoftware；
b.其他pkg: /Library/InstallerSandboxes/.PKInstallSandboxManager；
安裝目標不是root volume:
a.對于apple簽名的pkg: $targetVolume/.PKInstallSandboxManager-SystemSoftware；
b.其他pkg: $targetVolume/.PKInstallSandboxManager；
需要注意的是，只有當apple簽名包安裝到root volume時，Sandbox Repository才會受到限制。
沙盒路徑
“沙盒路徑”用于在安裝期間存儲腳本和有效載荷等文件。
它是“Sandbox Repository”中的一個目錄，由“[PKInstallSandboxManager addSandboxPathForDestination:forSystemSoftware:]_block_invoke”方法創(chuàng)建：
實現(xiàn)“addSandboxPathForDestination:XXX”函數(shù)
沙盒路徑有四種，每種路徑都有一個通用唯一標識符(UUID)名稱，表示它們特定的沙盒狀態(tài)：
UUID.sandbox：創(chuàng)建的第一個狀態(tài)；
UUID.activeSandbox：激活狀態(tài)，正在使用中；
UUID.trashedSandbox：停用狀態(tài)，被丟棄；
UUID.orphanedSandbox：孤立狀態(tài)，如果磁盤空間不足，將進行清理；
PKInstallSandbox
" PKInstallSandbox "是一個用于抽象和封裝的Objective-C類名：
通過“-[PKInstallSandbox initWithSandboxPath:installRequest:error:]”方法初始化“PKInstallSandbox”的新實例，這取決于沙盒路徑和安裝請求。
請注意，該實例是可序列化的，并且該類實現(xiàn)了“NSSecureCoding”協(xié)議?！皊ystem_installd”服務(wù)可以通過“-[PKInstallSandboxManager saveSandboxAsStaged:]”方法將實例保存或序列化到沙盒路徑中名為“SandboxState”的文件中：
“saveSandboxAsStaged”函數(shù)的實現(xiàn)
“PKInstallSandbox”實例也可以稍后通過“-[PKInstallSandboxManager_sandboxAtPath:matchingRequest:forUse:]”方法從“SandboxState”文件還原或反序列化：
“sandboxAtPath:matchingRequest:XXX”函數(shù)的實現(xiàn)
注意，在第57行有一個檢查，它要求恢復(fù)的安裝請求與從安裝客戶端傳遞的安裝請求深度相等。這項檢查給我們的開發(fā)程序帶來了一個小小的挑戰(zhàn)。
在安裝之前，“system_installd”服務(wù)需要根據(jù)“-[PKInstallSandboxManagersandboxForRequest:created:error:]”函數(shù)中的安裝請求獲取“PKInstallSandbox”的實例。
該函數(shù)的核心邏輯如下：
首先，它將從“sandbox Repository”中枚舉所有帶有“.ssandbox”后綴的文件夾，然后從內(nèi)部的“SandboxState”文件中恢復(fù)“PKInstallSandbox”實例。
枚舉帶有“.ssandbox”后綴的所有文件夾
接下來，如果它找不到與安裝請求匹配的“PKInstallSandbox”實例，那么它將枚舉帶有“.activeSandbox”后綴的所有文件夾，并嘗試從這些位置還原它們。
枚舉帶有“.activeSandbox”后綴的所有文件夾
最后，如果它仍然不能匹配這樣的沙盒，它將創(chuàng)建一個新的“沙盒路徑”，并構(gòu)造一個新的“PKInstallSandbox”實例。
創(chuàng)建一個新的“沙盒路徑”和實例
CVE-2022-32800
漏洞詳細信息
CVE-2022-32800漏洞允許攻擊者劫持“SandboxState”文件以獲取SIP繞過原語。
“SandboxState”文件存儲在“Sandbox路徑”中，該路徑位于“Sandbox Repository”中。在正常情況下，“Sandbox存儲庫”僅限于Apple簽名的軟件包。
但是，如果安裝目標是DMG（磁盤映像）卷，則根本不限制“Sandbox Repository”。“SandboxState”文件也是如此。因此，我們可以制作一個特制的“SandboxState”文件，在反序列化過程中劫持新的“PKInstallSandbox”實例。然后可以控制“PKInstallSandbox”實例的所有成員變量。
漏洞利用
有不同的方法可以利用這個漏洞。例如，在下圖中，我們劫持了成員“_cleanupPaths”，以獲取一個原語來刪除任意的SIP保護路徑。
安裝完成后，無論是否成功，它都將調(diào)用“-[PKInstallSandboxManager_removeSandbox:]”函數(shù)刪除沙盒，并刪除“_cleanupPaths”成員指定的所有文件和文件夾。
“_removeSandbox”函數(shù)的實現(xiàn)
該漏洞的完整概念證明可以在GitHub找到，演示視頻可以在此查看。
蘋果CVE-2022-32800的補丁
蘋果在macOS 12.5中修復(fù)了這一安全漏洞。
補丁位于“-[PKInstallSandboxManager _sandboxAtPath:matchingRequest:forUse:]”函數(shù)中:
CVE-2022-32800補丁
正如我們在第38行檢查中看到的，它在內(nèi)部調(diào)用“PKSIPFullyProtectedPath”函數(shù):
“PKSIPFullyProtectedPath”函數(shù)的實現(xiàn)
對于Apple簽名的軟件包，“SandboxState”文件需要受信任或限制。
安全建議
為了成功地保護系統(tǒng)免受漏洞攻擊，用戶必須定期更新其操作系統(tǒng)。定期應(yīng)用安全補丁將阻止攻擊者利用漏洞提升權(quán)限并發(fā)起惡意攻擊。關(guān)于此處討論的漏洞，CVE-2022-22583于2022年1月修補，CVE-2022 2-32800于2022年7月修補。
最終用戶可以受益于安全解決方案，如趨勢科技Mac版防病毒軟件和趨勢科技防護套件，它們有助于檢測和阻止利用此類漏洞的攻擊。
本文翻譯自：https://www.trendmicro.com/en_us/research/22/l/a-technical-analysis-of-cve-2022-22583-and-cve-2022-32800.html
文章題目：CVE-2022-22583和CVE-2022-32800技術(shù)分析，你明白了嗎？
新聞來源：http://m.5511xx.com/article/dhieoed.html
