安全動態(tài)

新款iPhone SE開售前夕,iOS被曝存在八年的0day漏洞

來源:聚銘網(wǎng)絡(luò)    發(fā)布時間:2020-04-24    瀏覽次數(shù):
 

信息來源:Freebuf


近日,安全研究人員發(fā)現(xiàn)iPhone和iPad自帶的默認(rèn)郵件應(yīng)用程序MobileMail 和Maild存在兩個正在被在野利用的嚴(yán)重漏洞,而且至少在兩年前就已經(jīng)開始監(jiān)視用戶了。

這兩個漏洞允許遠(yuǎn)程攻擊者秘密獲取蘋果設(shè)備的控制權(quán),只要向已經(jīng)登錄郵件賬號的用戶設(shè)備發(fā)送電子郵件即可。這可能會使超過5億部iPhone容易受到黑客的攻擊。同時,iPad也存在這一問題。

舊金山的一家手機(jī)安全取證公司ZecOps在周三發(fā)布的一份報(bào)告中表示,在2019年末調(diào)查一起客戶網(wǎng)絡(luò)攻擊事件時,發(fā)現(xiàn)了該問題。ZecOps創(chuàng)始人Zuk Avraham表示,他發(fā)現(xiàn)證據(jù)顯示,這一漏洞至少在六起網(wǎng)絡(luò)入侵事件中被利用。

Zuk推特聲明

該漏洞是存在于蘋果自帶郵件應(yīng)用程序中的MIME庫中的遠(yuǎn)程代碼執(zhí)行漏洞,首先是因?yàn)樵浇鐚懭脲e誤,其次是堆溢出問題。

盡管兩個電子郵件都是在處理郵件時觸發(fā)的,但是第二個漏洞更為嚴(yán)重一些,因?yàn)槠淇梢詫?shí)現(xiàn)“零點(diǎn)擊”利用,無需任何用戶交互。

iOS 13上的漏洞觸發(fā):在后臺打開Mail應(yīng)用程序時,iOS 13上的無輔助(零點(diǎn)擊)攻擊;

iOS 12上的漏洞觸發(fā):攻擊需要單擊電子郵件,攻擊將在呈現(xiàn)內(nèi)容之前觸發(fā),用戶不會在電子郵件本身中發(fā)現(xiàn)任何異常;

如果攻擊者控制郵件服務(wù)器,則可以觸發(fā)(即零點(diǎn)擊)iOS 12上的無輔助攻擊。

報(bào)告中還提及疑似遭受攻擊的目標(biāo):

來自北美財(cái)富500強(qiáng)企業(yè)的員工;

日本某航空公司的高管 ;

來自德國的貴賓;

來自沙特阿拉伯和以色列的MSSP;

歐洲記者;

懷疑:一家瑞士企業(yè)的高管。

八年零日漏洞在野利用

據(jù)研究員表明,兩個漏洞存在iPhone 和iPad多個版本中長達(dá)8年,可以追溯到iOS6,甚至影響了當(dāng)前的iOS 13.4.1,常規(guī)版本尚且沒有補(bǔ)丁更新。

更讓人擔(dān)憂的是,多個攻擊者組織長期利用這些漏洞(至少在野零日攻擊中利用了2年最早可追溯到2018年1月)。

研究人員說:“目前公布的攻擊數(shù)據(jù)有限,但是至少有6個組織或者個體遭受攻擊,影響力還是很大的。盡管ZecOps沒有發(fā)現(xiàn)攻擊的幕后黑手,但是我們了解到至少有一個“雇傭組織”在銷售該漏洞利用,并將電子郵件地址作為唯一標(biāo)識符。

此外,對于蘋果用戶本身來說是很難意識到黑客的入侵的,因?yàn)樗麄冊讷@取用戶遠(yuǎn)程操控之后,可以立即刪除惡意電子郵件。

盡管數(shù)據(jù)表示是用戶的iOS設(shè)備接收和處理電子郵件的,但是本應(yīng)存儲在郵件服務(wù)器上的郵件卻消失了,因此可以推斷故意刪除是攻擊手段的一部分。

除了郵件使用速度的短暫下降以外,用戶沒法發(fā)現(xiàn)任何的異常行為。成功的漏洞利用是讓黑客在MobileMail 或者M(jìn)aild 應(yīng)用程序中執(zhí)行惡意代碼,并竊取、修改或者刪除郵件。

然而,想要完全操控設(shè)備,黑客還需要一個助手,即單獨(dú)的內(nèi)核漏洞(比如無法修補(bǔ)的Checkm8漏洞)。盡管目前研究人員還沒有發(fā)現(xiàn)黑客使用的惡意軟件細(xì)節(jié),但是郵件的漏洞和內(nèi)核漏洞結(jié)合使用來監(jiān)控他們的目標(biāo)用戶也不是沒有可能。

