接上文《如何通過查找惡意開發(fā)者的線索來尋找漏洞(上)》

[[350294]]

CVE-2015-2546

分類：一日漏洞;

基本描述：xxxSendMessage(tagPOPUPMENU)中的Use-After-Free;

零日漏洞供應(yīng)商報告：FireEye;

在以下惡意軟件示例中發(fā)現(xiàn)：Ursnif，Buhtrap;

研究人員的利用樣本使用了一種不同于最初報告中描述的內(nèi)存成形技術(shù)(內(nèi)存成形技術(shù))：噴涂Windows而不是AcceleratorTable。此外，研究人員最早和最基本的利用示例包含以下PDB路徑，這表明開發(fā)者已經(jīng)知道此漏洞的CVE-ID:“C:\…\volodimir_8\c2\CVE-2015-2546_VS2012\x64\Release\CmdTest.pdb”。

CVE-2016-0040

分類：一日漏洞

基本描述：WMIDataDeviceIOControl中未初始化的內(nèi)核指針;

零日漏洞供應(yīng)商報告：沒有，因為研究人員從未在野外發(fā)現(xiàn)這個零日漏洞;

在以下惡意軟件示例中發(fā)現(xiàn)：Ursnif;

該漏洞已在一個樣本中被使用，該樣本還包含之前描述的CVE-2015-2546的漏洞。如果目標(biāo)是比Windows8早的Windows版本，則會選擇此漏洞。否則，使用CVE-2015-2546。

CVE-2016-0167

分類：零日漏洞

基本描述：Win32k!xxxMNDestroyHandler中的Use-After-Free;

零日漏洞供應(yīng)商報告：FireEye;

在以下惡意軟件示例中發(fā)現(xiàn)：PUNCHBUGGY;

研究人員的漏洞利用示例與有關(guān)野外漏洞利用的技術(shù)報告完全吻合。

CVE-2016-0165

分類：一日漏洞;

基本描述：Win32k!xxxMNDestroyHandler中的Use-After-Free;

零日漏洞供應(yīng)商報告：由卡巴斯基找到，但未公開發(fā)布任何報告;

在以下惡意軟件示例中發(fā)現(xiàn)：Ursnif;

CVE-2016-0165是一個典型的整數(shù)上溢漏洞，由于在 win32k!RGNMEMOBJ::vCreate 函數(shù)中分配內(nèi)核池內(nèi)存塊前沒有對計算的內(nèi)存塊大小參數(shù)進(jìn)行溢出校驗，導(dǎo)致函數(shù)有分配到遠(yuǎn)小于所期望大小的內(nèi)存塊的可能性。而函數(shù)本身并未對分配的內(nèi)存塊大小進(jìn)行必要的校驗，在后續(xù)通過該內(nèi)存塊作為緩沖區(qū)存儲數(shù)據(jù)時，將會觸發(fā)緩沖區(qū)溢出訪問的OOB問題，嚴(yán)重情況將導(dǎo)致系統(tǒng)BSOD的發(fā)生。這是一個有趣的示例，研究人員的攻擊者的零日漏洞(CVE-2016-0167)已于2016年4月由微軟修復(fù)。同一修復(fù)程序也修復(fù)了CVE-2016-0165，該漏洞也在野外被使用。為了尋找新的漏洞加以利用，研究人員的攻擊者可能對微軟的修復(fù)程序進(jìn)行了修復(fù)程序修復(fù)，并發(fā)現(xiàn)了一個他們認(rèn)為是零日漏洞修復(fù)的漏洞。此漏洞源于其先前漏洞：Win32k!xxxMNDestroyHandler中使用的修復(fù)函數(shù)。

從他們的漏洞利用示例中有多個跡象表明，漏洞利用者或者至少他們的客戶確定他們已出售了針對CVE-2016-0165的漏洞。

如在Cutter所示的那樣，調(diào)試字符串表示了CVE-2016-0165的混亂迭代

造成這種混亂的原因可能是微軟發(fā)布了解決多個漏洞的單個修復(fù)程序，并且它們是唯一在每個代碼修復(fù)程序與為此發(fā)布的CVE之間具有完整映射的修復(fù)程序。

CVE-2016-7255

分類：零日漏洞;

