【本人手动渣翻系列·其三】WDAV更新分析

ANY.LNK

原文地址：https://www.safebreach.com/blog/ ... me-a-security-risk/

作者：Tomer Bar, VP Security Research, SafeBreach | Omer Attias

首发于2023年的Black Hat USA上

（虽然原文本质上是一篇漏洞分析文）

背景

2012年，卡巴斯基实验室的研究人员发现了Flame恶意软件，国家支持的威胁行为者使用此恶意软件，使用复杂的中间人攻击（MITM）劫持Windows的更新过程，将受感染的计算机的更新请求重定向至攻击者的服务器。此后，攻击者就能分发恶意更新并使用此种方法在受害者处维持持久化。

我们开始思考，可否用类似的方式劫持Windows Defender的更新过程，进而劫持Windows Defender本身以实现恶意目的。我们同样希望在不使用MITM、证书伪造以及特权用户的方式下达成此目的。

研究过程

理解Windows Defender的更新过程

为了确定最佳的方案，我们需要理解Windows Defender的更新过程。我们发现WD会定期ping微软更新中心（Microsoft Update Center）并检查是否有新的签名更新。若更新可用，它将返回一个名为Microsoft Protection Antimalware Front End的可执行文件（MPAM-FE.exe）



下载并分析MPAM文件后，我们发现其中包含一个CAB文件，其中又包含了2个可执行文件：mpengine.dll和MpSigStub.exe，以及4个VDM文件。运行MPAM文件，我们注意到它同样会运行MpSigStub作为子进程用于下载更新。

我们起初对VDM文件了解不多，但很快注意到了它们在研究中的重要性。它们是PE文件，但无法被执行因为其中并不包含逻辑代码。我们起初认为这是特殊的包含检测签名的数据文件，包含两种类型的VDM：Base和Delta，主要区别在它们的大小；后续的深入分析发现了它们是如何向Defender推送新签名数据库更新的。我们同样发现了微软为CAB内每个的文件进行了数字签名，用于防止更新过程中的篡改攻击。



选择正确的可利用文件

我们起初想替换原始的mpengine.dll位我们的虚假mpengine.dll，但此种尝试因为没有正确的签名失败了，并且无法更新。



接下来，我们转向VDM文件。我们开始取得了一些成果，让Defender认为旧版的VDM文件（没有修改任何数据）是新版本。这让我们认为找到了正确的方向。

此后我们尝试修改了VDM Delta文件中的随机字节并尝试推送此更新，但这种尝试没有成功。很明显，我们的过程中缺少了什么。此外，作为非特权用户，我们很难实现这一切。这些的答案就在于Malware Protection Signature Update Stub (MpSigStub)文件中。它揭示了Delta VDM文件的目的是为了给WD Base提供签名更新。

理解VDM文件

VDM文件是Windows PE文件，包含一个资源部分，压缩了Defender签名，但令人惊讶的是，这些文件都没有加密。解压缩后，我们可以轻易在Base文件中看到签名的起始与终止位置、实际的由清晰恶意软件名称的字符串。可以肯定的是，这是Defender检查恶意软件签名的主要文件，Delta文件则更复杂，需要进行深入分析。



理解签名结构

（详细可以参见此系列中我的第一篇译文）

0x5C：签名起始
0x5D：签名结束

上一条签名结束，下一条开始，可以从Base中提取多达250多万个签名。我们尝试修改特定签名的威胁名称，修改冗余校验CRC，并重新压缩，但这些尝试都失败了。

此后我们明白，不能忽视Delta文件。我们之前误解了Base和Delta之间的关系。更新和合并过程中以Base文件为蓝本，而Delta文件定义对Base文件做出的修改。这样之后的输出文件代表Delta文件的更新版本。我们意识到，要对Base文件进行目标的修改，只需提供设定好的Delta文件。


了解整个合并和签名认证流程

Delta文件是基于签名的文件。它总是包含2个签名，第二个签名类型为二进制大对象（BLOB）类型。第一次验证简单的对比ZlibDataHeader中的预期CRC值和ZlibCompressedData计算出的CRC值检查Delta文件的ZlibCompressedData是否更改。