當(dāng)心!目前尚無可用補(bǔ)丁

研究人員在兩個月前發(fā)現(xiàn)這次的在野利用攻擊,并將其報(bào)告給蘋果安全團(tuán)隊(duì)。

截至發(fā)文,只有iOS13.4.5 beta版本在上周發(fā)布,包含了這兩個漏洞的安全補(bǔ)丁。

而數(shù)百外的iPhone 和iPad用戶還需等待下一次的軟件安全補(bǔ)丁更新。與此同時,強(qiáng)烈建議蘋果用戶不要使用設(shè)備內(nèi)置的郵件應(yīng)用程序。

漏洞詳情

ZecOps發(fā)現(xiàn),在MIME庫中的執(zhí)行MFMutableData,沒有對系統(tǒng)調(diào)用ftruncate()進(jìn)行錯誤檢查,這會導(dǎo)致越界寫入。研究人員找到了一種無需等待系統(tǒng)調(diào)用ftruncate失敗即可觸發(fā)OOB-Write的方法。此外,他們還發(fā)現(xiàn)可以遠(yuǎn)程觸發(fā)的堆溢出。

事實(shí)上,這兩種漏洞都是遠(yuǎn)程觸發(fā)的。 OOB寫入錯誤和堆溢出錯誤都是由于相同的問題而發(fā)生的:未正確處理系統(tǒng)調(diào)用的返回值。

遠(yuǎn)程錯誤可以在處理下載電子郵件時觸發(fā),在這種情況下,電子郵件將無法完全下載到設(shè)備上。

受影響的庫:/System/Library/PrivateFrameworks/MIME.framework/MIME

漏洞功能:-[MFMutableData appendBytes:length:]

事故取證分析

用戶經(jīng)歷的部分崩潰(多次崩潰中的一部分)如下。

崩潰指令是stnp x8, x9, [x3],這意味著價值x8,并x9已寫入x3并墜毀由于訪問無效的地址0x000000013aa1c000,其存儲在x3。

Thread3Crashed:

0  libsystem_platform.dylib          0x000000019e671d88_platform_memmove+88

0x19e671d84        b.ls0x00008da8               

0x19e671d88        stnpx8,x9,[x3]             

0x19e671d8c        stnpx10,x11,[x3, #16]      

0x19e671d90        addx3,x3, 0x20              

0x19e671d94        ldnpx8,x9,[x1]             

1  MIME                              0x00000001b034c4d8-[MFMutableData appendBytes:length:]+ 356

2  Message                           0x00000001b0b379c8-[MFDAMessageContentConsumer consumeData:length:format:mailMessage:]+ 808

為了找出導(dǎo)致流程崩潰的原因,來看一下MFMutableData的實(shí)現(xiàn)。

下面的調(diào)用樹取自部分崩潰日志。

-[MFDAMessageContentConsumer consumeData:length:format:mailMessage:] | +-- -[MFMutableData appendData:] | +-- -[MFMutableData appendBytes:length:] | +-- memmove()

通過分析MIME庫, -[MFMutableData appendBytes:length:] 偽代碼如下:

崩潰發(fā)生之前,已執(zhí)行以下調(diào)用堆棧:

-[MFDAMessageContentConsumer consumeData:length:format:mailMessage:] | +-- -[MFMutableData appendData:]| +-- -[MFMutableData appendBytes:length:]| +-- -[MFMutableData setLength:]| +-- -[MFMutableData _flushToDisk:capacity:]| +-- ftruncate()

如果數(shù)據(jù)大小達(dá)到閾值,則使用文件來存儲實(shí)際數(shù)據(jù),當(dāng)數(shù)據(jù)更改時,應(yīng)相應(yīng)更改映射文件的內(nèi)容和大小。-[MFMutableData _flushToDisk:capacity:]在內(nèi)部調(diào)用系統(tǒng)調(diào)用ftruncate()來調(diào)整映射文件的大小。

以下是-[MFMutableData _flushToDisk:capacity:] 的偽代碼:

ftruncate詳情主頁:

ftruncate() andtruncate() cause thefilenamedbypath,orreferencedbyfildes,tobe truncated (orextended)tolengthbytesinsize.Ifthefilesizeexceedslength,anyextradataisdiscarded.Ifthefilesizeissmallerthanlength, thefileisextendedandfilledwithzerostothe indicatedlength. The ftruncate()formrequires thefiletobeopenforwriting.RETURNVALUESAvalueof0isreturnedifthecallsucceeds.Ifthecallfails a-1isreturned,andtheglobalvariableerrno specifies theerror.

主頁顯示:“If the call fails a -1 is returned, and the global variable errno specifies the error.”這意味著在某些情況下,此系統(tǒng)調(diào)用將無法截?cái)辔募⒎祷劐e誤代碼。

