首页 >> 网络安全 >>漏洞分析 >> 漏洞利用图谱–通过查找作者的指纹来寻找漏洞利用
详细内容

漏洞利用图谱–通过查找作者的指纹来寻找漏洞利用

时间:2020-10-03     作者:伊泰·科金(Iyal Itkin),伊泰·科恩(Itay Cohen)【转载】   阅读

研究者:伊泰·科金(Iyal Itkin),伊泰·科恩(Itay Cohen)

在过去的几个月中,我们的漏洞和恶意软件研究团队共同努力,专注于恶意软件内部的漏洞利用,尤其是漏洞利用者本身。从一个事件响应案例开始,我们构建了Windows最活跃的漏洞利用开发人员之一的档案,称为“ Volodya ”或“ BuggiCorp ”。到目前为止,我们设法跟踪了他们Windows内核本地特权升级(LPE)漏洞中的10多个(!),其中许多漏洞在开发时为零天。

背景

就像所有好的故事一样,我们的故事始于事件响应案例。在分析针对我们的一个客户的复杂攻击时,我们注意到该恶意软件执行了一个很小的64位可执行文件。该样本包含不寻常的调试字符串,这些调试字符串指向试图利用受害者计算机上的漏洞的尝试。更重要的是,样品具有哪些大声宣告,并清除该二进制文件的目标吃剩的PDB路径:...\cve-2019-0859\x64\Release\CmdTest.pdb由于没有CVE-2019-0859的此实现的任何在线资源,我们意识到,我们并不是在寻找可公开使用的PoC,而是在寻找真实的开发工具。这激发了我们进行更深入的挖掘。

对漏洞进行逆向工程非常简单。二进制文件很小,并且调试消息在那里指导我们。它利用了“售后使用”(UAF)漏洞CreateWindowEx来获取对父进程的更高特权。我们很快做出了一个有趣的观察:漏洞利用程序和恶意软件本身似乎不是同一个人编写的。代码质量,缺乏混淆,PDB和时间戳都表明了这一结论。

图1:对的调用CreateWindowEx,如Cutter所示。

漏洞分布101

我们倾向于将特定恶意软件家族背后的人们视为一个完整的单元。可以想象,每个组件都是由一个人,团队或团队编写的。事实是,由民族国家或罪犯编写先进的恶意软件,涉及具有不同技能的不同人群。一个民族国家的网络间谍组织可能在不同的团体和分支机构拥有数百甚至数千名员工。组织中的每个工人都有特定的角色,并经过特殊的技术培训和多年的专业知识进行了微调。在这样的组织中,编写通用组件的工作量在专业团队之间分解,由不同的团队负责初始访问,收集敏感数据,横向移动等。

目标是在其恶意软件中嵌入漏洞利用模块的运营实体不能仅依靠恶意软件开发人员。找到漏洞并可靠地利用漏洞,最有可能由专门从事特定角色的特定团队或个人完成。就其本身而言,恶意软件开发人员并不真正在乎其幕后工作方式,他们只想集成此模块并完成此工作即可。

为了使工作分工,两个团队都需要就一些API达成共识,这将成为不同组件之间的桥梁。这种集成API并不是国家行为者独有的,而是漏洞利用的“自由市场”中的常见功能。无论是涉及地下论坛,漏洞利用经纪人,还是令人讨厌的网络公司,它们都向客户提供有关如何将漏洞利用方法集成到其恶意软件中的说明。

从本质上讲,这个集成点是我们要在研究中重点关注的关键方面。假设利用漏洞的作者独立工作,并且仅将其代码/二进制模块分发给恶意软件作者,我们决定专注于他们进行更改。通过分析嵌入在恶意软件样本中的漏洞利用程序,我们可以了解有关漏洞利用程序作者的更多信息,并希望通过在将其产品分发给编写恶意软件的同行时研究他们的编码习惯和其他留下来作为其身份线索的指纹来进行区分。

指纹利用开发人员

我们不打算关注整个恶意软件,而是寻找恶意软件家族或参与者的新样本,而是希望提供另一种观点,并决定专注于由漏洞利用开发人员编写的这几个功能。从事件响应案例中获得这个小的64位二进制文件看起来是一个有希望的开端。