基本描述：NtUserSetWindowLongPtr中的內(nèi)存損壞;

零日漏洞供應(yīng)商報告：由Google報告，由趨勢科技提供技術(shù)報告;

在以下惡意軟件示例中發(fā)現(xiàn)：來自APT28(又名FancyBear，Sednit)，后來被Ursnif，Dreambot，GandCrab，Cerber，Maze使用;

研究人員的漏洞利用示例與有關(guān)野外漏洞利用的技術(shù)報告完全吻合，后來，這種勒索軟件被不同的勒索軟件攻擊者廣泛使用。此外，研究人員還看到了針對此特定漏洞的其他攻擊，它們也以一日漏洞的價格出售給其他勒索軟件攻擊者。

有多種間接證據(jù)表明，這一零日漏洞是BuggiCorp在2016年5月發(fā)布到exploit[.]的著名廣告中提到的那一天。

CVE-2017-0001

分類：一日漏洞;

基本描述：RemoveFontResourceExW中的Use-After-Free;

零日漏洞供應(yīng)商報告：沒有，因為研究者從未在野外發(fā)現(xiàn)這個零日漏洞;

在以下惡意軟件示例中找到：來自Turla，后來被Ursnif使用;

來自于Turla(FireEye)的操作中被用作一日漏洞。

CVE-2017-0263

分類：零日漏洞;

基本說明：win32k!xxxDestroyWindow中的Use-After-Free;

零日漏洞供應(yīng)商報告：ESET;

在以下惡意軟件示例中發(fā)現(xiàn)：來自于APT28(又名FancyBear,Sednit);

研究人員的漏洞利用示例與有關(guān)野外漏洞利用的技術(shù)報告完全吻合。

CVE-2018-8641

分類：一日漏洞;

基本描述：win32k!xxxTrackPopupMenuEx中的DoubleFree，doublefree的原理其實和堆溢出的原理差不多，都是通過unlink這個雙向鏈表刪除的宏來利用的。只是doublefree需要由自己來偽造整個chunk并且欺騙操作系統(tǒng)。

零日漏洞供應(yīng)商報告：沒有，研究人員從未在野外被視為零日漏洞;

在以下惡意軟件示例中發(fā)現(xiàn)：Magniber;

識別使用過的一日漏洞通常比識別零日漏洞困難，這次，研究人員找不到任何可能暗示該攻擊者認(rèn)為他們正在利用的漏洞是什么的示例。

研究人員確定此特定漏洞是由微軟在2018年12月修復(fù)的，在掃描了此修復(fù)程序中解決的漏洞列表之后，研究人員可以確定微軟將其標(biāo)記為CVE-2018-8641，但具體原因研究人員并不是很清楚。

2020年6月24日，卡巴斯基在其博客中發(fā)布了通過Magnitude漏洞利用工具包傳播的漏洞利用分析?？ò退够谒麄兊牟┛臀恼轮蟹治隽薓agniber使用的LPE漏洞，并認(rèn)為其來自于Volodya，并估計可能是CVE-2018-8641。

CVE-2019-0859

分類：零日漏洞;

基本描述：CreateWindowEx中的Use-After-Free;

零日漏洞供應(yīng)商報告：卡巴斯基;

在以下惡意軟件示例中找到：用作要注入或加載的獨(dú)立組件，研究人員無法將其歸類到任何特定的APT/惡意軟件。

研究人員的漏洞利用示例與有關(guān)野外漏洞利用的技術(shù)報告完全吻合，這個研究始于在客戶網(wǎng)絡(luò)中發(fā)現(xiàn)的這種漏洞利用的單個示例。在稍后發(fā)現(xiàn)的其中一個示例中，研究人員可以看到以下清晰的PDB字符串：“X:\tools\0day\09-08-2018\x64\Release\RunPS”，與研究人員初始示例中的pdb字符串相反：“S：\Work\Inject\cve-2019-0859\Release\CmdTest.pdb”。

CVE-2019-1132

分類：零日漏洞;

基本說明：在win32k!xxxMNOpenHierarchy(tagPOPUPMENU)處取消對NULL指針的引用;

零日漏洞供應(yīng)商報告：ESET;

在以下惡意軟件示例中找到：來自于Buhtrap;

