這篇文章將為大家詳細(xì)講解有關(guān)怎么對(duì)Microsoft Outlook漏洞的深入分析，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個(gè)參考，希望大家閱讀完這篇文章后對(duì)相關(guān)知識(shí)有一定的了解。

創(chuàng)新互聯(lián)建站專(zhuān)注于企業(yè)全網(wǎng)營(yíng)銷(xiāo)推廣、網(wǎng)站重做改版、平城網(wǎng)站定制設(shè)計(jì)、自適應(yīng)品牌網(wǎng)站建設(shè)、H5頁(yè)面制作、成都做商城網(wǎng)站、集團(tuán)公司官網(wǎng)建設(shè)、成都外貿(mào)網(wǎng)站制作、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁(yè)設(shè)計(jì)等建站業(yè)務(wù)，價(jià)格優(yōu)惠性?xún)r(jià)比高，為平城等各大城市提供網(wǎng)站開(kāi)發(fā)制作服務(wù)。

寫(xiě)在前面的話(huà)

MicrosoftOutlook是微軟Office套件中的一個(gè)組件，它可以用來(lái)發(fā)送和接收電子郵件，管理聯(lián)系人，記錄和跟蹤日程計(jì)劃，或執(zhí)行其他任務(wù)。近期，研究人員在Outlook 2010至Outlook 2019版本以及Office 365 ProPlus中發(fā)現(xiàn)了一個(gè)堆崩潰漏洞，Windows平臺(tái)下的32/64版本均會(huì)受到該漏洞影響。攻擊者可使用惡意RWZ文件來(lái)觸發(fā)該漏洞，當(dāng)Outlook收到惡意RWZ文件內(nèi)容時(shí)，它只會(huì)分配少量堆內(nèi)存，并且缺少恰當(dāng)?shù)倪吔鐧z測(cè)，最終導(dǎo)致堆內(nèi)存越界寫(xiě)入。

復(fù)現(xiàn)漏洞

為了復(fù)現(xiàn)該漏洞，我們需要運(yùn)行Microsoft Outlook，然后點(diǎn)擊“規(guī)則=>管理規(guī)則&警報(bào)=>選項(xiàng)=>導(dǎo)入規(guī)則”，選擇可以觸發(fā)Outlook崩潰的PoC文件。

下面給出的就是發(fā)生崩潰時(shí)的棧調(diào)用情況：

分析漏洞

我們可以從棧調(diào)用數(shù)據(jù)中看到，當(dāng)堆內(nèi)存被釋放時(shí)就發(fā)生程序崩潰了。因?yàn)槲覀儫o(wú)法判單堆釋放時(shí)發(fā)生了什么情況，所以我們需要打開(kāi)完整的堆內(nèi)存頁(yè)表來(lái)跟蹤堆內(nèi)存的數(shù)據(jù)變化，命令如下：

YOUR_WINDBG_INSATALL_LOCATION\gflags.exe/p /enable outlook.exe /full

上述命令返回的結(jié)果如下，表明命令已成功執(zhí)行了。

接下來(lái)，我們?cè)俅未蜷_(kāi)Outlook，選擇PoC文件并監(jiān)控崩潰發(fā)生時(shí)新的?？臻g情況：

現(xiàn)在我們可以看到，ECX指向的非0內(nèi)存地址時(shí)不可讀的，并且在向這個(gè)內(nèi)存地址寫(xiě)入數(shù)據(jù)時(shí)會(huì)發(fā)生異常，很有可能是因?yàn)槌绦蛟趪L試向未分配（或未釋放）的內(nèi)存地址寫(xiě)入數(shù)據(jù)。我們可以通過(guò)檢測(cè)內(nèi)存頁(yè)分配情況來(lái)驗(yàn)證這種猜想，此時(shí)我們會(huì)看到內(nèi)存仍然擁有Reserve屬性：

現(xiàn)在我們需要弄清楚，為什么程序會(huì)向未使用的內(nèi)存頁(yè)寫(xiě)入數(shù)據(jù)。通過(guò)靜態(tài)分析，我們可以看到ECX的值來(lái)自于EDI，而EDI貌似會(huì)在程序調(diào)用MAPIAllocateBuffer后被修改：