该二进制文件除了利用CVE-2019-0859之外没有做任何其他事情,并且不基于公开共享的源代码或POC。由于可执行文件是由漏洞利用作者以外的其他人编写的代码精炼而成,因此它非常适合我们进行指纹识别。此外,可执行文件与臭名昭著的犯罪软件恶意软件的主要二进制文件是分开的,这使我们相信,这种利用不是恶意软件开发人员内部开发的。带着这种希望,我们开始寻找更多由同一作者编写的漏洞利用程序。

我们首先从已经拥有的二进制文件中收集简单的工件:字符串,内部文件名,时间戳和PDB路径。第一个结果立即出现-一个与64位示例完全匹配的32位可执行文件。具体来说,如它们的时间戳和嵌入式PDB路径所示,它们是同时,从相同的源代码编译在一起的。现在我们有了这两个样本,我们能够制定我们应该寻找的东西。

为了对这一漏洞的作者进行指纹识别,我们将目光投向了以下方面:

  • 二进制文件中的独特工件

    • 硬编码值(加密常数,“垃圾”值,例如0x11223344)

    • 数据表(通常是特定于版本的配置)

    • 字符串(GDI对象名称:“ MyWindow”,“ MyClass_56”,“ findme1”等)

    • PDB路径

  • 代码段

    • 漏洞利用的流程

    • 代码的结构及其中的功能

    • 特定于版本的配置:

    • 提供给客户的API

    • 选项1:主要漏洞利用流程几乎没有分支

    • 选项#2:针对不同版本的OS的多个扭曲和旋钮

    • 模块化:功能分离

    • 结构:分离以清除阶段(初始化,配置,喷涂,令牌交换等)

    • 全局变量:哪些信息存储在全局变量中?(操作系统版本?操作系统版本枚举?只是特定的字段偏移量?)

    • 字段偏移量:哪些字段特别重要?

    • 首选系统调用:首选系统调用

    • 优选的泄漏技术(HMValidateHandlegSharedInfo等)

    • 首选提升技术(如何执行代币替换?)

    • 堆喷涂技术(使用AcceleratorTables?Windows?Bitmaps?)

    • Syscall包装器

    • 内联组装

    • 专有加密功能/实现

    • 独特的功能实现

    • 技术和习惯

    • 构架

图2:我们将寻找的与利用漏洞相关的工件集。

考虑到这些属性,我们回顾了我们拥有的两个样本,并标记了一些我们认为独特的工件。即使我们只有两个小的二进制文件(本质上是相同的),我们仍然能够创建搜寻规则来查找该开发人员编写的更多示例。令我们惊讶的是,我们能够找到比想象中更多的东西。

一个接一个的出现了几十个样本,并且每个样本都改进了我们的狩猎规则和方法。通过对样本的仔细分析,我们能够了解哪些样本利用了哪个CVE,并以此为基础创建了时间表,以了解该漏洞是在暴露之前写为0天,还是1天基于补丁扩散和类似技术实现的。

到目前为止,仅基于我们的指纹识别技术,而没有进一步的情报,我们就可以将10多个CVE归因于同一个漏洞利用开发人员。后来,公开报道透露了我们的目标漏洞利用销售者的名称:Volodya(又名Volodimir),以前称为BuggiCorp似乎我们不是唯一的跟踪此漏洞的卖家,卡巴斯基报道关于他们的一些相关信息的几个场合此外,ESET在其VB2019关于Buhtrap的演讲中还提到了Volodya的一些重要线索。

根据卡巴斯基的说法,Volodya最初以其“ BuggiCorp”绰号成为头条新闻,当时他们  在臭名昭著的Exploit [。]网络犯罪论坛上宣传了Windows 0天的待售广告,起价为95,000美元。多年来,价格上涨,他们的某些Windows LPE 0天漏洞利用软件的售价高达20万美元。正如卡巴斯基报告中所发表的,后来得到我们的确认,Volodya将漏洞利用软件卖给了犯罪软件和APT团体。我们将在“客户”一章中详细讨论演员的客户。

演员的功绩

尽管我们的一些最初的狩猎规则需要进行一些微调,但即使是立即收到的结果,我们也感到非常惊讶。经过进一步的校准后,我们设法找到了许多示例,所有示例都是Windows中的本地特权升级(LPE)漏洞。在这些样本中,我们能够确定演员所利用的以下CVE列表。

边注:

在对漏洞进行分类期间,我们在确定给定漏洞是作为0天还是1天利用时选择了保守的方法。如果其他安全供应商将狂放的漏洞归因于我们的演员,那么它就是0天。如果我们发现足够的证据表明我们的样本之一确实是在野外流通的漏洞利用程序,就像卖方在其报告中所描述的那样,那么我们也将其标记为此类。

在所有其他情况下,我们将该漏洞标记为被利用的1天,宁愿使用0天计数的下限,而不是错误地超过正确的数字。

CVE-2015-2546

分类: 1天
基本描述:xxxSendMessage(- tagPOPUPMENU)中的免费使用后
0天供应商报告:FireEye
在以下恶意软件样本中发现: Ursnif,Buhtrap

我们的漏洞利用示例使用了与初始报告中所述不同的内存整形技术:喷射Windows而不是Accelerator Tables。此外,我们最早也是最基本的利用示例包含以下PDB路径,这表明作者已经知道此漏洞的CVE-ID:“ C:\…\ volodimir_8 \ c2 \ CVE-2015-2546 _VS2012 \ x64 \ Release \ CmdTest .pdb”

CVE-2016-0040

分类: 1天
基本描述:WMIDataDevice IOControl
0天供应商报告中的未初始化内核指针:不适用
在以下恶意软件样本中从未被野外利用为0天 Ursnif

此漏洞利用已用于单个样本,该样本还包含先前描述的CVE-2015-2546漏洞。如果目标是Windows 8之前的Windows版本,则选择此漏洞利用。否则,将使用CVE-2015-2546。

CVE-2016-0167

分类: 0天
基本描述:Win32k!xxxMNDestroyHandler
0天供应商报告中免费使用后FireEye
在以下恶意软件样本中发现:PUNCHBUGGY

我们的漏洞利用示例与有关野生漏洞利用的技术报告完全吻合。

CVE-2016-0165 *

分类: 1天
基本描述:Win32k!xxxMNDestroyHandler
0天供应商报告中的免费使用后卡巴斯基找到,但未公开发布任何报告
在以下恶意软件样本中找到: Ursnif

这是一个有趣的案例。我们的演员的0天(CVE-2016-0167)已于2016年4月由Microsoft修补。同一补丁也修复了CVE-2016-0165,该漏洞也被广泛使用。为了寻找新的漏洞进行利用,我们的演员可能对Microsoft的修补程序进行了补丁修补,并发现了一个他们认为是0天修补的漏洞。此漏洞源自其先前漏洞:中使用的修补功能Win32k!xxxMNDestroyHandler

*我们从他们的漏洞利用示例中有多个迹象表明,漏洞利用者或者至少他们的客户确定他们已出售了针对CVE-2016-0165的漏洞。可悲的事实是,在分析了漏洞利用之后,我们可以说被利用的漏洞是一个不同的漏洞。

图3:调试字符串指示CVE-2016-0165周围的混乱,如Cutter所示。

造成这种混乱的原因可能是Microsoft发布了解决多个漏洞的单个修补程序,并且它们是唯一在每个代码修补程序与为此发布的CVE之间具有完整映射的修补程序。

CVE-2016-7255

分类: 0天
基本描述:内存损坏NtUserSetWindowLongPtr
0天供应商报告:报告者谷歌,通过技术报告趋势科技
下列恶意软件样本中发现:归因于APT28(又名花式熊,Sednit)。后来由Ursnif,Dreambot,GandCrab,Cerber,Maze使用

我们的漏洞利用示例与有关野生漏洞利用的技术报告完全吻合。后来,这种勒索软件被不同的勒索软件参与者广泛使用。此外,我们还看到了针对此特定漏洞的其他攻击,它们也以1天的价格出售给其他勒索软件参与者。

注意:我们有多种间接证据认为,这一0天是BuggiCorp在2016年5月发布到exploit [。]著名广告中提到的那一天

CVE-2017-0001

分类: 1天
基本描述:RemoveFontResourceExW
0天供应商报告中的免费使用后:不适用
在以下恶意软件样本中从未被用作野外零日攻击归因于Turla后来由Ursnif使用

在归因于Turla(FireEye)的操作中用作1天

CVE-2017-0263

分类: 0天
基本描述:win32k!xxxDestroyWindow
0天供应商报告中的免费使用后ESET
在以下恶意软件样本中发现:归因于APT28(又名Fancy Bear,Sednit)

我们的漏洞利用示例与有关野生漏洞利用的技术报告完全吻合。

