Another episode of the series: From XXX to SYSTEM !

This time I will show you how it is possible to gain SYSTEM privileges on a Windows machine (a fully patched Win 10 in our case) with HYPER-V enabled and being a member of the special “Hyper-V Administrators” Windows group. I know what you are thinking about: Hey! Hyper-V admins are just like  Administrators (or even more), so what are you telling us???

Well, that’s not  true. Hyper-V Administrators  are a special group which “only” grants to standard users the possibility to manage the Hyper-V environment (create, delete, start,stop VM’s and so on…) but no other special privileges on the underlying OS (https://docs.microsoft.com/en-us/windows-server/manage/windows-admin-center/use/manage-virtual-machines)

Imagine our  surprise when we discovered that it was really easy to exploit via hardlinks an arbitrary file overwrite with SYSTEM rights during a VM deletion process… but back to the beginning!

When you create a virtual machine, a “SetSecurity” call is made on the virtual harddisk file (.vhdx) in order to grant r/w permissions to special SID’s:

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\<id of VM>

Note that the creator of the VM (user “simple”, member of Hyper-V Admin in this case) has full control over the file.

These operations are performed by the “vmms.exe” process  (the Hyper-V management service) , which runs as SYSTEM user but impersonates during this operation the current user (“simple” in this case):

So far nothing strange or exploitable, do you agree?

But when you delete the VM, things are becoming more interesting… vmms.exe tries to reset the original permissions on the .vhdx file (which is not deleted).  During this process, no impersonation takes place, so it’s done by SYSTEM!

I guess you already got it: hardlinks abuse!

Oh yes! If you remove the .vhdx file and replace it with a native hardlink pointing to a SYSTEM protected destination file, you should grant yourself full access to that file during the VM deletion, isn’t it?

Here we go: in this example I will grant to my user “simple” full control on “license.rtf” file, which normally is read only for standard users:

I have uploaded a small POC in powershell which automates the whole process, you can download it here . Yes. it’s really a piece of cake!

Once you have full control over a SYSTEM file, EOP is an easy task… for example, you can use it for overwriting the printconfig.dll 🙂

Disclosure timeline

We submitted our findings to MSRC on October, 10th 2019.

After a few days, they answered that they were able to reproduce the issue and would fix it in February 2020. We also found another similar “bug”, always in the Hyper-V administration (November 7th 2019), but this time an arbitrary delete. Notified this too, same answer.

But to our surprise,  on January 10th 2020 we got the “official” response from MSRC telling us that they would not fix these 2 bugs, mainly because Hyper-V administrator is no more considered a “security boundary”. Below the original transcript:

“After an extensive investigation, the engineering team has determined that your report, while valid, is not something we can address via a security update. The reason for this is that the Hyper-V Administrators group is not intended to be a security boundary, similar to how we document that Administrator-to-Kernel is not a security boundary (https://aka.ms/windowscriteria). During the investigation we found areas which may be hardened in future releases, but due to the way the Hyper-V Administrator group functions, there is no feasible way to prevent the technique you reported without negatively affecting functionality.”

To be honest I don’t agree, Hyper-V admin group should be considered more a “security” boundary than a “safety “boundary.  Getting SYSTEM rights by abusing a misconfig/misbehavior of a program is something which is by sure not intended.

But it’s obviously up to Microsoft, what I really don’t understand is why they won’t fix it. From what I see, they just need to impersonate the user during the VM deletion, in the same way they did during the VM creation, isn’t it?

Possible Countermeasures

Even if MS won’t fix this bug soon and are concerned about this security issue, nothing is lost! @mkolsek and his team from 0patch.com is working on a “micropatch” which will be released soon!

That’s all 😉