进一步的分析揭示了Defender解析各种操作的确切时间点。我们注意到2种操作类型：CopyFromDelta和CopyFromBase。CopyFromDelta用于从Delta中复制特定大小的字节进入合并流程。CopyFromBase用于从Base中的偏移量中复制特定大小的字节进入合并流程。我们写了一个脚本用于合并Base和Delta中的数据。我们同样可以识别出Defender用于验证目的的两个数：MergeSize和MergeCRC32。



在理解了整个合并、签名和验证过程后，我们准备用现有的知识测试并验证能否推送虚假的更新给WD。它成功了，我们能在无特权的情况下用虚假的未签名的数据库更新Defender。



利用Windows Defender

在理解WD更新过程并找到了伪造更新控制Defender的最佳方式后，我们决定以不同的方式验证我们的漏洞利用能力。为了验证并支持我们所有的攻击向量，我们开发了名为wd-pretender（Windows Defender Pretender 的缩写）的全自动工具。

攻击验证1：删除威胁LaZagne

LaZagne是一款开源的应用程序，用于检索本地计算机上存储的大量密码。我们先在未修改Defender的情况下下载并运行LaZagne，Defender立即识别并阻止了运行。使用wd-pretender更新签名数据库后，Defender不再检测此文件并允许执行



攻击验证2：FriendlyFiles

我们接下来将注意力转向了Defender特性之一的FriendlyFiles，这是Defender内置的的白名单。此功能使Defender知道如何按哈希允许特定的可执行文件完成其操作。这是一个很长的，包含很多哈希的列表。解析此列表后，我们注意到一个Oracle的虚拟盒运行库，我们想知道如果用已知的Mimikatz的哈希替换掉这个哈希会如何。

同样，最初下载Mimikatz时，Defender阻止了此操作。但我们使用wd-pretender推送替换了哈希的更新给WD后，我们不仅成功安装了Mimikatz，还成功提取了所有机器上保存的凭据。

攻击验证3：DoS拒绝服务

第三次也是最后一次的攻击验证我们验证了DoS。我们决定通过修改Emotet签名特征码，使其包含“DOS模式桩代码字符串”（所有PE文件的文件头），如果Defender识别到"!This program cannot be run in dos mode"字符串，它将自动删除它们。

我们向Defender推送了修改过后的签名更新。更新完成后，它立即向我们发出威胁警报。我们又让Defender扫描了整个PC的驱动文件夹。它报告了多个关键的的Windows文件为恶意软件并迅速删除了它们。我们尝试重启电脑，但无法执行，造成了永久的拒绝服务。



未来潜在的攻击路径——实现本地权限提升的可能性

在研究过程中，我们发现签名文件同样包含了大约3万个LUA语言脚本。微软使用了修改的LUA文件头，但我们可以对其进行反汇编并提取所有的LUA脚本。拥有了对整个源代码的访问权限，我们就能用我们修改过的代码替换运行代码，并进行权限提升。



供应商回复

我们通知了微软我们的发现，微软将此问题确认为CVE-2023-24934并立即采取行动发布了更新，在Microsoft Malware Protection Platform 4.18.2303.8版本及往后，所有的VDM数字证书签名都会被验证。

关键启示

·如果对手有足够的动机，即使最可靠的安全控制也可以被绕过。在攻击者利用这些安全措施之前，必须定期进行安全性测试并修复。
·数字证书的使用并不总是意味着安全性的提升。安全厂商有责任确保攻击者无法利用这些内置过程并为攻击者的利益服务
·基于恶意软件签名更新流程的漏洞攻击可能成为新的攻击路径。因此需要开展更多研究以确保此过程的安全性

总结

我们的研究意义重大，因为Windows Defender被多个组织应用，为了减轻影响，我们已经：

·向微软披露我们的研究成果。
·设计了用于验证此漏洞的工具，为进一步研究和攻击路径的开发奠定了基础
·于此和最近的BlackHat演讲中，我们同更广泛的安全社区分享了我们的研究成果，并希望用户保持警惕：即使最受信任的安全工具，也可以被有足够动机的攻击者攻破。

DisaPDB

反  复  鞭  尸  M  D