正文

Windows .NET Core SDK权限提升漏洞分析

admin
admin V管理员 /0 评论 /14 阅读
0321
此篇文章发布距今已超过1195天，您需要注意文章的内容或图片是否可用！

 

0x00 概述

在DotNet Core Toolset安装程序中，存在一个奇怪的漏洞，该漏洞允许任何本地用户将其特权提升为SYSTEM。在这篇文章中，我将详细分析这个漏洞，尽管Microsoft没有将它认定为实际的漏洞，但是他们还是在暗中进行了（部分）修复。

 

0x01 背景介绍

2020年3月，Jonaslyk告诉我他在自己的计算机上遇到一个奇怪的错误。SYSTEM的PATH环境变量中似乎增加了与DotNet相关的路径。但奇怪的是，这个路径指向了非管理员用户的文件夹。基于此，我在自己的计算机上进行了检查，发现尽管存在与DotNet相关的路径，但它指向的是本地admin文件夹。如果用户拥有的文件夹的路径可以被附加到这个环境变量中，那么代码将可以以SYSTEM的身份来执行。因此，我们决定进行更深入的分析，看看最终能够实现什么。

 

0x02 初始设置

我们使用全新安装的Windows 10作为测试环境。在初始状态下，下面是SYSTEM帐户的PATH环境变量默认值。其中，S-1-5-18是LocalSystem帐户的安全标识符（SID）。

reg query "HKU\S-1-5-18\Environment" /v Path

然后，我们安装了Visual Studio Community 2019。安装过程中，我们选择包含.Net桌面开发组件。

点击“Install”按钮后，将下载并安装软件包。

由于我们需要寻找注册表项的修改情况，因此在这里使用Process Monitor来监视后台发生的事情。

在安装“.Net Core toolset”后，事情开始变得有趣。我们可以看到一个RegSetValue操作，是来自HKU\.DEFAULT\Environment\PATH中一个名为dotnet.exe的可执行文件。在这个事件之后，我们发现HKU\S-1-5-18\Environment中的PATH值与之前有所不同。

在这里，我们注意到存在两个潜在的问题：

1、变量%USERPROFILE%解析为当前用户的主文件夹，而不是SYSTEM帐户的主文件夹。

2、指向用户拥有的文件夹的另一个路径被添加到SYSTEM帐户的PATH中。

我们当前的用户还是本地管理员，因此这样的修改其影响非常有限。不过，理论上不应该发生这样的情况，因为这两个潜在的问题可能会产生意想不到的副作用（例如：UAC绕过）。

如果大家阅读过@RedVuln的《.Net系统持久性/绕过UAC/特权提升》这篇文章，可能会感觉这里的场景似曾相识。看上去，他几乎是在与我们相同的时间发现了这个问题。但我们还有一个疑问，因为DotNet SDK的安装需要一定的特权，所以是仅有管理员才能实现上述这个过程，还是普通用户也可以？

 

0x03 实际的特权提升漏洞

在上一章中，我们看到.Net SDK的安装过程对SYSTEM帐户的Path环境变量产生了一些潜在的意外后果。不过，严格来说，这并不会导致特权提升。

但是，如果我告诉大家，使用不具有管理员权限的普通用户身份登录时，也能够复现出同样的行为，这是不是意义就不一样了？

安装Visual Studio后，会将几个MSI文件复制到C:\Windows\Installer文件夹。由于我们观察到RegSetValue操作源自名为dotnet.exe的可执行文件，因此我们可以尝试在这些文件中搜索字符串。这是使用findstr命令得到的结果。

cd "C:\Windows\Installer"
findstr /I /M "dotnet.exe" "*.msi"

不错。我们找到了两个匹配的。接下来，可以尝试使用命令msiexec /qn /a <FILE>以普通用户身份运行每个文件，并观察注册表中SYSTEM帐户的环境Path变量。

在运行第一个MSI文件时，我们发现没有任何变化。但是，在运行第二个MSI文件时，我们观察到此时与以管理员身份安装DotNet SDK时发生的操作完全相同。

不过这一次，由于MSI文件是由用户lab-user运行的，因此路径C:\Users\lab-user\.dotnet\tools会附加到SYSTEM帐户的PATH环境变量中。因此，该用户现在可以植入DLL，并等待服务加载DLL，从而以SYSTEM身份执行代码。在Windows 10上，这个过程可以通过劫持由任务计划程序服务在启动时加载的WptsExtensions.dll来实现，@RedVuln在他的文章中曾进行过描述。

 

0x04 根本原因分析

这个漏洞的利用非常简单，因此我将重点放在根本原因分析上，这对于我们来说非常有趣。

问题是：我们从哪里开始？既然如此，不如从头开始，首先看看slightly_smiling_face：

我们有一个Process Monitor转储文件，其中包含我们关注的RegSetValue事件。这是一个很好的起点，我们可以看看能够从栈跟踪里面学到什么。

我们可以看到，dotnet.exe可执行文件加载了几个DLL，然后加载了几个.Net程序集。

查看Process Start操作的详细信息，我们可以看到以下命令行：

"C:\Program Files\dotnet\\dotnet.exe" exec "C:\Program Files\dotnet\\sdk\3.1.200\dotnet.dll" internal-reportinstallsuccess ""

根据这个命令行，我们可以假设Win32 dotnet.exe可执行文件实际上是dotnet.dll程序集的包装，这个程序集有以下参数：internalreportinstallsuccess 。