研究人員有多個理由認(rèn)為這是Volodya研發(fā)的另一個零日漏洞，因為報告中的多個技術(shù)細(xì)節(jié)與他們的典型漏洞利用方法相符。此外，該漏洞報告在其中嵌入了以下PDB路徑：“C：\work\volodimir_65\…pdb”。但是，這是研究人員列表中唯一尚未找到示例的漏洞利用程序，因此研究人員還無法對該漏洞利用方式進(jìn)行歸類。

CVE-2019-1458

分類：一日漏洞;

基本描述：窗口切換中的內(nèi)存損壞;

零日漏洞供應(yīng)商報告：卡巴斯基(初始報告，詳細(xì)報告);

在以下惡意軟件示例中找到：來自于WizardOpium;

研究人員的漏洞利用方法與有關(guān)野外漏洞利用的技術(shù)報告不符。此外，卡巴斯基在詳細(xì)報告中指出：“有趣的是，在修復(fù)程序發(fā)布僅一周后，研究人員又發(fā)現(xiàn)了該漏洞的另一個一日漏洞，這表明利用此漏洞非常簡單。”實際上，研究人員的示例可追溯到卡巴斯基初次報告后的6天。

下表總結(jié)了研究人員列出的漏洞：

 

 

 

 

 

開發(fā)者留下的線索

 

現(xiàn)在，研究人員發(fā)現(xiàn)了來自Volodya的10多種不同的攻擊，研究人員可以對其進(jìn)行更詳細(xì)的審查，并熟悉攻擊者的運(yùn)行習(xí)慣。從一開始就很清楚，研究人員要分析的攻擊程序可能有一個簡單的模板，它們?yōu)椴煌墓舨渴鹆诉@個模板，因為每個攻擊的函數(shù)流，甚至不同函數(shù)的順序，在大多數(shù)攻擊之間是共享的。

在本節(jié)中，研究人員描述了一組關(guān)鍵特征，這些特征反映了Volodya在創(chuàng)建利用模板時所做出的不同實現(xiàn)選擇。研究人員將它們的實現(xiàn)與另一個稱為PlayBit的漏洞編寫器的實現(xiàn)進(jìn)行比較。通過這種比較，研究人員的目的是概述在開發(fā)的每個部分中出現(xiàn)的各種實現(xiàn)選項，使每個開發(fā)者的一組實現(xiàn)選擇成為他們思考和工作方式的獨(dú)特“標(biāo)志”。

PlayBit(又名luxor2008)

使用研究人員用來尋找Volodya漏洞的相同技術(shù)，研究人員設(shè)法找到了5個由PlayBit編寫的WindowsLPE1-Day漏洞，以及開發(fā)者多年來銷售的其他工具。研究人員從一個由REvil勒索軟件使用的CVE-2018-8453示例開始，并使用PlayBits的獨(dú)特線索尋找到了更多漏洞。

研究人員發(fā)現(xiàn)以下WindowsLPE漏洞被惡意軟件開發(fā)者開發(fā)為一日漏洞：

• CVE-2013-3660;
• CVE-2015-0057;
• CVE-2015-1701;
• CVE-2016-7255(這是Volodya開發(fā)的一個零日漏洞);
• CVE-2018-8453;

從技術(shù)上講，PlayBit還出售了針對CVE-2019-1069(一個SandboxEscaper漏洞)和CVE-2020-0787的兩個漏洞。但是，研究人員忽略這些漏洞，因為它們不是內(nèi)存損壞漏洞，而是不同服務(wù)中的漏洞，因此具有不同的結(jié)構(gòu)。

boolelevate（inttarget_pid） 

Volodya的所有利用示例中的API始終相同。無論該漏洞是嵌入在惡意軟件示例中還是獨(dú)立的POC，該漏洞利用都具有以下簽名的單個API函數(shù)：

boolelevate（inttarget_pid） 

調(diào)用elevate(target_pid)函數(shù)，可以在Cutter中看到

這個漏洞本身并不包括任何將shell代碼注入到另一個進(jìn)程或任何類似的函數(shù)，它將系統(tǒng)特權(quán)授予所需的進(jìn)程，只使用它的PID作為參數(shù)。

Sleep(200)

