2022 SDC 议题回顾 | 猫鼠游戏：如何进行Windows平台在野0day狩猎
2022-12-7 18:3:47 Author: 看雪学苑(查看原文) 阅读量:7 收藏

在本议题中，演讲者讲述了如何使用不同的工具来解决不同的问题，例如如何借助沙箱来狩猎Office在野0day，以及如何借助Yara来狩猎Windows本地提权在野0day。此外，演讲者还对近两年的热门Office在野0day和Windows本地提权在野0day进行案例分析，并分享了一些最近捕获的案例。最后，演讲者结合自身经验，就如何培养在野0day狩猎人才给出了一些建议。

大家好，很高兴能来看雪峰会演讲，我本次演讲的议题是《猫鼠游戏：如何进行Windows平台在野0day狩猎》。
首先自我介绍一下，我是来自安恒信息的金权，括号里是我的Twitter ID（@jq0904）和看雪ID（银雁冰），欢迎交流。我目前任职于安恒信息猎影实验室和卫兵实验室，为什么会同时任职两个实验室呢？这和我的研究方向有关。我目前主要从事Windows平台的漏洞挖掘与利用，以及Windows平台在野0day狩猎，前者是卫兵实验室的工作范畴，后者是猎影实验室的工作范畴。同时我还管理卫兵实验室二进制漏洞小组，欢迎志同道合的小伙伴加入我们。
我之前曾在Blackhat/Bluehat/HITB等会议进行演讲，累计获得过多次微软和Adobe的漏洞致谢和在野0day致谢，同时还连续三年入选了微软MSRC TOP 100研究员。
下面我们来看一下本次的演讲的大致内容。
接下来我会先介绍一下本次演讲的背景，包括一些专业术语的解释和国内外这方面的一些现状。然后我会解释为什么在0day狩猎这件事情上，需要用不同的方法去解决不同的问题。接着我会挑选近两年热门的几个在野0day案例进行分析，包括一个比较有代表性的office在野0day案例，和一个Windows本地提权在野0day案例。最后我将结合我自己个人的工作经验，就如何培养在野0day狩猎这方面的人才发表自己的一些观点。

首先我们来看一下背景，这张图展示的是最近5年全球在野0day披露数量以及国内外的占比。我们可以看到，蓝色部分是国外厂商在最近5年披露的在野0day漏洞数量，橙色部分是国内厂商，很明显国内厂商跟国外厂商在这个领域上还是存在比较大的差距的。
我们来看第二张图表，这张图表展示的是国内厂商在最近5年捕获的在野0day数量分布，从图表中可以看到国内该领域做的最好的公司是360，其次是安恒信息、腾讯、阿里、奇安信等，这说明即使在国内，在野0day狩猎也存在较高的技术壁垒。
第三张图表展示的是这5年间我参与披露的在野0day数量，包括之前在360工作期间的4个在野0day，在安恒工作期间的3个在野0day，累计是7个，这个比例占这几年国内披露总数量的约1/3。因此我觉得可以结合自身在这方面的经验做个分享，以帮助大家获得一些这方面的启发。

现在我解释一下为什么需要用不同的方法解决不同的问题。我们首先来解释一下，沙箱为什么适合狩猎office在野0day？
我们总结一下office在野0day的漏洞分类，主要包括两大类，第一大类是纯office漏洞，这个很好理解，就是这个漏洞完全发生在office自己的组件内，包括两小部分，第一部分是内存破坏漏洞，第二部分是逻辑漏洞。
第二个大类是以office为载体的其他漏洞。这方面我也做了4个分类，第一个是flash漏洞，第二个是IE浏览器漏洞，第三个是.Net漏洞，第四个是Windows系统漏洞。
第一类flash漏洞已经随着flash的退役而消失了。第二类IE浏览器漏洞也随着IE的退役而逐渐减少了，但是它没有消失，原因在于office仍然可以调用IE的组件，它存在接口，这个接口并没有随着IE浏览器的退役而消失。第三个是.Net漏洞，只发生过个例，我这里不做过多的解释。最后一类是Windows系统漏洞，这种漏洞目前只见到过很少的例子，其中一个是CVE-2014-4148。我没记错的话，2011年有一个顶尖APT团队使用这个漏洞，在实际的使用场景中，只用一个Windows的字体系统漏洞，诱导受害者打开一个word文档就可以直接拿下系统最高权限，并且实现远程代码执行，杀伤力是非常大的，不排除后面还会出现这种。
office在0day漏洞利用方面目前存在两大趋势，第一个趋势就是内存破坏漏洞越来越少了。大家能感觉到最近内存漏洞缓解机制日益完善，导致内存破坏的漏洞现在能挖到但是不好利用了。特别是office它之前的符号还无法下载， PDB文件是下不到的，这就导致利用内存漏洞更加困难。所以就导致大概从2017年开始（其实2014年的杀虫漏洞也算），这种逻辑性的漏洞越来越多。