CVE-2018-8641 *

分类: 1天
基本描述:win32k!xxxTrackPopupMenuEx
0天供应商报告中的双倍免费:不适用
在以下恶意软件样本中从未被野外利用为0天 Magniber

再一次,识别使用过的1天通常比识别0天困难。这次,我们找不到任何可能暗示参与者认为他们正在利用的漏洞是什么的示例。

*我们确定此特定漏洞是由Microsoft在2018年12月修补的。在扫描了此修补程序中解决的漏洞列表之后,我们可以确定Microsoft将其标记为CVE-2018-8641,但我们不知道当然。

更新: 2020年6月24日,卡巴斯基在其博客中发布了通过Magnitude漏洞利用工具包分发的漏洞利用分析。卡巴斯基在他们的博客文章中分析了Magniber使用的LPE漏洞,并将其归因于Volodya,并估计可能是CVE-2018-8641。代表卡巴斯基的这一独立结论加强了我们的初步估计。

CVE-2019-0859

分类: 0天
基本描述:CreateWindowEx
0天供应商报告中的免费使用后卡巴斯基
在以下恶意软件样本中发现:用作要注入或加载的独立组件。我们无法将其归因于任何特定的APT /恶意软件。

我们的漏洞利用示例与有关野生漏洞利用的技术报告完全吻合。我们的研究始于在客户网络中发现的这种漏洞利用的单个样本。在我们后来发现的样本之一,我们可以看到这清楚PDB字符串:“X:\工具\ 0天2018年9月8日\ 64 \发布\ RunPS.pdb”,在我们最初的反对到PDB串示例:“ S:\ Work \ Inject \ cve-2019-0859 \ Release \ CmdTest.pdb”。

CVE-2019-1132 *

分类: 0天
基本描述:在空指针引用win32k!xxxMNOpenHierarchytagPOPUPMENU
0天的供应商报告:ESET
以下恶意软件样品中发现:归因于Buhtrap

*我们有多个理由认为这是Volodya的另一次0天漏洞利用,因为报告中的多个技术细节与他们的典型漏洞利用方法相符。此外,该漏洞报告其中嵌入了以下PDB路径:“ C:\ work \ volodimir_65 \…pdb”。但是,这是我们列表中唯一尚未发现样本的漏洞利用程序,因此我们不能确定该漏洞利用方式的归属。

CVE-2019-1458