然而,一旦系統(tǒng)調(diào)用ftruncate失敗,無論如何_flushToDisk會繼續(xù)進(jìn)行,這意味著在appendBytes()函數(shù)中映射文件大小沒有延伸并無法執(zhí)行達(dá)到memmove(),這導(dǎo)致MMAP文件的OOB寫入。

尋找另一個觸發(fā)因素

崩潰是由于系統(tǒng)調(diào)用ftruncate()失敗引起的,是否意味著除了等待系統(tǒng)調(diào)用失敗之外什么也不能做?

再來看一下-[MFMutableData _flushToDisk:capacity:]函數(shù)。

在[b]行中所見,檢查flush在調(diào)用ftruncate()之前標(biāo)志是否為true。這意味著,如果可以將flush在第[a]行將標(biāo)志設(shè)置為false ,則ftruncate()根本不會執(zhí)行。

如果有人在調(diào)用-[MFMutableData appendData:]之前調(diào)用-[MFMutableData setLength:](set flush to  0), ftruncate() won’t be executed due to flush==0),將會得到類似的結(jié)果。

將此OOB Write與其他漏洞或控制內(nèi)存布局的方法結(jié)合使用,可以遠(yuǎn)程觸發(fā)此漏洞,例如,通過控制選擇器。

盡管這確實(shí)是一個應(yīng)修補(bǔ)的漏洞,但我們懷疑它是由攻擊者試圖利用以下漏洞而觸發(fā)的。

第二個漏洞:MFMutable中的遠(yuǎn)程堆溢出

研究人員繼續(xù)調(diào)查可疑的遠(yuǎn)程事件,并確定同一區(qū)域存在另一個漏洞。

回溯可以如下所示:

-[MFDAMessageContentConsumer consumeData:length:format:mailMessage:] | +-- -[MFMutableData appendData:] | +-- -[MFMutableData appendBytes:length:] | +-- -[MFMutableData _mapMutableData]

在分析代碼流時,研究人員確定了以下內(nèi)容:

[MFDAMessageContentConsumer consumeData:length:format:mailMessage:]以原始MIME格式下載電子郵件時,將調(diào)用該函數(shù),并且在以Exchange模式下載電子郵件之前,還將多次調(diào)用該函數(shù)。它將創(chuàng)建一個新NSMutableData對象,并對屬于同一電子郵件/ MIME消息的任何新流數(shù)據(jù)調(diào)用appendData:。對于其他協(xié)議(如IMAP),它使用-[MFConnection readLineIntoData:]代替,但邏輯和漏洞相同。

NSMutableData將閾值設(shè)置為0×200000字節(jié),如果數(shù)據(jù)大于0×200000字節(jié),它將把數(shù)據(jù)寫入文件,然后使用系統(tǒng)調(diào)用mmap將文件映射到設(shè)備內(nèi)存。0×200000的閾值大小很容易被超過,因此每次需要添加新數(shù)據(jù)時,文件都會被重新映射,并且文件大小以及mmap大小會越來越大。

在內(nèi)部重新映射完成-[MFMutableData _mapMutableData:],漏洞存在該函數(shù)內(nèi)部。

易受攻擊的函數(shù)的偽代碼如下:

系統(tǒng)調(diào)用mmap失敗時,- [MFMutableData_mapMutableData:]調(diào)用函數(shù)MFMutableData__mapMutableData___block_invoke

image.png

偽代碼MFMutableData__mapMutableData___block_invoke如下,它分配了一個大小為8的堆內(nèi)存,然后用分配內(nèi)存替換data->bytes指針。

image.png

執(zhí)行-[MFMutableData _mapMutableData:]完之后,進(jìn)程繼續(xù)執(zhí)行-[MFMutableData appendBytes:length:],將數(shù)據(jù)復(fù)制到分配內(nèi)存時導(dǎo)致堆溢出。

-[MFMutableDataappendBytes:length:]

{

int length = [selflength];

//...

bytes =self->bytes;

if(!bytes){

bytes = [self_mapMutableData];//Might be a data pointer of a size8heap

}

copy_dst = bytes + length;

//...

platform_memmove(copy_dst, append_bytes, append_length);//It used append_length to copy the memory, causing an OOB writingina small heap

}

