.Net Core库中存在一个安全漏洞，恶意程序可利用该漏洞避开安全软件的检测而启动。

该漏洞是Microsoft .Net Core库中的一个路径遍历漏洞，低权限用户可利用该路径遍历漏洞加载恶意垃圾回收器DLL。

该漏洞影响.Net Core最新稳定版本（3.1.x版本）。该漏洞当前还没有可用补丁，攻击者可利用该漏洞在系统上执行恶意代码，且不被反病毒和EDR产品检测到。

该漏洞是由Context Information Security公司的Paul Laîné 发现的，该漏洞存在的原因主要有两个：

.Net Core让用户使用自定义DLL作为其垃圾回收器

用于指定自定义.Net垃圾回收器的环境变量“COMPlus_GCName”未被过滤。因此，该垃圾回收器路径中提供的任何遍历字符（../）未能被过滤。

.Net Core使用一个‘垃圾回收器’分配和释放.Net Core应用程序使用的系统内存。

用户有可能自定义创建会被.Net Core应用程序加载的DLL垃圾回收器。

.Net Core允许任何用户，包括低权限的用户，加载自定义垃圾回收器DLL，甚至是包含恶意代码的DLL。

利用该漏洞

在利用该漏洞之前，攻击者需要获得至少一些系统访问权限，以设置环境变量。这意味着攻击者实际上会结合现有的漏洞利用该漏洞，例如在一个漏洞链场景中。

黑客将这种攻击纳入其工具包的主要动机是防止其恶意payload被运行在受入侵计算机上的安全软件检测到。

要利用该漏洞，攻击者首先要创建一个含有恶意代码的自定义垃圾回收器，攻击者将在受入侵的计算机上执行恶意代码。

随后，攻击者就会设置环境变量，造成.Net Core使用该自定义的DLL。

设置自定义垃圾回收器

源：Reddit

在加载时，该恶意代码会被合法的.Net Core进程dotnet.exe执行，该进程会认为该DLL只是一个自定义的垃圾回收器。

恶意垃圾回收器DLL示例

一旦该垃圾回收器DLL被.Net Core框架加载，该payload就开始执行，在这个案例中，该payload是一个反向TCP shell。

反向meterpreter shell被启动

在真实世界场景中，可访问受入侵计算机的攻击者可以使用简单的批处理脚本让.Net Core运行恶意DLL，而不被检测到。

为什么EDR产品无法检测到？

Pentest Laboratories的研究人员进一步分析了该漏洞，提供了另外的详情。

研究人员解释称，该漏洞利用了进程空心化（process hollowing）技术。

Pentest Laboratories在博文中解释道，“由于该进程是在挂起状态下创建的，Paul Laîné在他的PoC中使用了进程空心化技术将代码注入合法进程，内存区域未被映射到文件，并被实际的shellcode替换。”

由于执行该恶意代码是在合法的进程中进行的，因此该技术有助于避开安全软件产品使用的严格的检测和防御控制。

如何检测和修复规避代码执行？

Pentest Laboratories的研究人员提供了几种策略来检测是否该漏洞遭到滥用。

虽然几乎不可能预测该恶意垃圾回收器DLL驻留在系统上的位置，但环境变量“COMPlus_GCName”仍然是一个固定的字符串，可以被监视。

使用自定义垃圾回收器的进程

源：Pentest Laboratories

研究人员指出，“即便该DLL文件的名称，该路径，该进程和该.Net应用程序是任意的，‘COMPlus_GCName’仍是一个固定的字符串。”

研究人员提供了一个YARA规则，可用于监测回避过程中的“COMPlus_GCName”实例：

检测.Net Core回避的YARA规则

源：Pentest Laboratories

此外，研究人员还提供了Sysmon事件ID，这些ID是在该漏洞遭到主动利用的环境中顺序创建的。

该.Net Core漏洞创建的Sysmon事件

源：Pentest Laboratories

Microsoft不认为是漏洞

由于利用这种机制需要攻击者已经具备在受入侵系统上设置环境变量的能力，微软不认为这是一个安全漏洞：

“根据MSRC，我们不认为这是个安全漏洞。利用该漏洞需要攻击者修改环境块，此时他们已经控制了应用程序执行的其他方面。”Microsoft的代表在Laîné报告的GitHub问题中指出。

Laîné在他最初的披露中承认，“能够使用自定义GC是一个合法的特性，可能不应该被移除。但是，应该解决该路径遍历漏洞，以便自定义GC的使用仅限于具有本地管理员权限的用户，这对于服务器端应用程序或开发环境应该是如此。”

考虑到这一“合法”特性并没有简单的解决办法，在重.Net企业环境中仍然存在滥用的可能性。

参考来源：

Bleeping Computer