第二个趋势是远程加载漏洞利用的手法越来越流行。具体到现实中的案例的话，2014年有CVE-2014-4114，2017年有CVE-2017-0199和CVE-2017-8759，2018年有CVE-2018-5002，CVE-2018-8174，CVE-2018-15982，2020年有CVE-2020-0674，2021年有CVE-2021-40444，以及今年还有一个CVE-2022-30190，都是这种远程加载漏洞利用的手法。
有了前面具体漏洞分类和趋势讲解，我们就可以来解释一下为什么说沙箱是比较适合狩猎office在野0day的。我们来简单地做个逻辑推理。目前远程加载漏洞利用已经成为office在野0day利用的一个主流，那么在这种攻击手法中，利用代码它基本上是云控的，具有时效性，这一点对于检测者来说其实是不太友好的。

我们有两种方式，第一种是静态检测，既然你是云控的漏洞利用代码，我只需要把你的URL提取出来，获取到漏洞利用组件，我就可以进行后面的分析。此外还有沙箱检测这种手法。
我们以静态提取URL为例，它其实是有几个缺点的。目前的大多数office在野0day攻击中实际的攻击载体都是rtf格式的文件。众所周知，rtf是一种古老的office文件格式，它由众多关键字组成，这种文件格式的组成就导致rtf很容易进行代码混淆。那么在实际静态提取的时候，如果你的静态提取算法写得不好，就很容易被绕过，就提取不到 URL，这种漏报和误报会对实际的检测造成很大的影响。
第二个缺点就是有些具体的案例中，它的漏洞利用代码在云端请求时是会加密的，比如说2018年有一个比较典型的例子是CVE-2018-5002，这是一个flash在野0day，以Excel为载体进行攻击。
它里面嵌了一套flash的漏洞利用框架，非常复杂，它在实际获取利用代码的时候是加密的。对于这种样本来说，如果只是静态把里面的 URL提取出来去获取云端的漏洞利用组件。第一个是可能根本就获取不到，第二个是即使获取到了，它里面组件是加密的，那也无法解出来。

现在我们再来考虑一下沙箱的检测场景，沙箱的一个优点是只要解决一些少量的对话框交互情况，就可以做到对样本的全过程模拟执行。像rtf代码混淆和请求时加密的这种行为，是无法影响一个样本动态执行的。所以沙箱在检测这类样本时可以做到全过程的记录，准确率高。我们只要基于沙箱捕获的行为进行狩猎就行。狩猎者唯一需要做的就是在这方面提高一些筛选的准确条件。还有一个原因就是，对于那种 office内存破坏漏洞，你不确定漏洞能在哪个版本上完美的触发。举个例子，CVE-2015-1641内存破坏漏洞，它很有可能只能在office 2013触发，如果只做一个office环境肯定是不够的。

对于逻辑漏洞来说，攻击者比较喜欢它的一个方面是，它的代码适配性很高，只要写出一份利用代码基本上就影响大部分的office环境。所以对于这种漏洞样本，我们在沙箱环境制作上的工作量也是比较小的，最偷懒的方法就是，我只需要维护一个目前比较常用的office版本的全补丁镜像就可以。所谓的全补丁镜像指的就是office补丁和操作系统补丁都打到最新的镜像。

现在来简要评估一下，以我的经验来看，沙箱大概能覆盖office在野0day约80%左右的狩猎场景（这只是一个大致的估算，并不准确），可以看到这个比例其实是相当高了的。

目前观察到的所有历史office在野0day的攻击案例，经过事后复盘，大部分都能通过沙箱捕获到，前提是你的沙箱做得足够好。所以各位后面如果有志于捕获一个 office的在野0day，做好你们的沙箱产品就可以，后面肯定还有机会。