因此，对其进行逆向，可以找到所有问题的答案：

1、可执行文件是如何评估.Net Core工具路径？

2、可执行文件如何在注册表中将路径添加到SYSTEM帐户的PATH？

为了检查程序集，我使用了dnSpy。实际上，这是我迄今为止在进行这类工作时最好用的工具。

程序的Main通过调用Program.ProcessArgs()开始。

这个函数有几个功能，其中最重要的部分我们以红色进行标记。

实际上，名称为ConfigureDotNetForFirstTimeUse()的函数看起来像是值得进一步分析的函数。

通过查看函数的内容，我们可以确认这一假设，因为我们开始看到一些对“环境路径”的引用。

根据依赖的操作系统，方法CreateEnvironmentPath()创建实现IEnvironmentProvider接口的对象的实例。因此，这里将是一个新的WindowsEnvironmentPath对象。

该对象基于动态生成的路径实例化，这个路径由某些字符串和“工具”的串联组成。

这个DotnetUserProfileFolderPath字符串本身是其他字符串和“.dotnet”的串联。

DotnetHomePath字符串是基于环境变量的值生成的。

变量的名称取决于PlateformHomeVariableName，由于操作系统是Windows，因此这里是USERPROFILE。

总结之前的分析，我们知道DotNet工具的路径符合以下形式：<ENV.USERPROFILE>\.dotnet\tools，其中ENV.USERPROFILE的值由Environment.GetEnvironmentVariable()返回。到目前为止，这与我们在Process Monitor中观察到的一致，因此我们必须走上正确的道路。

如果查看Environment.GetEnvironmentVariable()的文档，可以了解到，默认情况下，如果未指定EnvironmentVariableTarget，则会从当前进程中检索这个值。

现在，如果再次查看Process Monitor中“Process Start”的详细信息，可以发现该进程使用了当前用户的环境，尽管该进程以NT AUTHORITY\SYSTEM的身份运行。因此，最终的工具路径解析为C:\Users\lab-user\.dotnet\tools。

现在，我们知道了如何确定路径，因此就有了第一个问题的答案。接下来，需要找到这个路径的处理方式。
要回答第二个问题，可以返回Program.ConfigureDotNetForFirstTimeUse()方法，并查看在调用CreateEnvironmentPath()函数之后执行的操作。

确定工具路径后，将创建一个新的DotnetFirstTimeUseConfigurer对象，并立即调用Configure()方法。此时，路径信息存储在由pathAdder变量标识的EnvironmentPath对象中。

在这个方法中，相关的代码在下面的屏幕截图中以红色标示出，其中调用了AddPackageExecutablePath()方法。

这个方法很简单。在EnvironmentPath对象上调用AddPackageExecutablePathToUserPath()方法。

最后，AddPackageExecutablePathToUserPath()方法的内容为我们提供了第二个问题的答案。

首先，这个方法检查PATH环境变量的值，但是这次，使用一种稍有不同的方法进行检索。它使用附加的EnvironmentVariableTarget参数（设置为1）调用GetEnvironmentVariable。

从文档中可以看出，如果将这个参数设置为1，则会从HKEY_CURRENT_USER\Environment注册表项中检索该值。当前用户为NT AUTHORITY\SYSTEM，这个值从HKU\S-1-5-18\Environment中检索。

问题在于，这同样也适用于SetEnvironmentVariable()方法。因此，C:\Users\lab-user\.dotnet\tools\将附加到注册表LOCAL SYSTEM帐户的路径环境变量之中。

总而言之，.Net Core工具集路径时基于当前用户的环境创建的，但由于该进程以NT AUTHORITY\SYSTEM的身份运行，因此已经应用到注册表中的LOCAL SYSTEM帐户，因此存在漏洞。

 

0x05 总结

这个漏洞的当前修复状态尚不清楚。由于没有得到Microsoft的官方认可，因此没有将该漏洞分配CVE ID。但是，正如前言中所述，Microsoft已经对这个漏洞进行部分修复。如果我们使用最新版本的.NET Core安装程序，C:\Users\<USER>\.dotnet\tools路径将不会再添加到路径中。

那么，如何确保计算机不受到这一漏洞影响呢？

首先，在注册表中检查以下值：

C:\Windows\System32>reg query HKU\S-1-5-18\Environment /v Path

HKEY_USERS\S-1-5-18\Environment
    Path    REG_EXPAND_SZ    %USERPROFILE%\AppData\Local\Microsoft\WindowsApps;

如果我们看到实际内容与上面显示的内容有所不同，则可以以管理员身份使用以下命令来恢复默认值：

C:\Windows\System32>reg ADD HKU\S-1-5-18\Environment /v Path /d "%USERPROFILE%\AppData\Local\Microsoft\WindowsApps;" /F
The operation completed successfully.

然后，我们可以更新Visual Studio或.Net SDK，并再次检查注册表。“tools”文件夹应该不会再存在。
遗憾的是，根据我的最新测试，%USERPROFILE%变量仍然解析为当前用户的“home”文件夹。这意味着，在安装.Net SDK时，路径仍然会更改。值得庆幸的是，这个文件夹不能用于本地特权提升，因为相应的文件夹属于管理员所有。

 

0x06 参考资料

[1] .Net系统持久性/绕过UAC/特权提升 https://redvuln.com/net_privesc/
[2] dnSpy https://github.com/0xd4d/dnSpy