如何通過查找惡意開發者的線索來尋找漏洞（中）
CVE-2015-2546
分類：一日漏洞;
基本描述：xxxSendMessage(tagPOPUPMENU)中的Use-After-Free;
零日漏洞供應商報告：FireEye;
在以下惡意軟件示例中發現：Ursnif，Buhtrap;
研究人員的利用樣本使用了一種不同于最初報告中描述的內存成形技術(內存成形技術)：噴涂Windows而不是AcceleratorTable。此外，研究人員最早和最基本的利用示例包含以下PDB路徑，這表明開發者已經知道此漏洞的CVE-ID:“C:\…\volodimir_8\c2\CVE-2015-2546_VS2012\x64\Release\CmdTest.pdb”。
CVE-2016-0040
分類：一日漏洞
基本描述：WMIDataDeviceIOControl中未初始化的內核指針;
零日漏洞供應商報告：沒有，因為研究人員從未在野外發現這個零日漏洞;
在以下惡意軟件示例中發現：Ursnif;
該漏洞已在一個樣本中被使用，該樣本還包含之前描述的CVE-2015-2546的漏洞。如果目標是比Windows8早的Windows版本，則會選擇此漏洞。否則，使用CVE-2015-2546。
CVE-2016-0167
分類：零日漏洞
基本描述：Win32k!xxxMNDestroyHandler中的Use-After-Free;
零日漏洞供應商報告：FireEye;
在以下惡意軟件示例中發現：PUNCHBUGGY;
研究人員的漏洞利用示例與有關野外漏洞利用的技術報告完全吻合。
CVE-2016-0165
分類：一日漏洞;
基本描述：Win32k!xxxMNDestroyHandler中的Use-After-Free;
零日漏洞供應商報告：由卡巴斯基找到，但未公開發布任何報告;
在以下惡意軟件示例中發現：Ursnif;
CVE-2016-0165是一個典型的整數上溢漏洞，由于在 win32k!RGNMEMOBJ::vCreate 函數中分配內核池內存塊前沒有對計算的內存塊大小參數進行溢出校驗，導致函數有分配到遠小于所期望大小的內存塊的可能性。而函數本身并未對分配的內存塊大小進行必要的校驗，在后續通過該內存塊作為緩沖區存儲數據時，將會觸發緩沖區溢出訪問的OOB問題，嚴重情況將導致系統BSOD的發生。這是一個有趣的示例，研究人員的攻擊者的零日漏洞(CVE-2016-0167)已于2016年4月由微軟修復。同一修復程序也修復了CVE-2016-0165，該漏洞也在野外被使用。為了尋找新的漏洞加以利用，研究人員的攻擊者可能對微軟的修復程序進行了修復程序修復，并發現了一個他們認為是零日漏洞修復的漏洞。此漏洞源于其先前漏洞：Win32k!xxxMNDestroyHandler中使用的修復函數。
從他們的漏洞利用示例中有多個跡象表明，漏洞利用者或者至少他們的客戶確定他們已出售了針對CVE-2016-0165的漏洞。
如在Cutter所示的那樣，調試字符串表示了CVE-2016-0165的混亂迭代
造成這種混亂的原因可能是微軟發布了解決多個漏洞的單個修復程序，并且它們是唯一在每個代碼修復程序與為此發布的CVE之間具有完整映射的修復程序。
CVE-2016-7255
分類：零日漏洞;
基本描述：NtUserSetWindowLongPtr中的內存損壞;
零日漏洞供應商報告：由Google報告，由趨勢科技提供技術報告;
在以下惡意軟件示例中發現：來自APT28(又名FancyBear，Sednit)，后來被Ursnif，Dreambot，GandCrab，Cerber，Maze使用;
研究人員的漏洞利用示例與有關野外漏洞利用的技術報告完全吻合，后來，這種勒索軟件被不同的勒索軟件攻擊者廣泛使用。此外，研究人員還看到了針對此特定漏洞的其他攻擊，它們也以一日漏洞的價格出售給其他勒索軟件攻擊者。
有多種間接證據表明，這一零日漏洞是BuggiCorp在2016年5月發布到exploit[.]的著名廣告中提到的那一天。
CVE-2017-0001
分類：一日漏洞;
基本描述：RemoveFontResourceExW中的Use-After-Free;
零日漏洞供應商報告：沒有，因為研究者從未在野外發現這個零日漏洞;
在以下惡意軟件示例中找到：來自Turla，后來被Ursnif使用;
來自于Turla(FireEye)的操作中被用作一日漏洞。
CVE-2017-0263
分類：零日漏洞;
基本說明：win32k!xxxDestroyWindow中的Use-After-Free;
零日漏洞供應商報告：ESET;
在以下惡意軟件示例中發現：來自于APT28(又名FancyBear,Sednit);
研究人員的漏洞利用示例與有關野外漏洞利用的技術報告完全吻合。
CVE-2018-8641
分類：一日漏洞;
基本描述：win32k!xxxTrackPopupMenuEx中的DoubleFree，doublefree的原理其實和堆溢出的原理差不多，都是通過unlink這個雙向鏈表刪除的宏來利用的。只是doublefree需要由自己來偽造整個chunk并且欺騙操作系統。
零日漏洞供應商報告：沒有，研究人員從未在野外被視為零日漏洞;
在以下惡意軟件示例中發現：Magniber;
識別使用過的一日漏洞通常比識別零日漏洞困難，這次，研究人員找不到任何可能暗示該攻擊者認為他們正在利用的漏洞是什么的示例。
研究人員確定此特定漏洞是由微軟在2018年12月修復的，在掃描了此修復程序中解決的漏洞列表之后，研究人員可以確定微軟將其標記為CVE-2018-8641，但具體原因研究人員并不是很清楚。
2020年6月24日，卡巴斯基在其博客中發布了通過Magnitude漏洞利用工具包傳播的漏洞利用分析。卡巴斯基在他們的博客文章中分析了Magniber使用的LPE漏洞，并認為其來自于Volodya，并估計可能是CVE-2018-8641。
CVE-2019-0859
分類：零日漏洞;
基本描述：CreateWindowEx中的Use-After-Free;
零日漏洞供應商報告：卡巴斯基;
在以下惡意軟件示例中找到：用作要注入或加載的獨立組件，研究人員無法將其歸類到任何特定的APT/惡意軟件。
研究人員的漏洞利用示例與有關野外漏洞利用的技術報告完全吻合，這個研究始于在客戶網絡中發現的這種漏洞利用的單個示例。在稍后發現的其中一個示例中，研究人員可以看到以下清晰的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指針的引用;
零日漏洞供應商報告：ESET;
在以下惡意軟件示例中找到：來自于Buhtrap;
研究人員有多個理由認為這是Volodya研發的另一個零日漏洞，因為報告中的多個技術細節與他們的典型漏洞利用方法相符。此外，該漏洞報告在其中嵌入了以下PDB路徑：“C：\work\volodimir_65\…pdb”。但是，這是研究人員列表中唯一尚未找到示例的漏洞利用程序，因此研究人員還無法對該漏洞利用方式進行歸類。
CVE-2019-1458
分類：一日漏洞;
基本描述：窗口切換中的內存損壞;
零日漏洞供應商報告：卡巴斯基(初始報告，詳細報告);
在以下惡意軟件示例中找到：來自于WizardOpium;
研究人員的漏洞利用方法與有關野外漏洞利用的技術報告不符。此外，卡巴斯基在詳細報告中指出：“有趣的是，在修復程序發布僅一周后，研究人員又發現了該漏洞的另一個一日漏洞，這表明利用此漏洞非常簡單。”實際上，研究人員的示例可追溯到卡巴斯基初次報告后的6天。
下表總結了研究人員列出的漏洞：
現在，研究人員發現了來自Volodya的10多種不同的攻擊，研究人員可以對其進行更詳細的審查，并熟悉攻擊者的運行習慣。從一開始就很清楚，研究人員要分析的攻擊程序可能有一個簡單的模板，它們為不同的攻擊部署了這個模板，因為每個攻擊的函數流，甚至不同函數的順序，在大多數攻擊之間是共享的。
在本節中，研究人員描述了一組關鍵特征，這些特征反映了Volodya在創建利用模板時所做出的不同實現選擇。研究人員將它們的實現與另一個稱為PlayBit的漏洞編寫器的實現進行比較。通過這種比較，研究人員的目的是概述在開發的每個部分中出現的各種實現選項，使每個開發者的一組實現選擇成為他們思考和工作方式的獨特“標志”。
PlayBit(又名luxor2008)
使用研究人員用來尋找Volodya漏洞的相同技術，研究人員設法找到了5個由PlayBit編寫的WindowsLPE1-Day漏洞，以及開發者多年來銷售的其他工具。研究人員從一個由REvil勒索軟件使用的CVE-2018-8453示例開始，并使用PlayBits的獨特線索尋找到了更多漏洞。
研究人員發現以下WindowsLPE漏洞被惡意軟件開發者開發為一日漏洞：
- CVE-2013-3660;
- CVE-2015-0057;
- CVE-2015-1701;
- CVE-2016-7255(這是Volodya開發的一個零日漏洞);
- CVE-2018-8453;
從技術上講，PlayBit還出售了針對CVE-2019-1069(一個SandboxEscaper漏洞)和CVE-2020-0787的兩個漏洞。但是，研究人員忽略這些漏洞，因為它們不是內存損壞漏洞，而是不同服務中的漏洞，因此具有不同的結構。
- boolelevate（inttarget_pid）
Volodya的所有利用示例中的API始終相同。無論該漏洞是嵌入在惡意軟件示例中還是獨立的POC，該漏洞利用都具有以下簽名的單個API函數：
- boolelevate（inttarget_pid）
調用elevate(target_pid)函數，可以在Cutter中看到
這個漏洞本身并不包括任何將shell代碼注入到另一個進程或任何類似的函數，它將系統特權授予所需的進程，只使用它的PID作為參數。
Sleep(200)
在惡意軟件調用elevate()函數后，它要做的第一件事就是在200毫秒的固定時間內進入Sleep()。
通過調用Sleep(200)啟動漏洞利用程序，可以在Cutter中看到
現在還不完全清楚為什么Sleep(200)會出現在攻擊模板中，研究人員懷疑這是為了避免不必要的不穩定，特別是因為這些利用大部分是基于時間(UAF,races)。因此，稍等片刻以使與I/O和內存訪問相關的活動結束，可以提高穩定性。由于該漏洞利用程序是惡意軟件的一部分，因此在執行漏洞利用程序之前，所有與惡意軟件相關的代碼都會導致CPU/disk/RAM短暫升高，因此在繼續進行實際漏洞利用之前讓情況有所緩解可能是有意義的。對于短期峰值載荷(在啟動新進程，從磁盤讀取/寫入文件等時自然會發生)，，等待200ms就足夠了。
盡管研究人員在最近的示例中注意到了這種模式的變化，但仍可以在研究人員發現的9種利用中找到該函數。
與PlayBit的比較：PlayBit在其利用中沒有任何此類函數。
操作系統線索識別
該漏洞利用程序從其美睡眠中醒來后，便會立即識別并校準目標Windows的版本，以便為盡可能多的操作系統版本提供支持。從研究人員的示例中，開發者使用了兩種技術來查詢操作系統：
解析ntdll.dll的標頭
這是最常用的技術，ntdll.dll中的句柄用于查找IMAGE_NT_HEADERS中的偏移量，從該偏移量中可以解析MajorOperatingSystemVersion和MinorOperatingSystemVersion字段。
GetVersionEx()
該技術通常與以前的技術一起使用，并且僅在2016年至2017年初的示例中使用。這可能是由于該API現在已過時。
調用GetVersionExW()來獲得Windows的版本，如在Cutter中所示
這兩種技術的目的都是要查詢操作系統的主要版本和次要版本，并相應地配置漏洞利用程序的全局變量。
盡管大多數漏洞利用程序都支持廣泛的Windows版本，但Volodya似乎從不關心目標的特定ServicePack，也不必關心它是否是Windows服務器。除了對僅用于CVE-2019-1458的漏洞的特定Windows10構建版本感興趣之外，研究人員追蹤的攻擊者僅使用主要版本和次要版本，僅此而已。
與PlayBit的比較：再次使用GetVersionEx()，通常稍后在過程環境塊(PEB)本身中附加解析主要和次要號碼，如圖7所示。ntdll.dll，PlayBit還會從GetVersionEx()輸出中提取其他信息，例如計算機的ServicePack，甚至檢查目標計算機是否使用服務器操作系統。
從PEB中提取主要版本和次要版本，如Cutter所示
這是兩個攻擊者在作案手法上的明顯區別，它們不僅以不同的方式提取相同的信息，而且Volodya對信息的興趣遠不如PlayBit，即使它們都利用相同的漏洞(CVE-2016-7255)。
通常，兩個攻擊者都擁有詳細的特定于版本的配置，一旦確定了操作系統版本，它們就會從中加載相關信息。兩者之間的主要區別在于，Volodya漏洞利用程序中的代碼流很少依賴于操作系統版本，而PlayBit則使用多種依賴于操作系統版本的if-check來融合多種轉換。反過來，這會影響他們對確切版本詳細信息的不同興趣。
本文翻譯自：https://research.checkpoint.com/2020/graphology-of-an-exploit-volodya/
