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/