分类: 1天
基本描述:窗口切换中的内存损坏
0天供应商报告:Kaspersky(初始报告详细报告
在以下恶意软件样本中找到:归因于操作WizardOpium

我们的漏洞利用与关于野外漏洞利用的技术报告不一致。此外,卡巴斯基在详细报告中指出:“有趣的是,在补丁发布仅一周后,我们又发现了该漏洞的另一天1天利用漏洞,这表明利用此漏洞非常简单。” 实际上,我们的样本可追溯到卡巴斯基初次报告后的6天。

漏洞摘要

下表总结了我们列出的漏洞:

CVE

是0天?

CVE-2015-2546

没有

CVE-2016-0040

没有

CVE-2016-0165 *

没有

CVE-2016-0167

CVE-2016-7255

CVE-2017-0001

没有

CVE-2017-0263

CVE-2018-8641 *

没有

CVE-2019-0859

CVE-2019-1132 *

CVE-2019-1458

没有

总数

5uot of11

作者的指纹

现在,我们发现了来自Volodya的10多种不同的攻击,我们可以对其进行更详细的审查,并熟悉演员的工作习惯。从一开始我们就很清楚,我们的参与者可能有一个简单的模板,他们可以为不同的漏洞利用程序部署,因为每个漏洞利用程序的功能流程,甚至不同功能的顺序都在大多数漏洞利用程序之间共享。

在本节中,我们描述了一组关键特征,这些特征反映了Volodya在创建利用模板时所做出的不同实现选择。我们将它们的实现与昵称PlayBit的另一位漏洞利用编写者的实现进行比较通过这种比较,我们旨在概述漏洞利用各部分中存在的各种实现选项,从而使每个作者的实现选择集成为他们思维和工作方式的独特“签名”。

PlayBit(又名luxor2008)

使用我们用来搜寻Volodya漏洞的相同技术,我们设法追踪了PlayBit编写的5种Windows LPE 1-Day漏洞,以及作者多年来销售的其他工具。我们从一个由REvil勒索软件使用的CVE-2018-8453示例开始,并使用PlayBits的独特指纹来寻找更多漏洞。

我们发现以下Windows LPE漏洞由作者实施为1天:

  • CVE-2013-3660

  • CVE-2015-0057

  • CVE-2015-1701

  • CVE-2016-7255 –这是Volodya的0天

  • CVE-2018-8453

从技术上讲,PlayBit还出售了针对CVE-2019-1069(一个SandboxEscaper漏洞)和CVE-2020-0787的两个漏洞但是,我们忽略这些漏洞,因为它们不是内存损坏漏洞,而是不同服务中的漏洞,因此具有不同的结构。

注意:将在即将发布的博客文章中发布对PlayBit的更深入分析,以及他们开发和出售的各种漏洞。

布尔提升(int target_pid)

Volodya的所有利用示例中的API始终相同。无论该漏洞是嵌入在恶意软件样本中还是独立的POC,该漏洞利用都具有以下签名的单个API函数:

bool elevate(int target_pid)

1.png

image.png

2.png

image.png

3.png

图6:调用GetVersionExW()以获取Windows版本,如Cutter所示。


在这两种技术中,目标都是同时查询操作系统的主要版本和次要版本,并相应地配置利用程序的全局变量。


尽管大多数漏洞利用程序都支持广泛的Windows版本,但Volodya似乎从不关心目标的特定Service Pack,也不必关心它是否是Windows服务器。除了对仅用于CVE-2019-1458的漏洞的特定Windows 10构建版本感兴趣之外,我们的actor仅使用主要版本和次要版本,仅此而已。


与PlayBit的比较:再次GetVersionEx()使用PlayBit,通常在稍后再从流程环境块(PEB)本身对主号和次号进行额外解析,如图7所示。不仅使用PEB代替ntdll.dllPlayBit,还使用PlayBit从GetVersionEx()输出中提取其他信息,例如计算机的Service Pack,甚至检查目标计算机是否使用服务器操作系统。

图7:从PEB中提取主要版本和次要版本,如Cutter所示。

这是两个演员在作案手法上的明显区别。它们不仅以不同的方式提取相同的信息,而且Volodya对信息的兴趣远不如PlayBit,即使它们都利用相同的漏洞(CVE-2016-7255)。

通常,两个参与者都拥有详细的特定于版本的配置,一旦确定了OS版本,它们就会从中加载相关信息。两者之间的主要区别在于,Volodya漏洞利用程序中的代码流很少依赖于操作系统版本,而PlayBit则使用多种依赖于操作系统版本的if-check合并了多个扭曲和旋钮。反过来,这会影响他们对确切版本详细信息的不同兴趣。

内核地址泄漏

在绝大多数漏洞利用中,参与者使用内核指针泄漏原语来调整漏洞利用。在除CVE-2019-1458之外的所有漏洞利用中,此泄漏原语都是众所周知的HMValidateHandle技术

HMValidateHandle()是的内部未导出函数user32.dll,可被各种功能(例如)利用isMenu(),并且可用于获取所有Windows版本(直到Windows 10 RS4)中不同Window对象的内核地址。这项技术是众所周知的,甚至早在2011年就已使用,因此大多数开发教程都选择专门解析isMenu()以查找的地址HMValidateHandle()

令人惊讶的是,在可用于查找的数十种不同功能中HMValidateHandle(),演员仅遵循了著名的教程并选择了使用isMenu()令人惊讶的是,多年来,这种通用的开发技术仍然运作良好,没有给演员任何动力去尝试通过选择诸如的鲜为人知的“隐藏”功能CheckMenuRadioItem()

该泄漏为我们提供了以下内容:

  • 我们窗口的内核地址。

  • 我们THREAD_INFO(该pti字段)的内核地址

在利用过程中的多个步骤中将使用此信息:

  • 在指向/创建伪内核结构时使用地址。

  • 确保我们的内核地址是有效的Unicode字符串(不包含两个连续的'\ x00'字节)。

  • pti用于定位的有效EPROCESS,然后其在令牌交换阶段中使用。

与PlayBit的比较: PlayBit选择通过直接访问用户模式桌面堆来实现此功能。关于此主题的更多信息可以在将来针对该演员的博客文章中找到。

代币交换

漏洞利用的最终目的是根据给定的PID参数将SYSTEM特权授予所需的进程。传统上,实现此目的的方法是用SYSTEM进程的令牌替换EPROCESS / KPROCESS结构中的进程的令牌。

这里有一些常用的技术可以做到这一点。您会惊讶地发现有多少不同的选项可以实现此功能。

使用Ps *符号

Windows内核包含以下功能和与流程相关的功能的全局变量:

  • PsLookupProcessByProcessId –检索指向进程的EPROCESS的指针。

  • PsInitialSystemProcess –持有指向系统过程的指针的全局变量。

  • PsReferencePrimaryToken –返回指向流程主要令牌的指针。

通过以内核模式执行这些功能,给定的shellcode可以轻松定位SYSTEM的令牌,但是仍然无法解决如何在所需的EPROCESS中分配令牌的问题。

为此,有两种常见的解决方案:

  • 使用特定于版本的偏移量直接在EPROCESS中访问正确的偏移量。

  • 扫描EPROCESS以查找我们自己的指针(在上一次调用中已知道PsReferencePrimaryToken),并在找到匹配项后替换该条目。

此技术需要以内核模式执行代码,因此除非部署了其他SMEP旁路,否则它将被SMEP保护阻止。

扫描PsList

查找目标进程和SYSTEM进程的EPROCESS的常见替代方法是扫描双向链接的进程列表,称为PsList。此技术涉及的步骤为:

  1. 找到一个初始EPROCESS(使用泄漏的pti字段)。

  2. 扫描PsList以查找具有目标PID的EPROCESS。

  3. 通过查找PID为4或名称为,扫描PsList来搜索SYSTEM的EPROCESS SYS*

  4. 提取令牌并将其放置在目标进程中的匹配偏移量中。

  5. 谨慎更新SYSTEM令牌的引用计数。

图8: Volodya漏洞利用Arbitrary-Read原语搜索SYS*,如Cutter所示。

该技术需要的偏移到两个主令牌所述LIST_ENTRY的则PsList,几乎强制要求它们都存储为特定于版本的配置的一部分。

该技术的主要优点是,尽管它仍可以在内核模式下作为简单的shellcode执行(如在CVE-2017-0263的利用中所做的那样),但它也可以在用户模式下完全实现。为此,您需要两个利用原语,一个用于任意读取(来自内核空间),另一个用于任意写入(进入内核空间)。在用户模式下运行可以解决我们之前针对SMEP所详述的问题,从而使这种保护对于这种利用原语毫无用处。

由于令牌是一个引用计数对象,因此正确注册刚添加的引用非常重要,这样可以避免在提升进程终止时出现蓝屏死亡(BSOD)。实际上,有两个不同的参考计数:

  • 令牌是一个EX_FAST_REF对象-较低的指针位用作引用计数。

  • 将anOBJECT_HEADER存储在令牌之前,并保留另一个引用计数。

由于参与者选择更新后一个引用计数字段,因此需要执行以下步骤:

  1. 屏蔽令牌指针的ref-count位–在32位进程上应对齐8个字节,在64位进程上应对齐16个字节。

  2. 减去指向OBJECT_HEADERref-count字段所需的常数

  3. 读取值(使用任意读取漏洞利用原语)。

  4. 相应地增加它。

  5. 写回更新的值。

但是,如图9所示,我们在包含此功能的所有32位漏洞利用程序中发现了以下错误:

9:32位漏洞利用中的引用计数更新中的实现错误。

读取参考计数值时的对齐掩码为8字节的对齐方式,而回写更新后的值时使用不同的掩码。如果令牌将存储在对齐8个字节而不对齐16个字节的内存地址中,则写操作将更新错误的字段。

虽然CVE-2016-0040和CVE-2016-0167使用Ps *技术,但到目前为止,扫描PsList是我们演员最喜欢的执行令牌交换的方式,在他们的8个漏洞中使用。在其中的7个中,他们使用了用户模式下的任意读取和任意写入。

与PlayBit的比较:在他们的所有示例中,我们始终看到PlayBit使用Ps *函数进行令牌交换。这个决定迫使演员采取了一些SMEP绕过措施,将它们集成到CVE-2016-7255和CVE-2018-8453的后续漏洞中。这种设计选择说明了为什么参与者不愿意将适当的任意读取原语作为漏洞利用的一部分。PlayBit始终使用0x300或0x600作为搜索上限,而不是对EPROCESS中的令牌偏移使用特定于版本的配置,而是始终扫描EPROCESS进行搜索。

值得注意的是,Duqu 2.0还使用了PlayBit在不同漏洞利用中使用的内存破坏技术,并在Microsoft于2015年发布的VB演讲中对其进行了分析通过这种内存破坏,它们可以触发对内核内存的一些读/写操作,这将在漏洞利用期间提供帮助。

图10: PlayBit漏洞扫描EPROCESS以搜索令牌,如Cutter所示。

包起来

尽管我们可以讨论其他方面,例如每个参与者在开发过程中喜欢使用的不同系统调用,对Windows和ScrollBars之类的已创建对象的命名约定,但我们相信上面的清单清楚地证明了我们方法的效率/有效性。从上面的列表可以看出,利用程序中的几乎每个方面都可以通过几种不同的方式实现。尽管如此,我们两个演员在各自的剥削程序上都非常一致,每个人都坚持自己喜欢的方式。

顾客们

在我们整个研究过程中,我们希望专注于漏洞编写者本身,无论是Volodya,PlayBit还是其他人。但是,我们认为,通过查看漏洞利用作者的客户群,还有很多事情要学习。Volodya的客户列表各不相同,包括Ursnif等银行木马作者,GandCrab,Cerber和Magniber等勒索软件作者,以及Turla,APT28和Buhtrap等APT组(这些组织最初是从网络犯罪开始,后来转向网络间谍活动)。 )。有趣的是,我们可以看到Volodya的0天更有可能被卖给APT组,而1天是被多个犯罪软件组购买的。没有更多的信息,我们只能假设一旦安全行业检测到0天,该漏洞便被回收并以较低的价格作为非独占的1天出售。