append_length是來自流式傳輸?shù)臄?shù)據(jù)塊的長度。由于這MALLOC_NANO是一個可預(yù)測的內(nèi)存區(qū)域,因此可以利用此漏洞。

攻擊者無需耗盡內(nèi)存的每一個最后一位就可以使mmap失敗,因?yàn)閙map需要一個連續(xù)的內(nèi)存區(qū)域。

復(fù)現(xiàn)

根據(jù)mmap操作說明,在MAP_ANON was specified and insufficient memory was available時mmap會失敗。

mmap失敗是正常情況,理想情況下,電子郵件夠大就不可避免地會發(fā)生。但是,可以使用其他可耗盡資源的技巧來觸發(fā)漏洞。這些技巧可以通過多方面,比如RTF和其他格式來實(shí)現(xiàn)。

可能影響可利用性的另一個重要因素是硬件規(guī)格:

iPhone 6:1GB

iPhone 7:2GB

iPhone X:3GB

較舊的設(shè)備具有較小的物理RAM和較小的虛擬內(nèi)存空間,因此不必耗盡RAM的每一位來觸發(fā)此錯誤,當(dāng)無法在可用虛擬內(nèi)存中找到給定大小的連續(xù)內(nèi)存空間時,mmap將失敗。

目前已經(jīng)確定MacOS不會同時受到這兩個漏洞的攻擊。

在iOS 12中,觸發(fā)漏洞更容易,數(shù)據(jù)流傳輸是在同一過程中完成的,因?yàn)槟J(rèn)郵件應(yīng)用程序(MobileMail)會處理更多的資源,從而耗盡了虛擬內(nèi)存空間(尤其是UI)的分配渲染,而在iOS 13中,MobileMail將數(shù)據(jù)流傳遞到后臺進(jìn)程maild。它把資源集中在解析電子郵件上,從而降低了虛擬內(nèi)存空間意外用完的風(fēng)險。

遠(yuǎn)程復(fù)現(xiàn)

由于MobileMail / maild并未明確設(shè)置電子郵件大小的最大限制,因此可以設(shè)置自定義電子郵件服務(wù)器并發(fā)送具有幾GB純文本的電子郵件。iOS MIME /消息庫在流傳輸數(shù)據(jù)時將數(shù)據(jù)平均分成大約0×100000字節(jié),因此完全可以不下載整個電子郵件。

請注意,這只是如何觸發(fā)此漏洞的一個示例。攻擊者無需為了觸發(fā)此漏洞而發(fā)送此類電子郵件,使用多種方式,比如RTF或其他格式等技巧,可以使用標(biāo)準(zhǔn)大小的電子郵件實(shí)現(xiàn)相同的目標(biāo)。

披露時間表

2020年2月19日,根據(jù)ZecOps負(fù)責(zé)任的披露政策,向供應(yīng)商報(bào)告了可疑事件,該事件允許立即發(fā)布在野觸發(fā)因素;

受影響的供應(yīng)商與ZecOps之間的持續(xù)進(jìn)行攻擊;

3月23日,ZecOps向受影響的供應(yīng)商發(fā)送了OOB Write漏洞的POC復(fù)制信息;

3月25日,ZecOps共享了OOB Write的本地POC;

3月31日,ZecOps確認(rèn)同一地區(qū)存在第二個漏洞,并且具有遠(yuǎn)程觸發(fā)功能(遠(yuǎn)程堆溢出),這兩個漏洞都是在野外觸發(fā)的;

3月31日,ZecOps與受影響的供應(yīng)商共享了POC,以解決遠(yuǎn)程堆溢出漏洞;

4月7日,ZecOps共享了一個自定義郵件服務(wù)器,只需在Mail中添加用戶名和密碼并下載電子郵件,即可輕松觸發(fā)iOS 13.4 / 13.4.1上的0單擊堆溢出漏洞;

4月15日至16日,供應(yīng)商在公開測試版中修補(bǔ)了這兩個漏洞;

4月20日,研究人員重新分析了歷史數(shù)據(jù),發(fā)現(xiàn)了VIP和目標(biāo)人物在野外觸發(fā)的其他證據(jù),并發(fā)送了一封電子郵件,通知供應(yīng)商,我們將必須立即發(fā)布此威脅通報(bào),這樣企業(yè)可以自我保護(hù),因?yàn)楣粽撸ㄒ驗(yàn)橐言贐eta中進(jìn)行了修補(bǔ))很可能會越來越活躍;

4月22日,公開披露。


 
 

上一篇:2020年04月23日 聚銘安全速遞

下一篇:Tekya惡意軟件混入Google Play