现在我介绍一些用沙箱狩猎Office在野0day的可行思路，仅供参考：
做一个全补丁的office镜像，然后将可疑样本投入沙箱，通过异常行为进行捕获，这个流程谁都会。环境制作的话，我在PPT上也随便推荐了一个，不一定以此为准。异常行为方面，我觉得office由于目前逻辑性的在野0day也比较多，所以可以重点关注office进程启动可疑子进程的这种异常行为。
当然也需要过滤一些常见白名单，因为众所周知office是出了名的复杂，很多时候会调用系统进程进行各种各样的行为操作，比如说启动一个打印机进程之类的。第二个就是可以检测检测是否有异常地址处的指令访问敏感模块的导出表，这种异常地址指的是Shellcode之类，敏感模块的话可以指kernel32，kernelbase等，其实微软在这方面已经做了个EMET了，简单说就是导出地址表过滤。

既然已经做了一个全补丁的office镜像，并且已经获取了样本，又已经将样本投入沙箱，整套流程都建立起来了。当然也可以顺带做一些officenday漏洞的检测环境，在筛选0day的时候顺便标定一些被用于攻击的nday，以便对沙箱进行最大化利用。但是这个要求你的团队内要有对office历史漏洞案例有深入研究的人。
在具体的标定方式方面，也有两种：静态和动态。静态的话，我目前看过最好的（误报率比较少）的，是一个Github上开源的叫做quicksand的项目，有兴趣的可以去看一下，做得还是比较好的。动态标定方面的话，你既然要标定一些office的历史nday，想要做到比较好的动态检测的话，至少需要要挂钩到准确的漏洞触发处，这对技术要求就比较大了。当然它也有好处，它的准确率是比较高的。

接下来我来讲述一下为什么Yara是适合狩猎Windows本地提权在野0day的，更准确的说，我将解释一下为什么Yara是适合狩猎Windows本地提权在野0day里面的其中一个子分类。
和office一样，我们首先来看一下Windows本地提权在野0day的漏洞分类情况，主要分为三种，第一种大家最熟悉的内核提权漏洞，本议题也将重点讨论对其的狩猎情况，这类漏洞指的是由windows操作系统内核驱动程序的内存破坏引发的漏洞，可以实现从很低的权限提升到系统最高权限。
第二类是用户态提权漏洞，这个主要是由一些高权限的用户态进程引发的内存破坏漏洞，比较经典的是CVE-2020-0968，这是一个卡巴斯基捕获的在野0day，这个漏洞当时的实际使用场景是用来穿越IE的沙箱。
第三种是逻辑提权漏洞，例如COM提权漏洞和打印机提权漏洞，比较经典的是谷歌Project Zero的James Forshow公布的一些漏洞案例。当然后面国内外安全研究员在2017年之后针对这种COM提权漏洞进行了大量的挖掘，有很多有趣的故事，有兴趣的话可以去了解一下。

我们再来看一下Windows本地提权在野0day的使用场景。我觉得主要分两块，第一块是作为完整漏洞链的一部分，与其他前置漏洞配合使用。这部分主要可以细分为3种，第一种是配合office漏洞进行提权，比较知名的是CVE-2017-0263。第二种是内嵌在浏览器漏洞内进行利用，这方面卡巴斯基在去年捕获过一个比较厉害的漏洞，是CVE-2021-31956，实际使用场景是用来穿越chrome的沙箱。第三种是实配合flash使用，有一个比较经典的案例，就是与CVE-2018-5002这个漏洞配合。前置漏洞利用成功之后，再从云端获取提权组件并解密使用。
这个案例当时非常的复杂，背后的组织也很强，前面前置了一个flash漏洞，这个flash漏洞在2018年5月份被360和奇安等厂商捕获了，但是由于它主要攻击中东，在中国地区捕获到的样案例并没有抓到后续的配套载荷。然后Palo Alto Networks综合前面的厂商披露的信息捕获了后面的载荷，写了一篇分析文章，随后卡巴斯基又顺着Palo Alto Networks文章里面给出的一些线索深入挖，最后捕获到了CVE-2018-8453，整个攻击过程非常复杂，是多家厂商共同披露的一个综合性案例。

作为独立组件使用时的典型场景也分为两种，一种就是下发单个提权组件，但是使用的时候需要配合一些参数，比较经典的是我们抓到的CVE-2021-1732样本。这个样本在使用时需要使用者提供一个进程ID，然后它会把进程ID对应的进程提到最高权限。第二种就是最简单的直接双击执行提权，比如说我们在今年8月底抓到的在野0day样本。