APT的客户Turla,APT28和Buhtrap都通常归因于俄罗斯,而且有趣的是,即使是这些高级团队也购买了漏洞利用程序,而不是内部开发。这是另一个要点,这进一步加强了我们的假设,即书面漏洞利用可以被视为恶意软件的独立部分。

下表总结并显示了我们能够归因于Volodya的CVE,以及使用这些漏洞发现的客户或恶意软件组。标有蓝色的CVE为0天,自然更昂贵。左侧突出显示的组被视为APT。

图11: Volodya的客户和他们使用的CVE。

他们成长地好快

在回顾一段时间内在检查漏洞样本时注意到的不同趋势之前,我们应该强调,由于我们无法讨论尚未捕获的0天,因此可见性有限。此外,我们只能尝试将样本的日期追溯到被捕获之前的时期,但可悲的事实是,我们通常与实际在野外首次发现该漏洞利用的日期紧密相关。此外,对我们来说重要的是,从一开始就很明显,Volodya在开发我们能够归因于他们的第一个漏洞– CVE-2015-2546时已经非常专业。例如,它具有一个唯一的Arbitrary-Write原语,我们无法跟踪到其他任何利用教程/利用。

在对漏洞利用程序进行分析以及对我们收集的数十个恶意软件样本进行分析期间,我们注意到了一个有趣的变化。虽然早期的Volodya漏洞利用程序作为源代码被出售以嵌入到恶意软件中,而后期的漏洞利用程序则作为接受某个API的外部实用程序来出售。这种变化可能表明Volodya正在采取更多的预防措施。

