.NET Core 库中存在一个漏洞，可导致恶意程序躲避安全软件的检测。
该漏洞是由微软 .NET Core 库中的一个路径遍历bug 造成的，可导致低权限用户加载恶意垃圾回收器 DLL。该 bug 影响最新的稳定版本 .NET Core 3.1.x。目前尚不存在补丁，它可导致攻击者在系统上执行恶意代码，而不会被反病毒软件和 EDR 产品检测到。
Context 信息安全公司的研究员 Paul Laîné 发现了这个漏洞，它可能是由两个主要原因造成的：
.NET Core 允许用户使用自定义 DLL 作为垃圾回收器。
用于指定自定义 .NET 垃圾回收站器环境变量 “COMPlus_GCName” 未经过清理。因此垃圾回收器路径中的遍历字符 (../) 未经过滤。
.NET Core 使用“垃圾回收器”分配并释放由一个 .NET Core 应用使用的系统内存。然而，用户很可能以由 .NET Core 应用加载的 DLL 格式创建自定义垃圾回收器。
但 .NET Core 允许任何用户（包括低权限用户）加载一个自定义垃圾回收器 DLL，即使是包含恶意代码的 DLL 也不例外。
Bug 利用
在利用这个缺陷之前，攻击者已经需要至少拥有对系统某种级别的访问权限设置环境变量。也就是说这个缺陷实际上可结合一个已存在的 exploit 使用，如在漏洞链接场景中。
黑客在工具集中集成该攻击的主要动力在于阻止在受陷机器上运行的安全软件检测到其恶意 payload。要利用这个 bug，攻击者首先需要创建包含他们想在受陷机器上执行的恶意代码的自定义垃圾回收器，之后设置一个环境变量，引发 .NET Core 使用这个自定义 DLL。
恶意代码被加载后将被合法的 .NET Core 进程 dotnet.exe 执行，使用户认为 DLL 仅仅是一个定制化的垃圾回收器。
.NET Core 框架加载该垃圾回收器 DLL 后，payload 开始执行，在本案例中它是一个反向 TCP shell。
在真实场景中，能够访问受陷机器的攻击者能使用简单的 batch 脚本使 .NET Core 运行恶意 DLL而无需被检测到。
EDR 产品为何无法检测？
Pentest Laboratories 公司的研究人员进一步分析了该漏洞并提供了进一步的洞见。
研究人员解释称，该 exploit 使用的是process hollowing 技术。Pentest Laboratories 发表博客文章指出，“Paul Laîné 在 PoC 中使用 process hollowing 技术将代码注入合法进程中。由于该进程在挂起状态创建，内存区域并未被映射到文件并被实际的 shellcode 取代。”由于恶意代码执行发生在合法进程下，因此这种技术可用于躲避安全软件产品应用的严格的检测和防御控制。
检测和修复
研究人员提供了检测漏洞是否遭利用的多种战略。虽然几乎无法预测恶意垃圾检测器 DLL 在系统上的具体位置，但环境变量 “COMPlus_GCName” 仍然是一个固定的字符串且可被监控。
研究人员表示，“即使 DLL 文件、路径、进程和 .NET 应用的名称完全是任意的，但 ‘COMPlus_GCName’ 是一个固定的字符串。”研究人员提供了一种 YARA 规则，可用于监控躲避进程中的 “COMPlus_GCName’ 实例：
另外，研究人员已提供 Sysmon 事件 ID，它们是在漏洞遭活跃利用的环境中被顺序创建的。
微软：不是漏洞
由于利用该机制要求攻击者已经具有在受陷系统上设置环境变量的能力，因此微软认为它并非漏洞。
微软的一名代表在Laîné 报告的 GitHub issue 中表示，“MSRC 认为它并非安全漏洞。利用它要求攻击者能够修改环境块，而这时攻击者已经能够控制应用执行的其它方面。”
Laîné 在最初的漏洞披露文章中指出，“使用自定义 GC 是一个合法功能，很可能不应该被删除。然而，路径遍历漏洞应该得到解决，以便仅限具有本地管理员权限的用户使用自定义 GC，这应该是服务器端应用或开发环境中的情况。”
鉴于目前尚不存在该“合法”功能的修复方案，因此 .NET 企业环境中人可能出现滥用情况。
原文链接
https://www.bleepingcomputer.com/news/security/net-core-vulnerability-lets-attackers-evade-malware-detection/
声明：本文来自代码卫士，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