很明显，不同的场景需要用不同的方法，如果说Windows本地提权0day作为完整利用链的一部分进行使用，它很有可能是全程加密的，或者漏洞组件是从云端获取的。这种情况下，Yara和沙箱就会显得比较无力。我个人认为终端防护能力做得比较好的厂商在这方面是比较有优势的，比如说CrowdStrike和卡巴斯基。国内的话，可能360在这方面也会有一些优势，这种场景比较适合先EDR发现线索，然后专家团介入，更复杂的话还要去现场去取证，得多个环节配合这种事件的调查。

我们再看一下其他场景，如果说这个样本是第二种使用场景，作为独立组件使用，这时候难度就降低了一些。那么我们再根据它是否加密加壳，再分为两种情况，如果一个攻击者比较小心，基于各种考虑对编译好的可执行文件加了个壳或者加了密，这种时候用Yara去狩猎就显得比较无力，这种场景我觉得比较适合用沙箱检测，前提是在沙箱里面集成了Windows内核提权漏洞的一些检测技术，比如Token替换技术之类。

最后，最简单的场景，作为独立组件使用，而且还不加壳，直接编译完之后就来使用了。我觉得这种场景是非常适合Yara进行狩猎的。事实上目前观察到的大多数案例都是这种情况，我也不知道为什么攻击者他编译完之后就拿来用了，有可能是他们开发时也是流水线，前面的开发团队完成后丢给使用团队使用，后者使用的时候并没有考虑这方面的因素就直接开始用了。
下面我再来讲一些Yara在狩猎Windows本地提权样本其他方面的优势，主要是三点。

第一点，漏洞利用代码在运行前往往会检测操作系统的版本，或者杀毒软件的版本，或者沙箱的环境检测，这是因为商业化的代码会确保它使用时候的小心性。这个时候Yara就比那些进行动态检测的手法更有效，因为Yara对这种类型的动态检测免疫。

第二点，攻击者也经常使用一些经典的漏洞利用手法，而这些经典的手法因为它经典，所以会随时间流逝具有一定的连续性，而这些手法又恰好具备较强的静态特征。比较典型的是HMValidateHandle和Previous Mode的手法。

第三点，攻击者也经常瞄准较为较为热门的漏洞模块，他们也蹭热点，因为蹭热点意味着无论是写Poc，写Exploit，还是后续的开发成本都比较低，大家都喜欢简单的事情，是不是？但是热门模块的规则恰恰具有通用性，像之前win32k模块的callback机制，一直到现在都在被攻击。像今年不同厂商捕获到的好几个在野0day都是在CLFS驱动模块，因为它容易出问题，攻击者也喜欢攻击出问题的模块。

我个人来评估一下的话，我觉得Yara大概能覆盖Windows本地提权在野0day狩猎场景里面的大概20%。我来解释一下，因为Windows本地提权在野0day的狩猎场景是比较复杂的，有相当一部分是存在业界能力范围外的场景。例如微软、卡巴斯基、谷歌这三家厂商，在公开披露的文章里面都提到过这样的案例：他们知道相关漏洞的使用痕迹，但是没有捕获到对应的样本。

在业界能力范围内的能捕获的场景主要是适合用EDR进行狩猎的场景，沙箱狩猎的场景和Yara狩猎的场景。EDR这块的狩猎目前做的比较好的应该是卡巴斯基，还有CrowdStrike。我个人觉得沙箱在捕获Windows本地提权在野0day这块也是比较强力的，但是我目前好像没有看到有任何厂商公开披露相关案例。最后一块是适用Yara狩猎的场景，这方面目前做的比较好的是安恒的猎影实验室。
前面说了Yara比较适合Windows本地提权在野0day下面的一个子分类，我们来看一下如何正确地编写Yara规则，我个人觉得大概有三点，第一点是为漏洞利用的各个阶段特征编写规则；第二点是为最新的漏洞利用手法编写规则；第三点是为最可能出现的漏洞编写规则。

我们先来讲一下第一点，一个Windows内核本地提权漏洞的利用过程通常包括以下几个阶段：漏洞触发，堆风水，信息泄露，任意地址读写，控制流劫持和权限提升。我们的目的就是基于每个阶段的通用特征写规则，这部分的详细细节可以参考我在今年Blackhat USA 2022会议上的一个演讲，我在这里不做过多的讲述。