在2015年至2019年期间,我们还注意到Volodya的技术技能有了显着改善。随着他们变得更好和更有经验,Volodya开始使用更有效的任意读写原语,他们甚至修复了这些原语之间的错误。

CVE-2015-2546和CVE-2016-0165 *。而且,随着大型功能被拆分为较小的子例程,漏洞利用代码变得更加模块化。此外,他们在各种结构中搜索和访问特定偏移量的技术也得到了改进,并且在最近的实现中,它可以更好地处理Windows次要版本中的更改,因此变得更加动态和安全。

这不仅显示了我们演员的学习曲线和发展,也暗示了他们的技能。查找并可靠利用Windows内核漏洞的能力确实不是那么简单。相比之下,我们可以看到PlayBit在2015-2018年期间在这个市场上非常活跃,他们的重点是出售1天漏洞的漏洞,其中之一是Volodya的0天漏洞(CVE-2016- 7255)。

结论

我们的研究方法是对漏洞利用作者的特征进行指纹识别,然后再将这些属性用作唯一的狩猎签名。在跟踪Volodya和PlayBit的漏洞时,我们两次部署了此技术。有了这两个成功的测试案例,我们相信该研究方法可用于确定其他漏洞利用程序作者。我们建议其他研究人员尝试我们建议的技术,并将其用作其武器库中的其他工具。