在惡意軟件調(diào)用elevate()函數(shù)后，它要做的第一件事就是在200毫秒的固定時間內(nèi)進(jìn)入Sleep()。

通過調(diào)用Sleep(200)啟動漏洞利用程序，可以在Cutter中看到

現(xiàn)在還不完全清楚為什么Sleep(200)會出現(xiàn)在攻擊模板中，研究人員懷疑這是為了避免不必要的不穩(wěn)定，特別是因為這些利用大部分是基于時間(UAF,races)。因此，稍等片刻以使與I/O和內(nèi)存訪問相關(guān)的活動結(jié)束，可以提高穩(wěn)定性。由于該漏洞利用程序是惡意軟件的一部分，因此在執(zhí)行漏洞利用程序之前，所有與惡意軟件相關(guān)的代碼都會導(dǎo)致CPU/disk/RAM短暫升高，因此在繼續(xù)進(jìn)行實際漏洞利用之前讓情況有所緩解可能是有意義的。對于短期峰值載荷(在啟動新進(jìn)程，從磁盤讀取/寫入文件等時自然會發(fā)生)，，等待200ms就足夠了。

盡管研究人員在最近的示例中注意到了這種模式的變化，但仍可以在研究人員發(fā)現(xiàn)的9種利用中找到該函數(shù)。

與PlayBit的比較：PlayBit在其利用中沒有任何此類函數(shù)。

操作系統(tǒng)線索識別

該漏洞利用程序從其美睡眠中醒來后，便會立即識別并校準(zhǔn)目標(biāo)Windows的版本，以便為盡可能多的操作系統(tǒng)版本提供支持。從研究人員的示例中，開發(fā)者使用了兩種技術(shù)來查詢操作系統(tǒng)：

解析ntdll.dll的標(biāo)頭

這是最常用的技術(shù)，ntdll.dll中的句柄用于查找IMAGE_NT_HEADERS中的偏移量，從該偏移量中可以解析MajorOperatingSystemVersion和MinorOperatingSystemVersion字段。

GetVersionEx()

該技術(shù)通常與以前的技術(shù)一起使用，并且僅在2016年至2017年初的示例中使用。這可能是由于該API現(xiàn)在已過時。

調(diào)用GetVersionExW()來獲得Windows的版本，如在Cutter中所示

這兩種技術(shù)的目的都是要查詢操作系統(tǒng)的主要版本和次要版本，并相應(yīng)地配置漏洞利用程序的全局變量。

盡管大多數(shù)漏洞利用程序都支持廣泛的Windows版本，但Volodya似乎從不關(guān)心目標(biāo)的特定ServicePack，也不必關(guān)心它是否是Windows服務(wù)器。除了對僅用于CVE-2019-1458的漏洞的特定Windows10構(gòu)建版本感興趣之外，研究人員追蹤的攻擊者僅使用主要版本和次要版本，僅此而已。

與PlayBit的比較：再次使用GetVersionEx()，通常稍后在過程環(huán)境塊(PEB)本身中附加解析主要和次要號碼，如圖7所示。ntdll.dll，PlayBit還會從GetVersionEx()輸出中提取其他信息，例如計算機(jī)的ServicePack，甚至檢查目標(biāo)計算機(jī)是否使用服務(wù)器操作系統(tǒng)。

從PEB中提取主要版本和次要版本，如Cutter所示

這是兩個攻擊者在作案手法上的明顯區(qū)別，它們不僅以不同的方式提取相同的信息，而且Volodya對信息的興趣遠(yuǎn)不如PlayBit，即使它們都利用相同的漏洞(CVE-2016-7255)。

通常，兩個攻擊者都擁有詳細(xì)的特定于版本的配置，一旦確定了操作系統(tǒng)版本，它們就會從中加載相關(guān)信息。兩者之間的主要區(qū)別在于，Volodya漏洞利用程序中的代碼流很少依賴于操作系統(tǒng)版本，而PlayBit則使用多種依賴于操作系統(tǒng)版本的if-check來融合多種轉(zhuǎn)換。反過來，這會影響他們對確切版本詳細(xì)信息的不同興趣。

本文翻譯自：https://research.checkpoint.com/2020/graphology-of-an-exploit-volodya/