A recently released module by the Exploit Writing Team here at Core generated a lot of emails to me from folks out there in Security Land asking for more information about the underlying vulnerability and how we were able to develop a Denial of Service module to trigger the vulnerability.

 One of the exciting things about being product manager for CORE IMPACT Pro is I get to peek behind the curtain and see how the exploits and capabilities that wind up in the product are built. One of the most fascinating processes to observe is that of an exploit being “born.” Gone are the days when you could expect a detailed description of a vulnerability and how it is triggered when a patch is released; now you get terse language and a very high-level description. As patches are released by various vendors, members of Core Security’s Exploit Writing Team (EWT) review the description and the patch and determine if there is an actually exploitable vulnerability being patched. If that’s the case, the door to the EWT room closes, the lights dim, and an insane amount of cerebral work gets done. A recently released module by the Exploit Writing Team here at Core generated a lot of emails to me from folks out there in Security Land asking for more information about the underlying vulnerability and how we were able to develop a Denial of Service module to trigger the vulnerability.

It turns out that the case of MS10-102 “Hyper-V VMBus Vulnerability – CVE-2010-3960” is a really interesting example of exploit development. This vulnerability and the applicable patch was announced by Microsoft on December 14, 2010. I’ve asked Nicolás Economou (the exploit writer who produced our exploit) to describe the process by which he examined the patch to identify the vulnerability and then produce an exploit module that would allow our customers to check their protections or demonstrate the risk associated with this vulnerability. When I read Nico’s summary, I was impressed by the amount of time he put into working on this vulnerability. At Core, we consider an issue like this to be critical and are prepared to put the time needed into providing reliable information to our customers. What I like about this vulnerability is the reality that I simply need to gain access to one Guest OS running on a Hyper-V machine, and I can DoS every other virtual machine running on the server. If that doesn’t remind you that virtual machines are not isolated machines, I’m not sure what would! But enough from me, the purpose of this blog post was to allow you to hear the story of MS10-102 from Nico himself …

Behind the CORE IMPACT Exploit with Nico Economou Thanks Alex – As I am sure everyone knows, Microsoft releases their monthly security bulletin known as "Microsoft Patch Tuesday" on the second Tuesday of every month. December 2010’s Patch Tuesday included 17 security bulletins (MS10-090 - MS10-106). Since I'm very interested in virtual machine technologies, one bulletin in particular caught my attention: MS10-102 - "Hyper-V VMBus Vulnerability - CVE-2010-3960" In a nutshell, the bulletin says that whenever someone exploits this problem, the Hyper-V server running on the "host" machine stops responding – hence all the virtual machines running on the host are affected as well. The versions affected included in the document were: 1) Windows Server 2008 for x64-based Systems 2) Windows Server 2008 for x64-based Systems Service Pack 2 3) Windows Server 2008 R2 for x64-based Systems

About Hyper-V and Hyper-V VMBus First, some background info on Hyper-V and Hyper-V VMBus. Hyper-V is the latest hypervisor-based virtualization developed by Microsoft; something similar a VMWare Server. Hyper-V VMBus is basically the communication bus between the guest OS and the hypervisor. This communication bus is used through channels that are created by the hypervisor and served to the guest OSes applications and/or drivers.

Getting Started with the Exploit So, as I said, this bulletin caught my attention, so I decided to go for it. First I installed a Windows 2008 R2 into a virtual machine and tried to add a Role (Hyper-V) and … ouch! ... I realized that the Hyper-V couldn't be installed inside a virtual machine. For the second try, I installed the OS on another machine – not virtual this time ;) I then finished setting up the Hyper-V and installing a Windows XP SP3 OS as virtual machine so I could play with a complete scenario (host + guest OS).

Down and Dirty with Patch Diffing At this stage, the real challenge was trying to find the original bug by reversing the MS10-102 patch. So I installed the patch on the host machine (where the Hyper-V runs), rebooted the system, and looked for the files modified by the patch, which were:

  • At the host OS: "vmbus.sys", "vmswitch.sys" y "storvsp.sys"
  • At the guest OS: no changes

Once I knew the modified files, I backed them up and then uninstalled the patch so I could roll back to the original vulnerable scenario. Now, having the original and modified versions, I ran a binary diff and found out there were similar changes on the same function's name across the three files. That made me think that, either there were three different vulnerable functions that could be exploited, or some code-reorganization had been done. One of the modified functions was "IncomingBuildMdls," where some of the code belonging to that function got moved to a new function called "IncomingParseGpaDirect." In the end, everything boiled down to just breaking one function into two.

Debugging Hypervisor One question that kept coming up was, "How do I debug the hypervisor"? Luckily, as I mentioned before the files that changed were only device drivers. Therefore, there wasn't a big difference between debugging hypervisor and debugging a regular Windows kernel. The only difference was, instead of connecting to "kd.exe" (a kernel debugger) to a pipe created by a virtual machine, I had to connect through the serial port of the physical machine (the host OS).

Reverse Engineering the Patch It was now the right moment to try understanding the data flow reaching the modified functions. My main question was, "Is it possible to send data from the guest OS to those functions so I could trigger them at the host OS?" I spent a LOOOONG time (about a month) testing and retesting various ideas and hunches – most of which resulted in dead ends. I’m amazed that I didn’t go mad trying to understand functionality without any documentation except a bunch of function names, a disassembler, and a debugger. However, I finally managed to solve the puzzle and understand how all the pieces would fit together from the point of view of the guest OS. Hyper-V provides channels for the guest operating system to connect with the hypervisor. Some of those channels are meant to be used by the guest OS kernel, AND some others to be used by the userland processes on the guest OS. Out of all the drivers I saw, I found the driver for the "Virtual HD," "Microsoft Virtual Machine Bus Video Device,” and "Microsoft Virtual Machine Bus Network Adapter" – among others. I also found some services using these channels (through pipes this time):

  • "Hyper-V Data Exchange Server"
  • "Hyper-V Guest Shutdown Service"
  • "Hyper-V Heartbeat Service"
  • "Hyper-V Time Synchronization Service"

These services are installed on the guest OS when the "Insert Integration Services Setup Disk" is selected.

Triggering the Bug Once I understood how the data flows between the guest and host OS to reach the vulnerable functions, it was relatively easy to trigger the bug – although this wasn't exactly what Microsoft described. In the Microsoft Exploitability Index Assessment released in conjunction with the December Patch Tuesday, this vulnerability was given a rating of 3 (the lowest) “Functioning exploit code unlikely.” I guess they weren’t as excited about the potential of this vulnerability as I was!

Final Thoughts A false sense of security exists when an operating system runs inside a virtual machine – with some users believing the Guest machines are all isolated from each other and from the Host OS. If this vulnerability highlights anything, it is that the Guest and Host OS are in no way isolated from each other. Virtualization technologies mitigate some problems but can create others, as this particular case has proven. On a personal note, this was the hardest trigger I had to face, without even knowing that I could actually trigger it. Today I can say that (luckily) I could :)