在此研究过程中,我们重点研究了APT攻击和商品恶意软件(尤其是勒索软件)中不同恶意软件家族所使用或嵌入的漏洞。尽管它们很普遍,但我们经常发现详尽的恶意软件报告,而忽略了提及手边的恶意软件也利用漏洞来提升其特权的报告。

我们能够反复使用我们的技术来跟踪由两个不同参与者编写和出售的16种Windows LPE漏洞,这一事实令人惊讶。考虑到其中有15个是在2015-2019年的时间范围内,因此可以假设它们构成了漏洞利用市场的重要份额,尤其是Windows LPE漏洞。

最后,不可能说出正在积极利用的Windows内核0天漏洞的总数。民族国家的参与者不太可能被抓住,因此信息安全社区对其弹药箱没有清晰的可见性。话虽如此,我们仍然可以通过回顾所捕获的漏洞来获得洞察力,同时记住这种生存偏见。去年,卡巴斯基报告说,有一个演员分发了一个漏洞利用框架,其中包括另外3个0天。将这些数字加起来,我们发现15个零日漏洞中有8个(占“市场份额”的一半以上)仅归因于两个参与者(!)。这意味着我们的研究技术有可能被用来追踪可见市场中的许多参与者,即使不是全部。

保护建议

Check Point威胁仿真可针对以下威胁提供保护:

  • Trojan.Wins.Generic.F

  • Trojan.Wins.Generic.G

附录–国际奥委会表

Volodya

CVE-2015至2546年: 3f6fe68981157bf3e267148ec4abf801a0983f4cea64d1aaf50fecc97ae590d3
CVE-2016-0040: 0ea43ba3e1907d1b5655a665b54ad5295a93bda660146cf7c8c302b74ab573e9
CVE-2016-0165 *: f1842080b38b3b990ba3ccc1d55ceedd901d423b6b8625633e1885f0dadee4c2
CVE-2016-0167: 6224efee6665118fe4b5bfbc0c4b1dbe611a43a4b385f61ae33b0a0af230da4e
CVE-2016-7255: a785ad170a38280fc595dcc5af0842bd7cabc77b86deb510aa6ebb264bf2c092
CVE-2017-0001: ed7532c77d2e5cf559a23a355e62d26c7a036f2c51b1dd669745a9a577f831a0
CVE-2017-0263: f9dca02aa877ad36f05df1ebb16563c9dd07639a038b9840879be4499f840a10
CVE-2018-8641 *: 0829f90a94aea5f7a56d6ebf0295e3d48b1dffcfefe91c7b2231a7108fe69c5e
CVE-2019-0859 -初始样品64: 895ab681351439ee4281690df21c4a47bdeb6691b9b828fdf8c8fed3f45202d8
CVE-2019-0859 -匹配32位样本: eea10d513ae0c33248484105355a25f80dc9b4f1cfd9e735e447a6f7fd52b569
CVE-2019至1458年: 8af2cf1a254b1dafe9e15027687b0315493877524c089403d3ffffa950389a30

播放位

CVE-2013-3660: 9f1a235eb38291cef296829be4b4d03618cd21e0b4f343f75a460c31a0ad62d3
CVE-2015-0057: 8869e0df9b5f4a894216c76aa5689686395c16296761716abece00a0b4234d87
CVE-2015至1701年(是的,它是相同的样品作为CVE-2015-0057)  8869e0df9b5f4a894216c76aa5689686395c16296761716abece00a0b4234d87
CVE-2016-7255: 5c27e05b788ba3b997a70df674d410322c3fa5e97079a7bf3aec369a0d397164
CVE-2018-8453: 50da0183466a9852590de0d9e58bbe64f22ff8fc20a9ccc68ed0e50b367d7043

原文地址:https://research.checkpoint.com/2020/graphology-of-an-exploit-volodya/ 转载请注明

.
更多

1589982338979126.png


ots网络社区

www.ots-sec.cn

联系方式
更多

投稿邮箱:1481840992@qq.com

交流群2群:622534175

ots网络社区3群:1078548359

关注我们
更多
技术支持: 建站ABC | 管理登录