A rootkit has existed since early 2007 that is able to load from Windows Vista boot-sectors.
The code features support of the various versions of Vista, the possibility to place it inside the BIOS (it needs around 1,500 bytes), and the chance to use it to bypass Vista’s product activation or avoid DRM.
Vbootkit is much like a door or a shortcut to access vista’s kernel.
A bootkit is a rootkit that is able to load from a boot-sectors (master boot record, CD , PXE , floppies etc) and persist in memory all the way through the transition to protected mode and the startup of the OS. It’s a very interesting type of rootkit.
All rootkits install when the OS is running because they use the OS’ features to load (and also they use the Administrator privileges to install), but bootkits are different, they use the boot media to attack the OS, and thus survive.
Vbootkit is a bootkit specific for Windows Vista. It’s a total in-Ram concept. So, it doesn’t touch the hard-disk under any condition and thus leaves no proofs. Just give a reboot to a vbootkit running system, and it vanishes just as it was never here.
An attack vector exists which can be used to circumvent the full security of the OS, without being easily traceable.
A few things it can do…
– It periodically raises cmd.exe’s privilege to SYSTEM after every few
seconds.
– Modify Registry so as to start the telnet server automatically
– Create a user mode thread and deliver the user mode payloads in context of a system(protected) process (LSASS.EXE, Winlogon.exe etc)
IT CAN DO ANYTHING.
Since vbootkit becomes part of the kernel, it can do anything that Vista’s kernel can do and works on all versions of Vista, even localized ones.
The code for vbootkit was provided to a few antivirus vendors. Nowadays, many anti-virus solutions don’t scan for boot stuff. There was no official response. Whether they implement it or not!
How can an attacker deploy it?
An attacker doesn’t need to install, that’s the way it has been designed. Just boot the system by placing the vbootkit media (containing vbootkit in bootsectors) in the drive, and start booting. After Vista boots, you can verify that you are running vbootkit, by checking the privilege of any running cmd.exe, the sample converts all low-privileged cmd.exe process to SYSTEM privileges. It also supports system compromise via PXE booting.
It doesn’t need any privileges only physical access to the machine.
It can also be installed to a remote system without physical access.
It was basically designed to run from CD, Flash drives and portable HDD. However, such versions were not persistent, so if the system rebooted, they were gone. So,there is also a persistent version which will attach to MBR of the hard-disk. Attaching means it copies the original MBR to some-other location, and thus replace the MBR. So, when the System starts now, vbootkit awakes from MBR, it bootstraps itself (since it is larger than 446 bytes), then loads the original MBR and thus normal booting continues.
As far as someone using other boot managers, it has no effect on almost 99% of such systems, because it doesn’t replace the original boot process, it only inserts itself into it.
It is small enough to fit inside BIOS flash memory at just about 1500 bytes in size. It can be reduced further. Todays BIOSes are big in size, therefore, it can easily hide in there.
How does vbootkit work?
A small summary:
BIOS
–> Vbootkit code(from CD,PXE etc.)
—-> MBR
——> NT Boot sector
——–> Windows Boot manager
———-> Windows Loader
————> Vista Kernel.
Just after vbootkit takes control, it hijacks the interrupt 13, then searches for Signature for Vista OS. After detecting Vista, it starts patching Vista, meanwhile hiding itself (in smaller chunks at different memory locations).
The patches includes bypassing several protections such as checksum, digital signature verification etc, and takes steps to keep itself in control, while boot process continues to phase 2.
Phase 2 includes patching vista kernel, so as vbootkit maintains control over the system till the system reboots. Several protection schemes of Vista were analyzed such as the famous PE header checksum
(every Windows EXE contains it), the Digital Signature of files.
So, you have vbootkit loaded in Vista’s Kernel.
The vbootkit can be modified to bypass the DRM stuff. Since the DRM has been implemented in such a way, so as if unsigned drivers are loaded, then DRM will not let you play the content. What vbootkit does is let you load code without the OS knowing that it has been compromised, and thus the vbootkit can be misused to bypass DRM.
Some other things can vbootkit be used to do…
– vbootkit can be used to to create the long dead boot sector virus. Even some anti-virus vendors have stopped detecting boot sector viruses. It can revive the viruses.
Imagine the following scenarios
Suppose vbootkit is running on a computer and someone plugs-in a USB storage device (vbootkit will copy itself to the boot sector of the new device), now whenever mistakenly the USB devices boots up, it
gonna attach to the boot process of new system and thus, it can flow from system to system and the legend continues .
Now, just take another interesting scenario. vbootkit is running on a system in a company, it captures all MAC address, and at 00:00, in the silence of the midnight, the vbootkit system starts remote booting, and delivers the vbootkit code as boot code though PXE, so slowly and steadily, the whole organization gets going on
vbootkit…
It can also be used to implement backdoors (both local and remote), just an idea. Basically, it can do anything you can imagine (that vista could do).
In the current proof of concept versions, it shows our signature at OS selection time (Boot menu). Secondly, we have added vbootkit signature into the kernel memory, so a physical dump, or a kernel scan will be able to find it.
How would you modify it if you wanted to make it as “invisible” as possible? Removing all the signatures from boot menu and memory locations. Invisibility and detection in rootkits/bootkits is a continuous game of modifying your tools to defeat the other.
Developed during pentesting a client, we needed something that could load our code in kernel, without touching the hard-disk. This started bootkit development. We developed a bootkit for the complete family of Windows NT (including 2000 /XP/ 2003 except Windows NT itself). Then Vista RC1 arrived, since it contained a brand new OS loading mechanism (the boot process is completely different from previous versions), we started analyzing Vista. The process included studying Vista’s MBR, NT Boot sector, Boot manager (Bootmgr.exe), Windows Loader (Winload.exe) and Vista’s Kernel (NTOSKRNL.EXE). Several kernel-land shell codes were developed to be used as a payload in different scenarios.
We don’t want someone to misuse it. We want to show that an attack vector like vbootkit can be used to circumvent whole kernel protections.
It doesn’t need any particular hardware or cpu capable of virtualization.
It patches the windows boot manager, the windows loader, and the vista kernel.
In the reboot persistent version of vbootkit we also patch MBR. It patches few security checks such as PE security patch, digital signature patch and other patches to maintain control of the boot process. If we miss any patch system won’t boot at all.
Please tell us more about the code you had to modify, the shellcodes you developed, and the code that runs when the system is loaded.
The code modifications are done for the security checks. For example, the PE checksum, since we modify files in memory, they should pass through checks, so, we calculate the new checksum and put it in place.
We have to modify the Vista kernel to keep ourselves in control. The modification lets us stay in spare parts of the kernel, and then we dispatch our payload, which is a shellcode which keeps on escalating commands to System privileges. We also have other kernel land shellcodes such as registry modifications to start the telnet
server.
The POC video shows a privilege escalation shellcode. It is just another thread which finds cmd’s, escalates them and then sleeps for another 30 secs, so that no noticeable performance loss occurs. The shellcode has negligible affect on system performance.
vbootkit has a very little affect on the performance (less than .01%). This is because it doesn’t execute at all times, it works, sleeps, awakes, completes work, sleeps and so on (by the way, sleeping doesn’t take much CPU cycles).
In the proof of concept videos, Vista is running in vmware on our 4 years old Pentium-IV 2.00Ghz, 512 Ram, 40 Gb hard-disk, Geforce2 MX 400 graphics card. That is why it seems slow 🙂
Are you taking advantage of a bug in Vista to launch your attack? It isn’t that it exploits a bug in Vista’s
kernel (at least related to this scenario), it creates a tunnel to Vista’s kernel which doesn’t have any protection barriers and therefore restores full control of the machine to the user.
It can be programmed to bypass Vista’s product activation. No official Microsoft contact, but we have
discussed this with several Microsoft guys.
Software only protections are not enough to protect from bootkits. The only protection available is from hardware (Trusted Platform Module).
Microsoft can just raise the barrier for bootkits by changing algorithms, but there can be no real protection from bootkits using only software methods. Use Secure Boot (TPM).
Would you like to add something?
The beauty of VBootkit lies in the fact that it isn’t about someone else controlling your machine. It’s about you controlling your own machine, so you can run software of your choosing. Vbootkit gives control back to the user.
http://www.nvlabs.in
Presentation: http://www.nvlabs.in/uploads/projects/vbootkit/nitin_vipin_vista_vbootkit.ppt
White Paper: http://www.nvlabs.in/uploads/projects/vbootkit/vbootkit_nitin_vipin_whitepaper.pdf
Re-written – based on an April 26, 2007 article which originally appeared in Security Focus. Copyright © 2007, SecurityFocus
Like this:
Like Loading...