对于第二点，这里我给出两个例子：
1. 2020年7月，Synacktiv公司的 Paul Fariello 和 Corentin Bayet 在SSTIC大会上提出了一种新的Windows内核堆溢出漏洞利用手法。在学习了他们的白皮书后，我们意识到在分页池中借助Pipe Attribute手法实现任意地址读取的利用方式具有通用性，在未来很可能会被用到。因此我们花了一些时间为这种手法写了几条规则。事实证明这些规则后来捕获了几个高价值样本。
2. 2021年6月8号，卡巴斯基写了一篇博客，披露了一个Windows本地提权在野0day(CVE-2021-31956)。文章中提到样本使用WNF实现了任意地址读写原语。随后在2021年7月和8月，NCC Group 公司的 Alex Plaskett 发表了两篇博客，详细披露了CVE-2021-31956漏洞的利用细节，并解释了使用WNF构造任意地址读写原语的细节。与此同时，YanZiShuang也写了一篇博客讨论了借助WNF构造任意地址读写原语的手法。在学习了这些博客后，我们意识到这种方法是通用的，于是又花了一些时间为此写了几条规则。和预期的一样，我们确实捕获了一些高价值样本。

对于第三点，我这里也给出一个例子。2021年4月13号，卡巴斯基写了一篇博客披露了CVE-2021-28310，这是一个位于Windows桌面窗口管理器组件的Windows本地提权在野0day。不到一个月后，ZDI发表了另一篇博客，披露了另一个漏洞（CVE-2021-26900），这也是一个位于dwm组件的漏洞。这使我们意识到这种类型的漏洞在未来还会出现，所以我们在几个小时内为dwm漏洞写了几条规则。几周后，我们捕获了CVE-2021-33739这个在野0day。

接下来我们进入具体的案例分析阶段，首先来看一下office在野0day的一个案例，我选了一个CVE-2021-40444，我觉得它在近两年比较有代表性，这是一个IE浏览器的在野0day，但是它的实际使用场景是借助word文档进行攻击的。

我们来看一下它的发现厂商，是Mandiant，EXPMON和微软自己。我们来看一下这个样本的攻击流程，它首先是借助word文档远程加载了一个云端的html漏洞利用代码，随后 word加载IE组件，把 html文件进行解析，在这个过程中触发了IE的一个逻辑漏洞，这个逻辑漏洞可以导致在IE在解压CAD文件到特定目录的时候出现路径穿越，随后样本加载路径穿越得到的可预测目录的一个dll文件，实现了载荷的远程代码执行。

该漏洞主要由两个问题导致，第一个问题是CAB文件解压时存在一处路径穿越，第二个问题是可以直接指定CPL协议去加载dll。这里我着重讲一下CAB文件解压漏洞的成因及微软对它的修补，问题主要出在 catDirAndFile 函数，值得注意的是，这是微软的开发人员第二次在这里犯错。关于CPL协议加载DLL的具体细节，大家可以参考我在看雪论坛的一篇文章，那篇文章里面详细披露了这个漏洞的所有细节。
我们先来看一下微软开发人员的第一次犯错，图中引用的是某个早期版本的 catDirAndFile 函数代码，大家着重看一下红框内的代码，该处代码的逻辑是拼接文件名，注释也写得很清楚。很明显，该处代码在拼接路径时完全没有考虑路径穿越问题，如果这里拼接的路径中存在路径穿越字符，就会导致路径穿越。
很久以后，微软意识到了这里存在路径穿越问题，在某次安全更新后，开发人员在 catDirAndFile 函数内增加了 PathCchCanonicalizeA 和 PathIsPrefixA 两个函数，用于处理路径穿越问题。
PathCchCanonicalizeA函数的作用是将当前路径转化为规范化路径，理论上它能处理路径穿越字符。但让API使用者没想到的是，PathCchCanonicalizeA 只能处理反斜杠路径穿越字符，而路径穿越字符其实有正反斜杠两种写法。这就又留下了隐患。
PathIsPrefixA 函数的作用是，检查第二参数的路径是否以第一参数的路径作为前缀，如果是，则通过检查，继续往下执行，如果不是，则返回失败。在上述代码中，其第二参数的值来自 PathCchCanonicalizeA 处理返回的结果。
清楚了第一次补丁的修复逻辑后，我们可以来检视一下 PathIsPrefixA 实际的校验情况。实际调试时，某次 pszPrefix 参数的值如图上所示，我们来考虑 pszPath 的两种情况。
第一种情况，如果传入路径中有反斜杠路径穿越字符，经过PathCchCanonicalizeA 函数处理后，路径穿越被消除，转换后的路径明显无法以pszPrefix 参数的值作为前缀，校验失败，停止执行。
第二种情况，如果传入路径中有正斜杠路径穿越字符，经过PathCchCanonicalizeA 函数处理后，路径穿越并不会被消除，转换后还是原来的路径，转换后的路径显然可以用 pszPrefix 参数的值作为前缀，校验通过，CAB文件解压的内容成功被穿越到temp目录。

