I envisioned being able to simply copy any bootable CD or DVD (Windows installers, OS X boot discs, Linux Live CDs and recovery discs like Knoppix, etc) to a USB drive and boot it normally.
I spent days looking for a way to boot any and all ISO images from a USB drive.
Only then will you likely stand a chance against a Kon-Boot attack.at least on Windows systems.Boot any and all ISO images from USB driveīoot any and all ISO images from USB drive # Then (as thras has pointed out) you need to apply a pre-boot authentication solution and/or whole disk encryption TrueCrypt, PGP, CE-Infosys for example seem to work great against Kon-Boot. Mitigation? Pretty severe stuff: disable CD/DVD, USB, PXE booting of the system in BIOS. As miles stated, the MBR is not changed by Kon-Boot. However the MBR on a test system can be hashed/checked (as well as inspected at the sector level with a hex-editor) by a number of tools such as mbr.exe - or GMER - and also including an off-line boot of the system using a LiveCD boot disk (to ensure the OS booting the system to check isn't compromised by any potential rootkits left on the system). This similarity with MBR bootkits likely leaves some (as seen in the comments) that it must be leaving a MBR bootkit behind. Particularly when it has been coded to work on both Windows as well as Linux kernels. What makes this tool (and Vbootkit) interesting is that they take the normal stay-resident MBR bootkit design and do it all on the fly (apparently) leaving no trace on the system behind.
With these patched, the operator can access these profiles without any password input needed. From there it hooks INT 0x13 to control content of memory sectors loaded by NTLDR and begins patching areas of the kernel specifically dealing with the security profiles and user SAM files dealing with user logon authentication and the GINA processes. Based on what I have read and the research that miles and others have done on this and other bootkit tools that are "open" in the code, it likely (warning: logical conjecture here) hijacks the memory during the BIOS to bootloader process. ) and compare it to the eEye BootRoot project.
As has been noted in these comments, Nitin Kumar and Vipin Kumar have released their Vbootkit 2.0 code openly.and others have already started to review it ( Nitin Kumar & Vipin Kumar: "please remember to give necessary credit to the authors" PKB.
It likely won't detract from the hard work he has done, but would allow skilled coders to understand and "proof" his work. That is why (as miles suggests) Piotr's release of the source code could be valuable. However, if in our enthusiasm to have an easy solution (and not validating what is really happening) we run the risk of spreading some kind of malicious rootkit or sleeper issue behind.
This is a transparent "solution" that leaves the passwords intact.just completely ignored. Sure we could change their password from our admin service account, but then we would have to leave a note for a callback. Imagine being able to access and service end users (non-Active Directory shop) Windows user accounts when they were out and we show up after a two-hour drive and could not log on to their profile? Awesome time-saver. In the past this is the kind of tool that our technicans and other system administrators would have rejoiced over. But I imagine I could (like miles) think of some testing that might validate if a system is being compromised by such a tool or if the effect is memory-resident only. I certainly am not a programming expert so I can't disassemble such a tool. "Trust but verify" I think someone once said.
All too often we (end users/system administrators) can get enamored with a utility that has some great features and neglect to understand how it functions and any consequences it may bring (known/unknown).