上接《如何通过查找恶意开发者的线索来寻找漏洞(上)》CVE-2015-2546类别：一日漏洞；基本描述：xxxSendMessage(tagPOPUPMENU)中的Use-After-Free；每日零漏洞供应商报告：FireEye；在以下恶意软件样本中发现：Ursnif、Buhtrap；研究人员的漏洞利用样本使用了与原始报告中描述的不同的内存整形技术（MemoryShapingTechnique）：SprayingWindowsinsteadofAcceleratorTable。此外，研究人员最早和最基本的利用示例包含以下PDB路径，这表明开发人员已经知道此漏洞的CVE-ID：“C:\…\volodimir_8\c2\CVE-2015-2546_VS2012\x64\Release\命令测试.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，它也在野外被利用。为了寻找可利用的新漏洞，研究人员的攻击者可能已经修补了Microsoft的修复程序并发现了一个他们认为是零日修复程序的漏洞。该漏洞源于其上一个漏洞中使用的修复函数：Win32k!xxxMNDestroyHandler。从他们的漏洞利用示例中可以看出，漏洞利用者或至少他们的客户确信他们出售了针对CVE-2016-0165的漏洞利用。如Cutter中所示，调试字符串指示CVE-2016-0165的一个令人困惑的迭代。造成这种混淆的原因可能是Microsoft发布了解决多个漏洞的单个修复程序，并且它们是每个代码修复程序中唯一的一个。在程序和为其发布的CVE之间具有完整映射的修复程序。CVE-2016-7255分类：零日漏洞；基本描述：NtUserSetWindowLongPtr内存损坏；零日漏洞供应商报告：谷歌报告，趋势科技技术报告；在以下恶意软件样本中发现：来自APT28（还有FancyBear、Sednit），后来被Ursnif、Dreambot、GandCrab、Cerber、Maze使用；研究人员的漏洞利用示例与有关野外漏洞利用的技术报告非常吻合，后来，该勒索软件被不同的勒索软件攻击者广泛使用。此外，研究人员还发现了针对此特定漏洞的其他攻击，这些漏洞也以一日利用的价格出售给其他勒索软件攻击者。有多个间接证据表明，BuggiCorp在2016年5月发布了著名的利用[.]的漏洞利用日。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分类：一日漏洞；基本描述：窗口切换内存损坏；零日漏洞供应商报告：Kaspersky（初始报告、详细报告）；在以下恶意软件样本中发现：来自WizardOpium；研究人员的漏洞利用方法与野外漏洞利用技术报告不符。此外，卡巴斯基在详细报告中指出：“有趣的是，仅在修复发布一周后，研究人员就发现了该漏洞的另一个一日利用程序，这表明利用该漏洞非常简单。”事实上，研究人员样本可追溯到卡巴斯基首次报告后的6天。下表总结了研究人员列出的漏洞：开发人员留下的线索现在，研究人员已经发现了10多种来自Volodya的不同攻击，研究人员可以更详细地审查这些攻击，并熟悉攻击者的操作习惯。从一开始就很清楚，研究人员正在分析的攻击程序可能有一个他们为不同攻击部署的简单模板，因为每次攻击的函数流，甚至不同函数的顺序，在大多数攻击之间都是不同的。房间是共用的。在本节中，研究人员描述了一组关键特性，这些特性反映了Volodya在创建漏洞利用模板时做出的不同实施选择。研究人员将他们的实现与另一个名为PlayBit的漏洞编写器的实现进行了比较。通过这种比较，研究人员旨在概述在开发的每个部分出现的各种实施选项，使每个开发人员的实施选择集成为他们思考和工作方式的独特“签名”。PlayBit（又名luxor2008）研究人员使用与发现Volodya漏洞利用相同的技术，设法找到了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)API在Volodya的所有漏洞利用示例中始终相同。无论该漏洞是嵌入在恶意软件样本中还是独立的POC中，该漏洞利用具有具有以下签名的单个API函数：boolelevate(inttarget_pid)调用elevate(target_pid)函数，如Cutter中所示，漏洞本身确实如此notinclude任何将shellcode注入到另一个进程或任何类似的函数中的任何东西，这些函数将系统权限授予所需的进程，仅使用其PID作为参数。Sleep(200)恶意软件调用elevate()函数后，它做的第一件事是进入Sleep()，持续200毫秒的固定时间。该漏洞是通过调用Sleep(200)启动的，可以在Cutter中看到。目前还不完全清楚为什么Sleep(200)会出现在攻击模板中，研究人员怀疑这是为了避免不必要的不??稳定，特别是因为这些漏洞利用大多是基于时间的（UAF，竞赛）。因此，等待I/O和内存访问相关活动结束可以提高稳定性。由于漏洞利用是恶意软件的一部分，所有与恶意软件相关的代码都会在漏洞利用执行之前导致短暂的CPU/磁盘/RAM峰值，因此在继续实际利用之前让情况缓和可能是有意义的。对于短期峰值负载（在启动新进程、从磁盘读取/写入文件等时自然会出现），等待200ms就足够了。尽管研究人员在最近的示例中注意到这种模式发生了变化，但在研究人员发现的九个漏洞利用中仍然可以找到该功能。与PlayBit的比较：PlayBit在其exploit中没有任何这样的功能。操作系统线索识别一旦漏洞从睡眠中醒来，它就会识别并校准目标Windows版本以支持尽可能多的操作系统版本。从研究人员的示例来看，开发人员使用了两种技术来查询操作系统：解析ntdll.dll的标头这是最常用的技术，ntdll.dll中的一个句柄用于查找IMAGE_NT_HEADERS中的偏移量，从MajorOperatingSystemVersion和可以在此偏移量中解析MinorOperatingSystemVersion字段。GetVersionEx()该技术经常与之前的技术一起使用，并且仅在2016年至2017年初的样本中使用。这可能是因为该API现在已过时。调用GetVersionExW()获取Windows的版本，如Cutter所示。这两种技术的目的都是查询操作系统的主要和次要版本，并相应地配置漏洞利用程序的全局变量。虽然大多数漏洞利用支持广泛的Windows版本，但Volodya似乎从不关心目标的特定服务包，也不关心它是否是Windows服务器。除了对仅用于CVE-2019-1458漏洞的特定Windows10版本感兴趣外，研究人员跟踪的攻击者仅使用主要和次要版本，仅此而已。与PlayBit比较：再次使用GetVersionEx()，通常后面会额外解析进程环境块(PEB)本身中的主次编号，如图7.ntdll.dll，PlayBit还从GetVersionEx()输出，例如计算机的ServicePack，甚至检查目标计算机是否使用服务器操作系统。从PEB中提取主要版本和次要版本，如Cutter所示这是两个攻击者在作案手法上的明显差异，他们不仅以不同的方式提取相同的信息，Volodya对信息的兴趣远不如PlayBit，甚至尽管他们都利用了相同的漏洞(CVE-2016-7255)。通常，两个攻击者都有详细的特定于版本的配置，一旦确定操作系统版本，他们就会从中加载相关信息。两者之间的主要区别在于，Volodya漏洞利用中的代码流很少依赖于操作系统版本，而PlayBit使用依赖于操作系统版本的多个if-checks来合并多个转换。反过来，这会影响他们对确切发布细节的不同兴趣。本文翻译自：https://research.checkpoint.com/2020/graphology-of-an-exploit-volodya/
