欢迎访问Sunbet官网(www.sunbet.us),Allbet欧博官网(www.ALLbetgame.us)!

首页Sunbet_新闻事件正文

如何启用Hyper-V技术获取系统权限

b9e08c31ae1faa592020-02-0172资讯

本文,我将向你展示如何在启用了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 Hyper-V Virtual Machine Bus Provider (S-1-15-3-1024-2268835264-3721307629-241982045-173645152-1490879176-104643441-2915960892-1612460704)

2. NT Virtual machine\

如何启用Hyper-V技术获取系统权限  资讯 第1张

如何启用Hyper-V技术获取系统权限  资讯 第2张

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

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

如何启用Hyper-V技术获取系统权限  资讯 第3张

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

如何启用Hyper-V技术获取系统权限  资讯 第4张

Lenovo ThinkPad P51s固件SMM驱动逆向及漏洞分析

一、前言 从去年夏天开始,我尝试对自己的Lenove ThinkPad P51s计算机固件进行逆向分析。之所以对这个型号的固件感兴趣,其原因在于独立BIOS供应商(专门从事固件开发的公司)似乎是Phoenix Technologies而不是AMI,因为此前已经研究过大多数固件。尽管大多数固件都使用EDKII,但供应商的不同意味着其中的很多代码都将有所不同。 我们首先开始分析SMM驱动程序,很快就发现了一个漏洞——在一个SWSMI处理程序中调用SMRAM。该漏洞已经由Lenove在8月完成修复,目前我无法在网上找到关于该漏洞的任何信息。 在本文中,将首先介绍SMM和UEFI的基础概念,随后对这一漏洞进行详细分析,这里面的漏洞利用涉及到在此前另一篇文章中发表的技术——SMM中的Code Check(mate)。 以下内容已经公开发表,幻灯片可以参考这里

此时,该利用硬链接发起攻击了!

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

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

如何启用Hyper-V技术获取系统权限  资讯 第5张

我在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/