• Welcome to the world's largest Chinese hacker forum

    Welcome to the world's largest Chinese hacker forum, our forum registration is open! You can now register for technical communication with us, this is a free and open to the world of the BBS, we founded the purpose for the study of network security, please don't release business of black/grey, or on the BBS posts, to seek help hacker if violations, we will permanently frozen your IP and account, thank you for your cooperation. Hacker attack and defense cracking or network Security

    business please click here: Creation Security  From CNHACKTEAM

Windows .Net Core SDK权限


This Wind

Recommended Posts

DotNet Core Toolset安装程序中存在一个奇怪的错误,该错误允许任何本地用户将其特权提升为SYSTEM。在此博客文章中,我想分享此Bug的详细信息,尽管该漏洞没有被Microsoft确认为漏洞,但该漏洞已被默默(但仅部分修复)了。

介绍

2020年3月,乔纳斯里克(Jonaslyk)告诉我他在个人计算机上遇到的一个奇怪的错误。SYSTEM的PATH环境变量中填充了一个似乎与DotNet相关的路径。奇怪的是,该路径指向非管理员用户文件夹。因此,我在自己的计算机上进行了检查,但是,尽管存在与DotNet相关的路径,但它指向的是本地admin文件夹。无论如何,如果可以将用户拥有的文件夹的路径附加到此环境变量中,则意味着代码以SYSTEM的身份执行。因此,我们决定在这个奇怪的情况下共同努力,看看我们能想到什么。

初始设置

我们从全新安装Windows 10开始进行全新安装。在此初始状态下,这是SYSTEM帐户的PATH环境变量的默认值。提醒您的S-1-5-18LocalSystem帐户的安全标识符(SID)。

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

01_path-key-default-value.png

然后我们安装了Visual Studio Community 2019link)。安装完成后,我们在安装程序中选择.Net桌面开发组件。

02_visual-studio-installer.png

单击“安装”按钮后,将下载并安装软件包。

03_visual-studio-installer-dotnet.png

我们正在寻找一个注册表项修改,以便我们可以使用Process Monitor来轻松监视后台发生的事情。

04_procmon-regsetvalue.png

安装“ .Net Core工具集”后,事情变得很有趣。我们可以看到一个RegSetValue源自可执行文件dotnet.exeon的操作HKU\.DEFAULT\Environment\PATH。在此事件之后,我们可以看到PATHin的值 HKU\S-1-5-18\Environment确实不同。

05_regkey-modification.png

我们可能在这里注意到两个潜在的问题:

  1. 变量%USERPROFILE%解析为当前用户的主文件夹,而不是SYSTEM帐户的主文件夹。
  2. 再次指向用户拥有的文件夹的另一条路径被追加到SYSTEM帐户的PATH

在这两种情况下,当前用户是本地管理员,因此这种修改的后果受到一定程度的限制。但是,不应将它们发生,因为它们可能会产生意外的副作用(例如:UAC旁路)。

读完这篇文章后,您可能会感到似曾相识。如果是这样,则意味着您可能在某个时候偶然发现了@RedVuln的这篇文章:.Net系统持久性/绕过/ Privesc。看起来他几乎是在乔纳斯和我正在研究的同时发现了这个错误。但是有一个问题,所有这些都只能以管理员身份来实现,因为DotNet SDK的安装需要此类特权。还是呢?

实际特权升级漏洞

在上一部分中,我们看到.Net SDK的安装过程对SYSTEM帐户的Path Environment变量产生了一些潜在的意外后果。尽管严格来讲,这不会导致特权提升。

但是,如果我告诉过您,以没有管理员权限的普通用户身份登录时可以重现相同的行为该怎么办?

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

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

08_findstr-msi-dotnet.png

大!我们有两场比赛。我们接下来要做的是尝试使用命令以普通用户身份运行每个文件,msiexec /qn /a <FILE>并观察注册表中SYSTEM帐户的Environment Path变量的结果。

运行第一个MSI文件,我们看不到任何东西。但是,运行第二个MSI文件时,我们观察到与以管理员身份安装DotNet SDK时最初发生的操作完全相同。

07_procmon-poc.png

但是,这一次,由于MSI文件是由用户运行的lab-user,因此该路径C:\Users\lab-user\.dotnet\tools将附加到SYSTEM帐户的PATH环境变量中。结果,该用户现在可以通过植入DLL并等待服务加载它来以SYSTEM身份执行代码。这可以在Windows 10上通过劫持WptsExtensions.dll由Task Scheduler服务在启动时加载的DLL来实现,如@RedVuln在其帖子中所述。

根本原因分析

该漏洞的利用是微不足道的,因此我将重点放在根本原因分析上,这对我来说非常有趣。

问题是:我们从哪里开始?好吧,让我们从头开始...:slightly_smiling_face:

