有人公开了Avast、McAfee 等杀软中的 8 个 0day

最新推荐文章于 2025-04-20 08:31:21 发布

奇安信代码卫士

最新推荐文章于 2025-04-20 08:31:21 发布

阅读量1.2k

点赞数

文章标签： python java 安全编程语言 windows

原文链接：https://codesafe.qianxin.com/#/home

版权

聚焦源代码安全，网罗国内外最新资讯！

昵称为 halov 的安全研究员今天发布了 Avast、McAfee 等杀毒软件的8个0day，给出的理由是 “我能做到，而且我需要一份工作”。如下是全文：

我将披露8个 0day 的详情而且这些均未报告给厂商。厂商可能会发布紧急补丁，修复这些漏洞，因此它们起作用的时间大概只有一两周。

Avast

（1）沙箱逃逸

Avast（任意付费版本）杀毒软件中都具有一个功能，名为 Avast sandbox。该功能可供用户在沙箱内测试可疑文件。但这个沙箱和我所知的任何其它沙箱都不同：比如运行在特殊容器中的 Windows 沙箱应用，或者在令牌中应用一些缓解措施（如降低令牌的完整性、应用创建进程的缓解措施等）以及在虚拟机中实际运行可疑文件以便使文件完全隔离的沙箱。Avast 沙箱完全不同，沙箱app 在操作系统中运行且沙箱 app 令牌中的安全缓解措施很少，如删除某些权限像 SeDebugPrivilege、SeShutdownPrivilege……虽然仍然保持了令牌的完整性，但这还不足以成为一个沙箱。Avast 沙箱实际上创建了一种虚拟化的文件流且注册表实体文件几乎和真实文件完全一样，同时它强制被沙箱的 app 通过 hook 每个 WINAP 调用的方式使用虚拟化流。这样做虽然听起来很酷，但也是不可能实现的，任何不完整的 hook 都会导致沙箱逃逸。

该虚拟化文件流位于 “C:\avast! sandbox” 中。

虚拟化的注册表实体文件存在于 “H****\_avast! Sandbox”中，看似 “\snx-av\” 中也存在一个虚拟化的对象管理器中。