我们来看一下CVE-2021-40444漏洞的补丁，清楚了漏洞成因后，补丁修复人员在之前的基础上又加入了对正斜杠的处理，从而彻底修复了路径穿越问题。假设API开发人员一开始就考虑到正反斜杠两种路径穿越场景的话，就不会出现这个漏洞。

大家思考一下，还存在类似的问题吗？肯定还是存在的，因为补丁修复的人员在用那个函数的时候，有时候根本就没有考虑到它只能处理反斜杠，不能处理正斜杠，开发API的那个人犯的错误才是根源，所以大家有兴趣可以去审计一下类似函数的使用场景，很可能还有。

接下来我分享一个Windows本地提权漏洞案例，我选的案例是 CVE-2022-24521，这是2022年4月微软披露的一个CLFS驱动在野0day，这个样本在使用的时候是作为一个独立组件进行使用的，属于最简单的使用场景。该漏洞的发现厂商是CrowdStrike和和NSA，漏洞披露后，我就一直在想，其他团队有没有可能抓到这个0day？

直到今年思科被入侵的一些细节被Talos团队自己披露之后，我在里面找到了一些相关的样本，这是一个加密压缩包样本，首次提交vt的时间是在今年的3月18号，这个漏洞是4月份修复的，3月18号里面第一个文件的文件最后的修改时间是2022年1月31号，说明很早就出现了。思科这篇文章里面还披露了另外一个样本，刚好就是压缩包里面解出来的第一个样本，我们可以通过crc32校验码很完美的进行信息匹配。这个样本它的编译时间比较有趣，在2021年10月28号。这个说明什么？这个样本从编译到使用到被发现，大概过了半年时间，这在目前已经是一个比较长的窗口期了，但比较可惜的一点是，这个样本在8月25日才提交到VT，很明显太迟了。

所以，如果有团队可以在3月18号到4月12号把压缩包给解出来或者爆破掉的话，他就有可能抓到样本，但这个是有一定难度的，我到现在也不知道压缩包的密码是多少。这个案例也告诉我们，其实很多时候并不是说没有样本，而是样本它就游走在我们的视野范围下，但是我们并没有看到。
CVE-2021-24521漏洞的成因是 SignatureOffset 字段的范围校验不严格，从而导致SignatureOffset 指向的区域可以与某个 Container Context 的 pContainer 指针重合。攻击者可以通过精心构造日志文件内容来触发这个漏洞，CLFS在解析日志文件时，会调用 ClfsEncodeBlock 函数将每个 512 字节扇区的最后两字节备份到 SignatureOffset 指向的偏移处，整个“备份”完成后，pContainer 指针会被替换为攻击者伪造的指针。
我们来看一下在野0day样本是如何利用这个漏洞的，样本首先借助漏洞，将内存中的 pContainer 指针覆盖为 fakeContainer 指针，并且事先已经伪造了 fakeContainer 的虚函数表。这个过程要求伪造日志文件的相关字段遵从严格的对应，上面三行代码是在野24521漏洞利用的一个强特征点。底下的汇编代码显示的是某次内存中的 Container Context 对象和其内部的 fakeContainer 指针，我们可以看到这个指针变为了一个用户态地址，它的虚表也变为了一个用户态地址。正常情况下，这两个地址应该位于内核空间。
接下来我们看一下在野样本是如何实现任意地址写入的，在 RemoveContainer 函数内，代码会尝试获取 pContainer 指针，并调用内部的两个虚函数。正常情况下这两个函数是 Release 和 Remove。触发漏洞后，这两处实际调用的函数变为攻击者准备的两个函数，利用代码通过这两个函数实现了任意地址写入。
此外，为了构造任意地址读取，在野样本采用了这几年比较流行的 Pipe Attribute 手法，通过修改 PipeAttribute 结构的 Size 和 Value 字段以实现任意地址读取。值得一提的是，在构造任意地址读取原语的过程中，在野样本还借助 SystemBigPoolInformation 手法泄露了部分关键堆地址。具备任意地址读写原语后，在野样本获取 System 进程的令牌，并将自身的令牌替换为 System 进程的令牌，从而完成提权。

