Vbootkit 2.0 Given Open Source Status

Vbootkit is written to serve as a rootkit – to take and hold full, un-detectable control of a system – provided it is substituted for the system’s normal boot loader, at start-up time.

The program starts by hooking the (in) famous INT 0x13, an instruction which makes the BIOS provide hardware-level hard disk and floppy disk read and write access to whatever program issues it. Normally, this interrupt is intercepted by the operating system and re-directed to a filesystem driver.

However, at boot-time there is no operating system in place yet, so the caller (in this case Vbootkit 2.0) can, by hooking (taking control of) INT13, “see” and change everything that is copied from the disk to memory.

Vbootkit 2.0 then uses this advantage to patch (modify) the various components of the Windows 7 boot process (BOOTMGR.EXE, winload.exe and finally the kernel itself, ntoskrnl.exe) as they are being loaded from disk, but after the file integrity checks have been made. Once loaded into the next component, the boot-kit changes the previous component back to its original, un-tampered-with state in memory.

Once the kernel is finally loaded (in its modified, compromised state) the system is up. Afterwards, Vbootkit 2.0 patches tcpip.sys so it can monitor the network interface and starts listening for commands from the attacker.

The communication channel chosen is ICMP (the one used by the “ping” command, which simply tells you if a computer exists at a certain IP address; it is very rarely, if ever blocked by firewalls).

Nothing is loaded or run in user mode and nothing is written to disk.

It’s then game over for the system, including any security solutions inside it, as the kernel memory can only be accessed with kernel privileges and kernel privileges are not granted to user-mode programs, ever, under the Windows 7 security model.

All this is purely of academic interest for now, as people aren’t going to boot from an infected disk (unless, of course, Microsoft Windows 7 installation disks somehow get compromised – a highly unlikely scenario).

Nor is it likely that the boot record of a Windows 7 disk could be modified from within the running Windows 7 system, as the system does not grant such access to user mode programs.

However, one (big) piece of the puzzle is already in place. It’s rather likely that a way to overcome the present limitations of Vbootkit 2.0 exists and it’s also likely that such a way will be found.

When that happens, we can only hope that it will be a security researcher who finds and publishes it.