所以，正常情况下要实现逃逸，我应当阅读任何和 avast 沙箱逃逸相关的write-ups。一番搜索后，我发现了 CVE-2016-4025 和谷歌 Project Zero 发现的另外一个 bug (https://bugs.chromium.org/p/project-zero/issues/detail?id=700）。

Nettitude Labs 构建了 DeviceIoControll 调用，以逃逸虚拟化。使用 notepad 的“另存为”功能后，他们发现实际保存的文件位于沙箱之外（位于真实的文件系统中），这种方式看似是我的菜。

我点击了“另存为”但并不起作用，因为补丁禁用了该功能，于是我点击了“Print”。

之后我们得到了一个弹出消息，因此正常情况下我点击了默认打印机 “Microsoft XPS Document Writer” 的 print。

之后，我们就得到了“另存为“窗口。

点击“保存“，竟然发生了意想不到的事情：

该文件位于虚拟化文件流之外，很明显是一个沙箱逃逸问题。

这是怎么造成的？似乎是一个外部进程在模拟 notepad 的访问令牌写了该文件。幸运的是，从发生 CVE-2020-1337 漏洞后，我就一直在阅读微软提供的所有文档，学习该 Printer API，同时 James Forshaw 也发布了一些和使用 Printer API 造成 Windows 沙箱逃逸的文章(https://bugs.chromium.org/p/project-zero/issues/detail?id=1413)。

所以我认为，如果我们能设法正确地调用 Printer API，则能轻易逃逸沙箱，所以我们先从 OpenPrinter 函数入手：

当然，我们会在存在于标准 Windows 安装程序 “Microsoft XPS Document Writer” 上的默认打印机 pPrinterName 中具体说明。

接着，我们将分析 StartDocPrinter 函数，从而准备关于打印文档；第三个函数看似起着重要作用。

所以，我们将查看 DOC_INFO_1 结构，发现一些不错的消息。

看似第二个成员可使我们指定实际的文件名称，这可能是我们逃逸 Avast 沙箱的出路。

所以，现在的情况是，我们很可能看到沙箱之外的文件，但写入文件尚未实现。进一步研究后我发现了另外一个和 WriteFile 作用一样的函数：WritePrinter。

因此，最终结果是：

备注：该漏洞已告知厂商，但他们并未答复。

（2） 提权

提权漏洞并不容易找到，不过花了一些时间后，我从 Avast 的一个功能 “REPAIR APP” 中找到了。点击该功能会发现 Avast Antivirus Engine 会创建一个新的子进程 “Instup.exe”。

尝试修复该 app 后，很可能这里有一些值得看的地方。在这个请看下，我们需要使用一款工具 Process Monitor。

我们又发现了一些值得关注的东西。Instup 进程正在查找某些并不存在的目录 C:\stage0 和 c:\stage1。

但如果它们存在会怎么样？

我通过子文件的形式创建了 c:\stage0 目录并观察 instup.exe 将如何行动，结果发现了一个异常行为：它并非只是删除或忽略文件，而是创建了该文件的硬链接。

虽然我们可利用该问题，但问题在于该硬链接具有一个随机名称且通过猜测这个名称可以将创建重定向到一个任意位置，但遗憾的是该硬链接随机名称非常难猜，因此我决定另寻他处。

在硬链接创建的进程末尾，可以看到它们均被标记为“删除“，或许我们可以滥用这个问题，实现一个任意文件删除漏洞。

我为该问题创建了一个 exploit，该 exploit 在 c:\stage0 中创建了一个文件并继续查找该硬链接。当硬链接创建后，poc 会在 instup 试图删除时 OPLock，之后，该 poc 将移走该文件并将 c:\stage0 连接至 “\RPC CONTROL\”，我们将创建一个符号链接，将文件删除重定向至一个任意文件。

备注：该漏洞并未提交给厂商。

PoC 见：https://github.com/klinix5/blog-stuff/tree/main/Avast

McAfee Total Security

(1) 提权

之前我从该杀软中找到几个漏洞并获得致谢。

CVE-2020-7279 和 CVE-2020-7282：

CVE-2020-7282 是一个任意文件删除漏洞，CVE-2020-7279 是一个自我防御绕过漏洞。从 C:\ProgramData\McAfee\Update 创建一个和任意位置的连接可导致任意文件删除后果，McAfee 通过强制 McAfee Total Security Updater 处理重新解析点的方式提供了补丁。

最重要的点在于，C:\ProgramData\McAfee\Update 实际上受自我防御驱动的保护，因此即使管理员无法在该目录中创建文件也不例外。打开 GENERIC_WRITE 访问的目录，之后创建目标目录的安装点，Updater 启动后，目标目录的子内容就会被删除，从而造成绕过问题。

不过现在的情况有所改变，目前的目录中拥有子内容（此前默认为空）。

我花了一些时间分析了这个自我防御漏洞是如何修复的。他们并没有通过 GENERIC_WRITE 阻止目录被打开，而是阻止如下控制代码 FSCTL_SET_REPARSE_POINT 和 FSCTL_SET_REPARSE_POINT_EX 在受保护的文件系统组件中被调用。该修复方案很好，所以如果我们无法绕过自我防御，则不会对该组件造成任何实际影响。

事情就是这样了，或者有转机？

绕过自我防御的新方法

该方法适用于所有具有文件系统过滤功能的杀毒软件。

那么，内核过滤器是如何运作的？

文件系统过滤器限制对该杀软所有的对象的访问，方法是拦截用户模式文件 I/O 请求：如果请求源自杀软组件，则会获得该权限；否则将返回访问拒绝。

由于目前尚未公布，因此我将不会披露详情。

截至目前，我知道的过滤器绕过方法有两种：

1、构造一个特殊调用，和驱动所看到的相悖

2、从受保护组件中请求访问权限

由于第一种方法已在 CVE-2020-7279 中修复，因此只剩下第二种方法。我们该如何实现？该杀软的大部分 GUI 支持文件对话进行选择，我们以 McAfee 文件粉碎机为例，它打开一个文件对话，让用户做出选择。

虽然该文件对话用于挑选文件，但也可被用于攻击该杀软；为更好地理解这一点，我们需要创建一个示例代码，因此必须查找微软提供的 API。一般而言，应用使用的或者是 GetOpenFileNameW，或者是 IFileDialog 接口，由于 GetOpenFileNameW 似乎已被弃用，因此我们将集中介绍 IFileDialog 接口。

于是，我创建了一个样本代码。

运行代码后：

似乎是从进程而非外部进程（如 explorer）完成的任务，因此从技术角度讲，我们所做的任何事情符合进程设置。不过，如果是由进程完成的，不就意味着我们可以在受保护的位置创建一个文件夹吗？是的，我们可以这样做。

武器化自我保护绕过

CVE-2020-7282 补丁是在设法删除目录前针对重新解析点的简单检查。我们需要做一个简单的检查：如果目录上的 FSCTL_GET_REPARSE_POINT 控制返回除 STATUS_NOT_A_REPARSE_POINT的内容，则目标将被删除，否则该 Updater 讲删除子内容 “NT AUTHORITY\SUSTEM”。

链接一下，我就得到了可演示该 bug 的 exploit：首先是 C:\UPDMGR 中的一个目录将被创建，之后应当手动将其移动到 C:\ProgramData\McAfee\Update，机会锁讲触发该 PoC，在目标中创建一个重新解析点，一旦 AV GUI 试图移动该文件夹，该 PoC 将把它设置到重解析点并锁定移动的目录，从而阻止重解析点删除。

PoC 见：https://github.com/klinix5/blog-stuff/tree/main/McAfee

Avira 杀软

我将在 Avira Prime 上做测试，说实话，Avira 的下载速度是最快的。其它厂商在提供试用之前就逼得让人想撞墙了，所以披露这个漏洞我有一点不忍。

言归正传，Avira Prime 具有一种功能，名为 “Avira System Speedup Pro”。虽然我现在仍然无法解释这种行为为何会存在 Avira System Speedup 功能中，但它确实存在。

启动 Avira System Speedup Pro GUI 时，“Avira.SystemSpeedup.Service.exe” 会执行初始化操作。该服务是用 C# 编写的，使其更容易逆向但我逆向之后发现有一些不对劲的地方，于是我像最好是通过展示进程监控输出来理解该问题。

打开 GUI 时，我假设 GUI 和该服务之间存在 RPC 通信来做出所要求的初始化，以满足用户需求。该服务启动初始化进程时，将在未检查重解析点的情况下创建并删除 C:\Windows\Temp\Avira.SystemSpeedup.Service.madExcept 中的目录。滥用该问题及其容易。

这次，我并未使用 C++ 编写 PoC，而是用 batch 脚本写了一个简单的 PoC。该案例中的 PoC 并不要求任何用户交互，而且将会删除目标目录子内容。

PoC 可见：https://github.com/klinix5/blog-stuff/tree/main/Avira

趋势科技 Maximum security

它是我见过的最佳杀软之一，不过遗憾的是这次漏洞披露让我把它也拉入了黑名单。

我之前在趋势科技杀软中已经发现了一个问题，并已在CVE-2020-25775中修复。我发现了一个高危漏洞，但约定在先，因此无法在这里披露。

由于其它杀软中也有“个人电脑健康体检”功能，因此或许应该引起我们的注意。

在浏览该组件时，我注意到一个名为“Clean Privacy Data（清除隐私数据）” 的功能。

点击 MS Edge 浏览器并清理，进程监控的输出如下：

我们可以看到，趋势科技 Platinum Host Service 正在删除用户可写位置的目录，但在以“NT AUTHORITY\SYSTEM” 运行时并未对重解析点进行正确的检查，因此可轻易被滥用于删除任意文件。

我用 batch 脚本的方式创建了一个 PoC，运行后应该会删除目标目录子内容。

PoC 见：https://github.com/klinix5/blog-stuff/tree/main/Trend%20Micro

MalwareBytes

这又是一个不错的杀软，我也在用。5个月前我找到了一个 bug，但至今仍未修复，不过已颁发奖金。虽然现在我无法披露，但还是有一些东西可以分享。我还是通过上述提到的技术绕过自我保护措施。

在检查更新时，该杀软正在查找一个不存在的目录。

我们看一下

上图表明 Malwarebytes 杀软引擎正在删除 C:\ProgramData\Malwarebytes\MBAMService\ctlrupdate\test.txt.txt 的所有子内容，由于未假冒用户且未对重解析点进行正确的检查，因此我们或许可以利用这一点，方法是创建一个目录并在 C:\ProgramData\Malwarebytes\MBAMService\ctlrupdate 中创建一个重解析点，这样我们就能将文件删除重定向到一个任意位置。

PoC 见：https://github.com/klinix5/blog-stuff/tree/main/Malwarebytes。

卡巴斯基

这是我使用频率最高的一款杀软，我报告了11个漏洞，其中3个已修复。

当前我将讨论我已披露的一个漏洞 (https://github.com/klinix5/Kaspersky_Safe_Money_LPE)。PoC 将生成一个 SYSTEM shell。虽然2020年12月的补丁已发布，但该漏洞似乎仍然存在于卡巴斯基Total Security 中。唯一的问题是，该杀软将把该 exploit 检测为恶意软件，我们必须做一些修改，以阻止 exploit 被删除。目前我确认该问题仍然存在。

另外一个问题

从卡巴杀软中我发现了另外一个漏洞，可导致在无需用户交互的情况下覆盖任意文件。我已将该漏洞告知卡巴，但尚未获得奖金。

卡巴表示该漏洞不符合漏洞奖励计划条件，原因是漏洞复现不稳定。说实话我提供的 PoC 确实很糟糕，不过还是可以用的，因此我猜测应该会给我发奖金的，我才不会像傻瓜一样白提交漏洞呢。

我们来深挖一下该漏洞。任意用户启动 Mozilla 火狐浏览器器时，卡巴斯基在 %Firefox_Dir%\defaults\pref 中写入特殊内容，但不会以用户身份写入甚至都不会执行正确的链接检查。如遭滥用，则可导致在无需用户交互的情况下，按需覆盖任意文件。

PoC：https://github.com/klinix5/blog-stuff/tree/main/Kaspersky

Windows

本来打算披露 Eset 和 Bitdefender 中的漏洞，但由于时间有限，所以这是最后一个了。

首先，说下背景，这是我第六次绕过微软 Windows Installer 中的漏洞 CVE-2020-16902了，但现在漏洞仍未完全修复。

微软通过检查 c:\config.msi 是否存在，如不存在则会生成回滚目录，否则如存在，则 c:\windows\installer\config.msi 将被用作生成回滚文件的文件夹。

Sandboxescaper 发推文称，如果在安装开始时，存在注册表键 “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\Folders\C:\Config.Msi”，则该 Windows 安装程序将使用 c:\config.msi 作为目录回滚文件。作为一个低权限用户，我认为无法阻止 “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\Folders\C:\Config.Msi” 的删除和创建。

还有一些地方值得我们注意：