我们有一个Process Monitor转储文件,其中包含RegSetValue我们感兴趣的事件。这是一个很好的起点。让我们看看我们可以从堆栈跟踪中学到什么。

10_10_analysis-stack-trace.png

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

10_11_analysis-dotnet-exe-start.png

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

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

从此命令行,我们可以假定Win32dotnet.exe可执行文件实际上是该程序dotnet.dll集的包装,该程序加载了以下参数:internalreportinstallsuccess ""

因此,颠倒该程序集应该为我们提供我们正在寻找的所有答案:

  1. 可执行文件如何评估.Net Core工具路径?
  2. 可执行文件如何PATH在注册表中将路径添加到SYSTEM帐户?

为了检查该程序集,我使用了dnSpy。到目前为止,这绝对是我迄今为止用于此类任务的最佳工具。

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

10_12_analysis-dotnet-dll-program-main.p

此功能发生了几件事,但最重要的部分在下面的屏幕截图中以红色框起。

10_13_analysis-dotnet-dll-program-config

确实,带有名称的功能ConfigureDotNetForFirstTimeUse()看起来像是继续进行调查的不错的选择。

10_14_analysis-dotnet-dll-Program-Config

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

10_15_analysis-dotnet-dll-ToolsShimPath.

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

该对象是根据动态生成的路径实例化的,该路径是由一些字符串和的串联形成的"tools"

10_16_analysis-dotnet-dll-GetToolsShimPa

DotnetUserProfileFolderPath字符串本身是其他一些字符串和的串联".dotnet"

10_17_analysis-dotnet-dll-DotnetUserProf

DotnetHomePath字符串是根据环境变量的值生成的。

10_18_analysis-dll-dotnet-DotnetHomePath

变量的名称取决于PlateformHomeVariableName"USERPROFILE"因为操作系统是Windows ,所以该名称在此处。

10_19_analysis-dotnet-dll-PlatformHomeVa

总结分析的第一部分,我们知道DotNet工具的路径遵循以下方案:<ENV.USERPROFILE>\.dotnet\tools,其中的值由ENV.USERPROFILE返回Environment.GetEnvironmentVariable()。到目前为止,这与我们在Process Monitor中观察到的一致,因此我们必须走在正确的轨道上。

如果我们查看的文档Environment.GetEnvironmentVariable(),则可以看到,默认情况下,如果EnvironmentVariableTarget未指定,则从当前进程中检索该值。

10_20_doc-GetEnvironmentVariable.png

现在,如果再看一下Process StartProcess Monitor中的操作细节,我们可以看到该进程使用当前用户的环境,尽管它以身份运行NT AUTHORITY\SYSTEM。因此,最终的工具路径解析为C:\Users\lab-user\.dotnet\tools

10_24_analysis-procmon-env-variables.png

现在我们知道了如何确定路径,因此我们有了第一个问题的答案。现在,我们需要找出此路径的处理方式。

为了回答第二个问题,我们可以返回到Program.ConfigureDotNetForFirstTimeUse()方法,并查看CreateEnvironmentPath()函数调用后执行的操作。

10_20_analysis-dotnet-dll-ConfigureDotNe

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

在此方法中,最相关的代码在下面的屏幕截图中以红色框起来,在此处AddPackageExecutablePath()调用了该方法。

10_21_analysis-dotnet-dll-Configure.png

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

10_22_analysis-dotnet-dll-AddPackageExec

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

10_23_analysis-dotnet-dll-AddPackageExec

首先,此方法检索PATH环境变量的值,但是这次,它使用略有不同的方式来执行此操作。它GetEnvironmentVariable使用EnvironmentVariableTarget设置为的附加参数进行调用1

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

10_23_analysis-dotnet-dll-AddPackageExec

问题在于这也适用于该SetEnvironmentVariable()方法。因此,C:\Users\lab-user\.dotnet\tools\将其附加到注册表中LOCAL SYSTEM帐户的Path Environment变量中。

结论是,.Net Core工具集路径是基于当前用户的环境创建的,但由于该进程以的身份运行NT AUTHORITY\SYSTEM,因此将其应用于注册表中的LOCAL SYSTEM帐户,因此存在漏洞。

结论

此漏洞的状态尚不清楚。由于没有得到Microsoft的正式承认,因此没有与此发现相关的CVE ID。但是,如引言中所述,它已部分修复。即,C:\Users\<USER>\.dotnet\tools如果您使用最新的.NET Core安装程序之一,则该路径将不再追加到该路径中。

现在,如何确保您的计算机不受此漏洞影响?

首先,在注册表中检查以下值。

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并再次检查注册表。“工具”文件夹应该不再存在。

不幸的是,根据我的最新测试,该%USERPROFILE%变量仍被解析为当前用户的“ home”文件夹。这意味着在安装.Net SDK时,路径仍会更改。值得庆幸的是,该文件夹不能用于本地特权升级,因为相应的文件夹归管理员所有。

  •  

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now