luochicun 嘶吼专业版

本文，我将向你展示如何在启用了HYPER-V并成为特殊的“HYPER-V管理员”Windows组的成员的情况下，获得Windows设备上的系统高级权限，在本文的示例中是一个完全修补过的win10。也就是说，Hyper-V管理员就像真正的管理员一样。

但就其本质来说，Hyper-V管理员仅是一个特殊的组，它“仅”向标准用户授予管理Hyper-V环境（创建，删除，启动，停止VM等）的可能性，但在底层操作系统上则不会赋予其高级权限。https://docs.microsoft.com/en-us/windows-server/manage/windows-admin-center/use/manage-virtual-machines

想象一下，当我们(我和我的朋友@padovah4ck)发现，在VM删除过程中，可以很容易地通过硬链接使用带有系统权限的任意文件覆盖时，我们有多么惊讶!

当你创建一个虚拟机时，将对虚拟硬盘文件(.vhdx)进行“SetSecurity”调用，以便向特殊SID授予读写权限:

1. Microsoft

2. NT Virtual machine\

注意，VM的创建者(用户“simple”，本例中是Hyper-V Admin的成员)对文件有完全的控制。

这些操作由“vmms.exe”进程（Hyper-V管理服务）执行，该进程以系统用户身份运行，但在此操作期间模拟当前用户(在本例中为“simple”):

到目前为止，没有什么奇怪或可利用的。但是，当你删除VM时，事情变得越来越有趣，vmms.exe尝试重置(不删除).vhdx文件的原始权限。在此过程中，不进行任何模拟，因此由系统完成!

此时，该利用硬链接发起***了!

如果你删除了.vhdx文件并将其替换为指向受系统保护的目标文件的本地硬链接，那么你应该在VM删除期间授予自己对该文件的完全访问权，不是吗?

我们来看一下：在此示例中，我将向用户“simple”授予“license.rtf”文件的完全控制权，该文件通常仅对标准用户只读：

我在powershell中上传了一个小的POC，它可以自动完成整个过程，你可以在此https://github.com/decoder-it/Hyper-V-admin-EOP下载。

一旦你完全控制了一个系统文件，EOP就是一个简单的任务，例如，你可以用它来覆盖printconfig.dll

披露时间表

我们已经于2019年10月10日向MSRC提交了我们的调查结果。几天后，他们回答说，他们能够重现这个问题，并将在2020年2月修复它。另外，我们还发现了另一个类似的“漏洞”，总是在Hyper-V管理(2019年11月7日)，但这一次是任意删除。照例，我们也通知了这个调查结果。

但让我们惊讶的是，在2020年1月10日，我们得到了MSRC的官方回复，告诉我们他们不会修复这两个漏洞，主要是因为Hyper-V管理员不再被认为是一个“安全边界”。以下为原文:

经过广泛的调查，工程团队已经确定，你的报告虽然有效，但我们不能通过安全更新来解决。这样做的原因是Hyper-V管理员组并不是一个安全边界，类似于我们证明Administrator-to-Kernel不是安全边界（https://aka.ms/windowscriteria）的方式。在调查过程中，我们发现了一些在未来版本中可能会加强的地方，但是由于Hyper-V管理员组的工作方式，在不影响功能的情况下，没有可行的方法来阻止你所报告的技术。

说实话，我不同意，Hyper-V管理组应该被认为是一个安全边界，通过滥用程序的错误配置/错误行为来获得系统权限肯定不是故意的。

我真不理解他们为什么不修复它，在我看来，他们只需要在删除VM时模仿用户，就像在创建VM时一样。

本文参考自https://decoder.cloud/2020/01/20/from-hyper-v-admin-to-system/