我們將在本文介紹最近攻擊者是如何避開攝像頭和麥克風(fēng)綠色/橙色指示器，來悄悄監(jiān)視用戶的。

從iOS14開始，蘋果多了幾個新指示器：一個綠點和一個橙點。當(dāng)訪問攝像頭或麥克風(fēng)時，這些指示燈會發(fā)出信號。

當(dāng)沒有綠色/橙色圓點時，就意味著手機(jī)沒有被監(jiān)聽。

我們知道像NSO/Pegasus這樣的惡意軟件能夠監(jiān)聽麥克風(fēng)。NSO組織和數(shù)百名其他針對移動設(shè)備的攻擊者能否在視覺指示器關(guān)閉時拍攝我們的視頻？

讓我們來看看此功能是否對攻擊者構(gòu)成任何挑戰(zhàn)。

邏輯問題

讓我們先想想，每次訪問攝像頭或麥克風(fēng)時，指示燈是否真的亮起？我們很快就會想到Siri。如果麥克風(fēng)指示燈沒有一直亮起，手機(jī)如何知道我們何時說“Hey Siri”？手機(jī)一定在聽某種正確的聲音。

“Hey Siri”

/System/Library/PrivateFrameworks/CoreSpeech.framework/corespeechd依賴于VoiceTrigger.framework來持續(xù)監(jiān)控用戶的聲音，然后在聽到關(guān)鍵字時激活Siri。

輔助功能->語音控制

語音控制允許你使用語音命令與設(shè)備進(jìn)行交互。

/System/Library/PrivateFrameworks/SpeechRecognitionCore.framework/XPCServices/com.apple.SpeechRecognitionCore.brokerd.xpc/XPCServices/com.apple.SpeechRecognitionCore.speechrecognitiond.xpc/com.apple.SpeechRecognitionCore.speechrecognitiond

負(fù)責(zé)訪問麥克風(fēng)。

SwitchControl的部分功能是檢測用戶頭部的運(yùn)動來與設(shè)備進(jìn)行交互。非?？岬墓δ?！由以下人員處理：

/System/Library/PrivateFrameworks/AccessibilityUI.framework/XPCServices/com.apple.accessibility.AccessibilityUIServer.xpc/com.apple.accessibility.AccessibilityUIServer

和

/System/Library/CoreServices/AssistiveTouch.app/assistivetouchd

這些功能必須訪問麥克風(fēng)或攝像頭才能運(yùn)行。但是，這些功能不會觸發(fā)綠色/橙色視覺指示器。這意味著移動惡意軟件也可以做同樣的事情。

這意味著，通過向com.apple.accessibility.AccessibilityUIServer/com.apple.speechrecotioncore.speechrecotioncore.speechrecotiondaemon注入一個惡意線程，攻擊者就可以對麥克風(fēng)進(jìn)行靜默訪問。攝像頭訪問需要額外的補(bǔ)丁，我們稍后會討論它。

繞過TCC提示

TCC代表“透明度、同意和控制”。iOS用戶經(jīng)常會遇到這樣的提示：

TCC的核心是一個名為tccd的系統(tǒng)守護(hù)進(jìn)程，它管理對敏感數(shù)據(jù)庫的訪問以及從輸入設(shè)備（包括但不限于麥克風(fēng)和攝像頭）收集敏感數(shù)據(jù)的權(quán)限。

TCC提示符只適用于具有UI界面的應(yīng)用程序。任何在后臺運(yùn)行的東西都需要特殊的權(quán)限才能操作。權(quán)限如下圖所示。只需要kTCCServiceMicrophone就可以接入麥克風(fēng)。

攝像頭訪問稍微復(fù)雜一些。除了tccd之外，還有另一個名為mediaserverd的系統(tǒng)守護(hù)進(jìn)程確保沒有后臺運(yùn)行狀態(tài)的進(jìn)程可以訪問攝像頭。

到目前為止，當(dāng)用戶與另一個前臺應(yīng)用程序交互時，似乎需要一個額外的步驟（例如修補(bǔ)mediaserverd）來訪問后臺的攝像頭。

禁用麥克風(fēng)、攝像頭訪問的可視指示器

第一種方法比較粗糙，使用Cycript向SpringBoard注入代碼，導(dǎo)致指示器突然消失。

受com.apple.SpeechRecognitionCore.speechrecognitiond和com.apple.accessibility.AccessibilityUIServer的啟發(fā)，這是一種非常適合我們目的的私有權(quán)限(com.apple.private.mediaexperience.suppressrecordingstatetosystemstatus)！不幸的是，此方法不適用于攝像頭訪問。

通過修復(fù)“mediaserverd”在后臺訪問攝像頭

mediaserverd是一個監(jiān)控媒體捕獲會話的守護(hù)進(jìn)程。想要訪問攝像頭的進(jìn)程必須得到tccd和mediaserverd的批準(zhǔn)。它是tccd之后的額外安全層。當(dāng)它檢測到應(yīng)用程序不再在前臺運(yùn)行時，它還會終止攝像頭訪問。

值得注意的是，mediaserverd配備了一個特殊的權(quán)限（get-task-allow）來防止代碼注入。

由于“get-task-allow”授權(quán)，動態(tài)調(diào)試器依賴于獲取任務(wù)端口，如cycript，frida在mediaserverd守護(hù)進(jìn)程上不起作用。當(dāng)mediaserverd沒有響應(yīng)時，它也會經(jīng)常被系統(tǒng)阻止，即使是很短的時間。這并不常見：這些跡象告訴我們mediaserverd負(fù)責(zé)一些重要的事情。

當(dāng)進(jìn)程切換到后臺時，mediaserverd將收到通知并撤銷對該特定進(jìn)程的攝像頭訪問權(quán)限。我們需要找到一種方法，讓mediaserverd在檢測到進(jìn)程在后臺運(yùn)行時不做任何事情。

經(jīng)過簡短的研究，我們發(fā)現(xiàn)可以通過掛鉤到Objective-C方法-[FigCaptureClientSessionMonitor_updateClientStateCondition:newValue:]來防止mediaserverd撤銷對攝像頭的訪問權(quán)限，因此不需要代碼覆蓋。

為了注入mediaserverd，我們使用了lldb。Lldb不依賴于任務(wù)端口，而是調(diào)用內(nèi)核進(jìn)行代碼注入。實際上，已經(jīng)具有內(nèi)核代碼執(zhí)行能力的攻擊者可以替代mediaserverd的“權(quán)限”來執(zhí)行此類注入。

POC源代碼可以在這里找到。

根據(jù)2015年之前的實驗，Mac上前置攝像頭旁邊的綠燈不能僅使用軟件關(guān)閉。修改AppleCameraInterface驅(qū)動程序并上傳自定義網(wǎng)絡(luò)攝像頭固件沒有解決問題。綠燈無法關(guān)閉，因為它在攝像頭開機(jī)時亮起。只要有電，燈就會一

熱點：iOS