在分析完24521漏洞的在野样本后，我马上关联到了另一个CLFS在野漏洞样本。除了使用的漏洞不同，两个样本的漏洞利用手法完全一致，推测为同一开发人员所编写。关于该另一个的更多细节可以参考我在 Blackhat USA 2022 会议上的演讲 。
除了前述两个CLFS在野漏洞，我们还捕获到一些其他的CLFS漏洞在野样本，这里面有一些是1day，有一些是0day。特别地，在2022年8月底，我们还捕获了一个新的CLFS在野0day：CVE-2022-37969。由于该漏洞在演讲时尚未彻底修复，出于谨慎考虑，不做过多披露。不过国外公司已经有一篇分析文章，感兴趣的观众可以去阅读一下。以上是案例分析部分的所有内容。

最后我结合自己的一些工作经验，就如何培养在野0day狩猎人才，发表一些自己的思考。

我们以累计捕获在野0day案例数量 ≥3 作为筛选标准，全球范围内，该领域目前做得比较好的团队或公司是如下几个。
从统计结果来看，少数团队/公司多次捕获在野0day的现象非常普遍，头部厂商由于容易集聚人才，拥有优质数据且具备领先的技术，往往可以做到多次捕获这类顶级威胁事件。规模较小的公司，由于在人才招聘、数据积累和技术研发上的相对劣势，往往无法迈入在野0day狩猎的门槛。所以，接下来我结合自身经验给出一些培养此类人才的建议，仅作为个人观点。
第一点是好苗子很重要，顶级的威胁狩猎人员往往具备敏锐的嗅觉，一点蛛丝马迹就可以引起他们的注意，这种嗅觉后天往往很难培养。

第二点是要对历史案例有仔细的研究，为了捕获一个Office在野0day，最好把历史Office在野0day都研究一遍，Windows本地提权在野0day也一样，这部分的时间成本没有办法省略，一万小时定律在威胁狩猎领域一样适用。

第三点是要有有价值的数据源，对于卡巴斯基和CrwodStrike这些有海量终端的企业来讲，端上的告警数据是非常有价值的；对于终端没有那么多的企业，VT是一个不错的选择；对于规模较小的企业来讲，样本交换或者收集公开样本也都是不错的选择，当然这里面含有在野0day的可能性会比较小。俗话说，巧妇难为无米之炊，如果数据本身都不含希望，那更谈不上狩猎。

第四点是要提供或者具备合适的平台和工具，像优质的EDR、沙箱、YARA这些都是久经考验的狩猎利器，如果可以用好这些工具，必定事半功倍。而且要注意根据不同的情况选择不同的工具。

第五点是要不断模拟演练，不断复盘优化，在这方面历史样本是很好的试金石。如果所有历史样本都可以捕获，那根本不用担心无法捕获后面的样本。此外，在在野0day狩猎这件事上，时间就是一切，必须锻炼早发现、早防御、早修复的行动力，以及不断缩短各环节的时间消耗。能做到3小时内完成响应的人，和只能做到3天内完成响应的人，水平肯定是不一样的。

最后一点，要具备逆向思维，经常站在攻击者的角度进行思考，假如一个攻击者具备和你同样的知识，熟知同样的趋势，他接下来会怎么做？要去猜测对方的意图，并在中途等待他们。这是一种比较高的对抗层级，但就像陆基中段反导拦截技术一样，一旦具备就会牢牢占据主动权。

今天的分享到此结束，谢谢大家。

文章来源: http://mp.weixin.qq.com/s?__biz=MjM5NTc2MDYxMw==&mid=2458486711&idx=1&sn=2f510ec4187c3d54291ad4aa9340c26b&chksm=b18eb73d86f93e2b5d46e31788196d984a75d023bd664e04f86e30dee5557e2a4548e4995799#rd
如有侵权请联系:admin#unsafe.sh