曾幾何時，人們對於蘋果產品的信任程度就好像他們經常使用的冰箱、空調、洗衣機一樣，但隨著「蘋果絕對安全」謠言的破滅，更多安全人員開始投身到蘋果產品的漏洞挖掘研究之中。
今年年初，蘋果手機軟體FaceTime的一項重大漏洞被曝光，更是讓人們深知世上並無絕對的安全可言。
據The Verge報導，該漏洞可以讓用戶通過 FaceTime 群聊功能（Group FaceTime）打電話給任何人，在對方接受或拒絕來電之前，就能聽到他們手機裡的聲音，該漏洞的曝光把蘋果推上了輿論的風口浪尖。
那麼，這樣的漏洞是如何被發現的呢？除了上述漏洞之外，FaceTime是否還存在著其他安全風險呢？
在此次ISC上，盤古團隊聯合創始人王鐵磊、盤古實驗室研究員黃濤就「蘋果FaceTime零接觸遠程漏洞首次被還原」這一議題詳細解密了FaceTime的逆向全程並分享了幾個典型的漏洞案例。
內繁外簡的FaceTime
但凡用過FaceTime的用戶，一定對下面這張圖不會陌生。它看起來要比微信、QQ的主界面更加清晰、簡潔，這十分符合蘋果的一貫風格。
然而，對FaceTime進行過逆向漏洞挖掘研究的黃濤卻深知它的「內在」遠沒有我們看到的這麼簡單，其內部結構甚至可以使用「錯綜複雜」來形容。
通過逆向分析黃濤發現，FaceTime UI界面其實分成了通訊框和視頻區兩個部分。看似簡單的UI區域實則是由多個進程在合作完成整個UI的運作，它們分別是callservicesd、avconferenced（macOS）和mediaserverd（iOS）三個部分組成。
其中，callservicesd進程主要負責渲染通訊框部分，以及撥打或者掛電話的功能。callservicesd進程主要管理了三個功能——第一個是FaceTime接聽、撥打的音視頻狀態；第二個是反饋、響應一些FaceTime產生的UI上的數據；其次會為avconferenced（macOS）和mediaserverd（iOS）兩個進程去提供信息傳遞的橋梁。
avconferenced和mediaserverd主要負責右邊的視頻區，它們負責處理通訊時的圖像內容，其主要的功能就是將自身的音視頻發給遠端或者處理遠端傳遞過來的音視頻信息。
現在試想，當一個用戶撥打FaceTime請求的時候，首先會點擊左邊的通訊框內容選擇通話對象，這時UI會發送UINotification-Call通信，以此告知系統「我要打一個電話出去」。
這個時候callservicesd就會接受到系統發出的UINotification，它會通過一個函數開啟通話模式的請求。然後，callservicesd就會調用【CSDFaceTimeProviderDelegateprovider：performStartCallAction】函數與avconferenced做交互，獲取到lnviteData請求並以此建立通話渠道。
在通話渠道創建之後，其通訊數據會被返回給callservicesd。這時callservicesd會將其內部的通訊數據封裝起來並傳送給identityservicesd，這就是callservicesd的第三個動作，也是和avconferenced（macOS）以及mediaserverd（iOS）建立通信橋梁的過程（identityservicesd是一個系統進程，主要用來管理用戶和iCould和MAC的連接）。
隨後，identityservicesd會將通訊信息機型封裝，並且同時把它傳輸給一個叫apsd（用於和蘋果發射推送數據）的進程，後者和蘋果保持了可行的安全連接，它們在持有交互證書的情況下運作以確保進程的安全性。
在apsd收到來自identityservicesd的封裝信息之後，前者會再度將一層一層的數據打包成一個對象，同時將其推送給AppleServer。當然，蘋果伺服器不會簡單地把消息推送過去，而是會對消息做一個簡單的過濾。
「老實說，我們發現這種過濾機制並非真的能確保FaceTime整個運作進程的安全可靠，在尚未被過濾的信息中，我們仍可找到可能被攻擊者遠端控制的數據。」
原來，研究人員會人為發送一組數據進入到上述的進程流程當中，在經過蘋果伺服器過濾後，再通過對比這些數據和遠端發送的數據，以此得知哪些數據是可控的。在這個流程完成後，蘋果伺服器就會把apsiMessage傳遞給遠端的apsd，也就是被呼叫那個用戶的設備上了。
在接聽方設備收到數據後，便能夠看到來自撥打方的音視頻信息，為了實現雙向交流，與此同時apsd收到的數據會採用與上述完全一致的封裝結構來反序列化apsiMessage。為了方便觀察apsiMessage中具體包含了哪些數據信息，通常會在其反序列的函數裡面設置一個斷點。
通過設置斷點，可以看到其中幾個比較重要的參數，它們標示了apsd數據包究竟會被傳輸到那裡進行處理。apsd會通過兩個參數把消息傳遞給mediaserverd，之後進一步進行反序列化。
「最終，我們在mediaserverd函數裡面看到數據變了，其中有一個欄位叫做C的值是232，其代表遠端發來的是一個Notification。通過不同的C值，比如說232、233、234、235來調用不同的函數去處理Notification，所以即便不改變漏洞內容，只改變與之對應的處理函數會不一樣。」
緊接著，mediaserverd會繼續把數據解開然後發給callservicesd，其同樣也會把數據進行反序列化，將其推送給遠端的mediaserverd。如此以來，遠程呼叫端的設備就獲取到了呼叫端的媒體配置信息和加密信息。在這些數據處理完之後，呼叫端遠端就會跳出一個UI上面顯示——有一個人正在通過Facetime與你通話的音視頻信息。
這樣一來，一次FaceTime的通話連接便被建立起來了。
為了實現實時的通話需求，遠端用戶接通的時候同樣會產生一個與上述FaceTime UI數據傳遞路徑完全一致的反交換過程，這一過程同樣會被遠端的callservicesd去處理，接下來流程和之前幾乎是一樣。
「值得注意的是，在反向通訊的過程中之前的C值不是232而是233了，這時遠端已經接受了對方設備視頻的請求，這時會調用相應函數值來處理返回過來的數據。這種情況下，兩端都會打開各自的avconferenced（macOS）和mediaserverd（iOS）埠，並且在穿牆協議的幫助下實現雙方找到IP建立端對端連結。」
通過端對端的連結，identityservicesd負責處理和接收網絡包，另一個函數會調用apsiMessage從udp埠拿到網絡包傳遞給IDSGlobaLink，後者會判斷該網絡報是否符合seiten協議，如果是就會將其傳送給對應的執行函數，進一步解析網絡包，再次將其發送給更細分的執行函數。與此同時，identityservicesd還會響應一些其他的協議。
這張圖是真正的在建立FaceTime之後其數據的音視頻究竟是怎樣的，到這裡逆向的分析也就告一段落了。
可見，看似簡潔的FaceTime其進行數據處理、執行及反饋的渠道多到令人咋舌的地步，這也註定FaceTime更容易存在攻擊面。而對於如此龐雜的數據流通線路，其中需要用戶進行操控的地方少之又少，這就意味著一旦攻擊開始，其整個過程具有極強隱蔽性。
FaceTime的4個漏洞案例分享
從上面FaceTime逆向的過程可以看出，實際上從呼出到最終的雙方看到音視頻信息是一個非常長的處理流程。也就是說，一旦逆向分析有所疏漏，漏洞挖掘的過程只是在某一層進行，這就難免會使得研究數據完整性欠缺，甚至會損壞其格式。
那麼，在搞清楚FaceTime的工作原理之後，關於其漏洞挖掘的過程才算真正開始。在這裡，王鐵磊分享了4個FaceTime的漏洞分析案例。
案例1
第一個案例介紹的是一個疑似的信息洩露，這個漏洞發生在從apsd到avconferenced之間，也就是在最初的信息數據包處理上。
通過查看數據流，發現攻擊者的數據包中包含了一些U欄位的報文數據。這個U欄位數據實際上是一個UUID，其本身只是一些嵌入符號，並沒有什麼特別的含義。
「但是，我們發現通過在其前後插入額外的欄位，可以讓這些原本毫無意義的欄位來強制執行一些命令。」
首先在Notification插入一些額外的欄位，當遠端收到之後U欄位和人工植入的數據都在其中，於是強制返回包中會包含UUID——到目前為止整個流程上還沒有什麼問題，只是一方面是數據的發送另一方面是信息的返回。但是，因為這裡有同樣的欄位，這也正是漏洞的所在。
首先，來看看這段代碼的具體意思——收到一個Notification以後，遠端會把整個字典數據做一個分析，它先試圖去看有沒有所謂的U欄位，有的話就把U欄位所對應的數據包給取出來，並假定其是一個AI Sdatae，然後將其作為參數傳入一個以GWUUID開頭的函數中，其本意是為了把AI Sdatae轉換成一個CFStun，但是這個假定數據的長度是16位元組，而因為其調用的一個函數的LOKCBfer是沒有初始化的，這就意味這如果發出去的UUID的長度不到16位元組，那麼就有可能得到一個未初始化的棧溢出數據。
為了證明上述猜測，研究人員首先發送了一個遠端的UUID。研究人員的最初想法，是想看到的輸出一些值得關注的地址，但卻發現改造後的Notification發過去後在遠端收到的UUID不見了，這就意味著蘋果伺服器那端把短的UUID剝離掉了，從代碼角度來看這是一個100%未初始化內存洩露的問題，但是真實POC構造過程中蘋果伺服器扮演了一個未知的角色，因此不確定是何時開始過濾的。
案例2
當FaceTime的連接建立之後，一個非常重要的一個角色就是mediaserverd，因為mediaserverd進程負責第一層網絡報文的處理，FaceTime的所有數據或者其它控制的發送，這些報文在最初的未處理狀態都被mediaserverd服務運行。
mediaserverd會根據包的內容來去選擇是哪些其它的進程或者是其它的函數來處理，其中typeMessage攻擊者就可以通過udp把攻擊文件發送到遠端的mediaserverd，遠端的mediaserverd會識別typeMessage。
根據它的協議，typeMessage在偏移為「4」的地方會有執行。因此，從代碼執行上可以看到mediaserverd就是做了一個比較，如果包裡存在為「4」的值那就是typeMessage，然後將其一個函數除去，之後發送的報文會被反序列化成為一個叫IDSStunMessage的對象，而IDSStunMessage在這個反序列化構成中沒有發現什麼特別的漏洞，然後當typeMessage被反序列化成這個對象以後，會進一步處理函數。
實際上，期間過程中一共包含了20個屬性，他們全部是從udp報文中拷貝過去的，也就是說它們在現在這一階段是完全可以被攻擊者控制的。如果typeMessage中的type數值為「0x17」，這時會阻斷一個特殊函數，其功能是將類型為19的屬性取出來，這一過程都屬於安全流程，但是在隨後的反序列化過程中就會暴露出很多問題。
反序列化的時候數據格式非常簡單，它就是兩字節的type兩字節的長度。但實際上，這裡面如果看到一個屬性的type是0xF或者很多種類型的屬性都會得到一個叫readIDSGLAttrBinaryData的函數，其過程會調用到memcpy。而這個memcpy的case參數完全可控，其執行難度不大，稍加長度布局的改動即可讓其顯示141414...的錯誤顯示，這是一個典型的堆出漏洞。
案例3
callservicesd會把數據再轉給avconferenced（macOS）或者mediaserverd（iOS），這其實進入到了音視頻流的處理流程，而這裡的這個漏洞是一個棧溢出。
該漏洞的原理是——當去做視頻剪輯的時候，一幀數據可能會很大，這個時候一個處理單元就可能被分割成多個RTP包被進行傳送，然後接受方接收了這些包之後再重組成完整數據包做處理。由於RTP包是通過UDP包來的，所以有前有後，為了維持如此布局就要將這些RTP都進行串聯，在傳送到之後才重組起來。
在每收到一個RTP包的時候會嚴格檢查包的格式，但是有時候會出現丟包的情況，在蘋果的處理方案中，其引入了一種容錯機制——它可以通過已經收到的包去重構出一些已丟包的基本信息，這就是為什麼在發生網絡抖動的時候，FaceTime聊天的畫面會糊一點，但還是能夠保持能看到基本的內容的原因。
但是問題在於，在做包修復的時候，RTP裡面會含一個叫做FEC的東西會重構出RTP包，重構出來的長度則是在FEC Header裡面制定的。但是FEC Header是沒有經過任何檢查的，所以最後導致的後果就是容錯機制被調度起來的時候，執行函數中的size是完全可控的，這是最經典的棧溢出。
那麼，在2019年iOS上面，棧溢出還能不能利用？
實際上，像這種傳統的經典棧溢出的最有效防範就是啟用cookie。它的基本原理就是當函數值被調用的時候，在返回地址和局部變量之間插入一個cookie，在函數返回的時候從棧上把剛才的cookie拿出來作比較，如果二者不一致的話那麼意味著整個cookie都被破壞掉了，很可能返回地址也已經被破壞掉了，所以這時該程序就可以主動地退出，避免整個返回地址被控制住。
這種連續溢出會破壞stack_cookie，這些指令在函數執行進來的時候，函數參數（地址）已經在棧上了，有些指令可以把一些寄存器暫時壓在棧上，這幾條指令在分配局部變量，其實也是在放置棧的cookie。
其中的問題是，棧cookie被放在了局部變量後面，這就意味著當局部變量發生棧溢出的時候它會直接覆蓋到crashed而無需破壞stack_cookie。這個問題十分嚴重，stack_cookie根本沒有放在一個合適的位置，自然也起不了正常的作用。
通過crash log的截圖可以看出，在iOS上可以看到serverd34號線程已經發生了崩潰，整個PC已經完全被控制，變成了808080，與此同時其他的寄存器也都被控制了。在將該漏洞報告蘋果後，後者在12.4版本中做了修復，但事情並沒有就此告一段落：
在意識到stack_cookie出問題的時候，研究人員又去檢查了其他的模塊及函數，他們發現很多函數都有這個問題，因此他們意識到這裡還有一個編譯器的漏洞。因此，結論是這是一個在FaceTime棧溢出背後還有一個編譯器漏洞問題。
實際上，蘋果是LLVM編譯器的一個最大推手，如果蘋果編譯器有問題那麼多半意味著LLVM編譯器有問題，最終這個問題蘋果的安全團隊在進行更詳細的分析後發現確實如此，其影響的是整個品牌的編譯器產品，這也是為什麼之後該廠商為這樣一個威脅程度為0的漏洞發布了公開聲明的原因。
案例4
identityservicesd會根據收到的Notification裡的一個函數決定是將消息發給callservicesd還是其它的服務。這是一個叫做Phone countinuity的漏洞，它原本是可以實現在MAC筆記本和iPhone在登陸統一Apple ID的情況啟用通話功能的一項附加功能。雷鋒網雷鋒網雷鋒網(公眾號：雷鋒網)
實際上，這就意味著手機和電腦之間存在著一個數據通道。他們也做了一些逆向分析，最終發現這個還是在identityservicesd做的處理。
其實會存在這樣的執行路徑，IDSLinkManager最後會走到一個叫做IDSSockAddrWrapper initWithSockAddr：的函數。這個函數實際是根據UTP包中的內容去反序列化一些地址，這裡也是最終出問題的地方。如果大家對去年的imptcp模塊安全漏洞熟悉的話，iOS內核嘗試著去把一個用戶的數據反序列化成一個soft地址，問題是對於一個有效地址其長度是0X80，但一個soft結構體它的長度域可表達的範圍是0XFF，這就與意味著當把一個地址進行拷貝時，要根據其第一字節的長度來進行調節，因此一定要做嚴格的長度檢查。但是，這個函數裡只對地址域進行了檢查，沒有檢查長度，這意味著可以把第一個字節填稱0XFF最多可以溢出0XFF-[字節長度]這麼長，那這個函數和前面說到了漏洞利用十分接近。
總結
在整個分析中，FaceTime的大量攻擊漏洞被逐一挖掘出來。
在對FaceTime進行分析時王鐵磊稱，首先，FaceTime的代碼質量非常差，這個出乎他們的預期，整個FaceTime需要一個極大的提高，否則隨著安全研究人員的不斷挖掘會有更多漏洞被曝出來；其次，整個Message的接口有非常大的畸變，其本質都是通過identityservicesd做的一個轉化，這麼多功能糅雜在一起也就意味這複雜性很高，那麼攻擊面是非常大的；最後對於進行安全研究的人員來說，很多老的漏洞並沒有過時，比如上面講的棧溢出就是十分經典的例子。