靜態(tài)分析的結(jié)果表明，MAPIAllocateBuffer函數(shù)其實(shí)是RtlAllocateHeap的封裝函數(shù)，而這個(gè)函數(shù)會(huì)確保請(qǐng)求的內(nèi)存大小參數(shù)不會(huì)超過(guò)0x7FFFFFF7。但是，它無(wú)法檢測(cè)該參數(shù)的值是否為0，因?yàn)閷?shí)際分配的堆大小為8字節(jié)，超過(guò)了請(qǐng)求的堆大小，這8個(gè)字節(jié)填充值為0x0000000001000010。接下來(lái)，MAPIAllocateBuffer會(huì)返回這8個(gè)字節(jié)后面的堆地址。因此，在調(diào)用MAPIAllocateBuffer之后EDI的值為8 + 分配的堆地址（來(lái)自RtlAllocateHeap）：

根據(jù)上面的靜態(tài)分析結(jié)果，我們可以大致判斷導(dǎo)致漏洞出現(xiàn)的原因?yàn)檎鸵绯鰡?wèn)題。通過(guò)調(diào)式后我們發(fā)現(xiàn)，調(diào)用MAPIAllocateBuffer時(shí)的堆大小參數(shù)為0，因?yàn)镸APIAllocateBuffer請(qǐng)求分配的堆大小為0+8=8，此時(shí)RtlAllocateHeap不會(huì)返回錯(cuò)誤，而是返回正確的堆地址。MAPIAllocateBuffer會(huì)使用這8字節(jié)來(lái)寫(xiě)入地址0x0000000001000010，然后把無(wú)效的內(nèi)存地址返回給用戶(hù)：

接下來(lái)，我們需要弄清楚請(qǐng)求的堆大小值為什么會(huì)變成0。原來(lái)，0值來(lái)自于當(dāng)前的一個(gè)函數(shù)參數(shù)：arg_4(eax = arg_4 * 4 + 4)。但是，當(dāng)這個(gè)函數(shù)被調(diào)用時(shí)，arg_4的值并非傳遞進(jìn)來(lái)的參數(shù)值，這也就意味著arg_4的值被修改了。分析后我們發(fā)現(xiàn)，罪魁禍?zhǔn)资瞧渥雍瘮?shù)sub_65F7DA：

在對(duì)子函數(shù)sub_65F7DA進(jìn)行分析后，我們發(fā)現(xiàn)它也是一個(gè)封裝函數(shù)。原來(lái)，這個(gè)函數(shù)是ReadFile，而arg_4得值實(shí)際上來(lái)自于PoC文件：

調(diào)試結(jié)果表明，arg_4讀取到的文件內(nèi)容為0xFFFFFFFF，因此堆內(nèi)存的分配大小就是0xFFFFFFFF * 4 + 4 = 0（整型溢出）。然而，程序并不會(huì)檢測(cè)這種錯(cuò)誤，最終導(dǎo)致了越界寫(xiě)入的情況出現(xiàn)：

在PoC文件中我們可以看到，并不存在0xFFFFFFFF這個(gè)值：

將其修改為0xAABBCCDD后再次進(jìn)行調(diào)試，我們就可以證實(shí)溢出就是由這4個(gè)字節(jié)造成的：

在安裝了修復(fù)補(bǔ)丁之后，我們對(duì)前后的程序代碼進(jìn)行了對(duì)比，我們發(fā)現(xiàn)補(bǔ)丁增加了對(duì)請(qǐng)求分配堆內(nèi)存大小的驗(yàn)證：

因此，廣大用戶(hù)請(qǐng)盡快安裝更新補(bǔ)丁以防止攻擊者利用該漏洞實(shí)施攻擊。

漏洞信息

MS.Outlook.CVE-2018-8587.Remote.Code.Execution

關(guān)于怎么對(duì)Microsoft Outlook漏洞的深入分析就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺(jué)得文章不錯(cuò)，可以把它分享出去讓更多的人看到。

本文標(biāo)題：怎么對(duì)MicrosoftOutlook漏洞的深入分析
本文地址：http://aaarwkj.com/article46/igojeg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供面包屑導(dǎo)航、微信小程序、服務(wù)器托管、搜索引擎優(yōu)化、移動(dòng)網(wǎng)站建設(shè)、外貿(mào)網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話(huà)：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)