Kon-Boot: Bypass Windows Login Security (and some helpful blocking solutions)

A number of weeks ago I received a tip from TinyApps.Org Blog that has become a real safari event.

• KON-BOOT - ULTIMATE WINDOWS/LINUX HACKING UTILITY – free boot utility from Piotr Bania

From the developer’s description:

Kon-Boot is an prototype piece of software which allows to change contents of a linux kernel (and now Windows kernel also!!!) on the fly (while booting). In the current compilation state it allows to log into a linux system as 'root' user without typing the correct password or to elevate privileges from current user to root. For Windows systems it allows to enter any password protected profile without any knowledge of the password. It was acctually started as silly project of mine, which was born from my never-ending memory problems :) Secondly it was mainly created for Ubuntu, later i have made few add-ons to cover some other linux distributions. Finally, please consider this is my first linux project so far :) Entire Kon-Boot was written in pure x86 assembly, using old grandpa-geezer TASM 4.0.

…it provides support for Microsoft Windows systems and also the Linux systems listed in the next sections. Kon-Boot for Windows enables logging in to any password protected machine profile without without any knowledge of the password. This tool changes the contents of Windows kernel while booting, everything is done virtually - without any interferences with physical system changes. So far following systems were tested to work correctly with Kon-Boot (however its quite possible other versions of listed Windows systems may be suitable as well):

Windows versions of logins that it supports/bypasses are: Server 2008 Standard SP2 (v.275), Vista Business, Vista Ultimate, Server 2003 Enterprise, XP, Windows 7.

Although not a “well-known” tool (yet), notice of Kon-Boot is slowly beginning to show up around the blog-o-sphere and security blogs.

• Kon-Boot "root a box" on the fly .. it’s a kind of magic ! – Security Database Tools Watch

• KON-BOOT for Windows and Linux (Password Bypassing Utility for Forgetting Heads) - DailyDave

• Login to Windows Administrator and Linux Root Account Without Knowing or Changing Current Password - Raymond.CC Blog

• Kon-Boot CD:110KB Floppy image/CD ISO to remove your Windows admin and Linux root pwd – Hacker News

I’ve avoided posting on it for some time as (like TinyApps blogger Miles) I’ve felt compelled to first try to understand what it is, how it may be working, and what impact (negative/positive) it might have on a system.

To use it, download one of the image files (I used the CD ISO) and burn the ISO file to a disk.

Boot your target Windows system from the CD and you will get the Kon-Boot splash screen.

Hit <Enter> or the spacebar to start the injection process.  If the BIOS/system “supports” Kon-Boot some programming checks will be displayed and the boot will hand off to the normal Windows loader processes.

Once at a Windows login screen, enter the user account name you wish to access and bypass the password.  Note: you must know this ahead of time unless the user name is set to save/display automatically.

Then you can either leave the password-field blank and click on through, or you can enter whatever garbage you want for the password. It doesn’t matter.  The password has been magically bypassed!

I have tried it on a number of systems once I had some firmer knowledge of the tool and in my cases; it worked as promised.  Completely bypassing the Windows GINA login on XP systems as well as Vista and Windows 7 (of which the login’s don’t actually use the GINA method of XP/W2K, but it works anyway).

Cool.  Very frightening from a sysadmin standpoint, but cool nonetheless.

In my mind, it would be irresponsible to post a “come and get it” call for this tool without first trying to see if it left any malicious files, root-kits, or other “baddies” behind in it’s wake.  As well as to offer some mitigation suggestions.

Thus begins the journey.

What Kon-Boot Does on the Surface

Many business (and some home users) who run Windows decide that one good method to protect their system from unauthorized access is to set up one or more (local system) user accounts.  These accounts then have passwords placed on them which (theoretically) should discourage unauthorized users from logging onto the system and accessing the applications and data.

System administrators and Windows security folks know this is actually a pretty weak model.

If that is the only security measures implemented on the system, then a penetrator/hacker/administrator just needs to apply one of a number of well known and documented methods to bypass the authentication.  Some of these methods include:

• Ophcrack (and L0phtcrack 6) – cracking the password SAM files with tables

• Offline NT Password & Registry Editor – blanking the password,

• Yanking the drive and placing in another system to access the files directly, bypassing the OS, or

• Booting with a “LiveCD” and accessing the files in place, again bypassing the OS.

However, these techniques have some drawbacks.

Ophcrack can/does work but unless the passwords are fairly simple, the attack can take some time to work and is not always successful in a reasonable amount of time.

The Offline NT Password & Registry editor is quite successful in its methods, but by “blanking” the password, leaves evidence to the primary user that something has been breached.

Yanking the drive or booting with a LiveCD are quite doable but may not be time-practical or hardware-practical solutions.

Kon-Boot would allow someone to drop in, boot the system directly, bypass any Windows account login security, poke around under the local account, then pull-out without letting the end-user be any wiser.  Of course an incident response investigation might find some evidence tracks afterwards, but with the password left intact, it might take a while to notice the breach.

On the other hand, sysadmins and Windows gurus who have to service systems often find user’s who have forgotten to provide them the password so I suppose it could be a useful tool for legitimate and authorized situations.

What it Is / What it (May) be Doing Deeper

Turns out Kon-Boot fits nicely into a class of hack/security tools called boot kits.

These are an old and well-established small class of tools.  They have recently started to gain notoriety in security circles again with a number of newer exploit proof of concepts released.

• eEye BootRoot – “…presented at Black Hat USA 2005 by researchers Derek Soeder and Ryan Permeh, as an exploration of technology that custom boot sector code can use to subvert the Windows kernel as it loads.”

• eEye SysRQ2 – “…a bootable CD image that allows a user to open a fully privileged (SYSTEM) command prompt on Windows 2000, Windows XP, and Windows Server 2003 systems by pressing Ctrl+Shift+SysRq at any time after startup. It was first demonstrated at Black Hat USA 2005 by researchers Derek Soeder and Ryan Permeh as an example of applied eEye BootRoot technology.”

• NVlabes Vbootkit 2.0 – a proof of concept tool which grants various abilities to elevate permissions to SYSTEM level, as well as start telnet server automatically and do some user-password manipulations.

While similar to root kits, boot kits operate (generally speaking) a bit differently.  Depending on the specific boot-kit code they might inject themselves into the OS kernel during the boot process, patch memory registers, and then do their deed.  Some may be persistent.  By that I mean once loaded on a system they stay present after reboot.  Others may be memory-persistent only.  They are “installed” in memory, function, but when the system is reset no trace is left behind.

Kon-Boot purports to be the later.

Turns out there is a quite a lot of great and highly technical material on understanding the principles of boot kit methodologies.

• 0wning Vista from the boot – SecurityFocus interview with Nitin Kumar and Vipin Kumar, developers of Vbootkit.

• Nitin Kumar & Vipin Kumar: "please remember to give necessary credit to the authors" PKB. - [Dailydave] – Dave Korn analyzes the code in the Kumar’s Vbootkit and finds many close similarities with eEye BootRoot code.

• VLAD Magazine - Issue #2 - ARTICLE.4_4 - BIOS Meningitis Source – BIOS-based resident boot kit.

• eEye BootRoot BlackHat presenation  (PDF) – Detailed presentation by Derek Soeder and Ryan Permeh on the technical process behind the Windows boot process, and how BootRoot subverts the Windows Kernel.  Very, very good reading.

• MBR Rootkit paper from VB2008 - Malicious Code - STN Peer-to-Peer Discussion Forums – Symantec also has an excellent technical paper (quite readable) on boot kit development and operation: The Rise of MBR Rootkits (PDF).

• Stealth MBR rootkit – In depth analysis of a MBR root kit based on the eEye BootRoot code.  Not only shows code in comparison, but how the MBR root kit has evolved to avoid detection techniques.  Also provides links to MBR boot kit detection tools mbr.exe and GMER.

• Vbootkit whitepaper (PDF) - Nitin Kumar and Vipin Kumar explain their boot kit exploit at Black Hat 2007.  See also their Vbootkit Presentation (PowerPoint).

• D2T2 (PDF) - Nitin Kumar and Vipin Kumar explain their boot kit method in another presentation.

• Dubai 2009 - NVlabs | Analyzing Security. Link to the Kumar brother’s presentation of Vbootkit 2.0 at Hack-in-the-Box Dubai 2009.  Note: this article links to the presentation notes Vbootkit 2.0 Attacking Windows 7 (x64) via Boot Sectors (ODP) which is an Open Office presentation format document.  Get OpenOffice, or OpenOffice Portable.  Microsoft also has a converter for ODP files.

• MBR rootkit: VirTool:WinNT/Sinowal.A report – Microsoft Anti-Malware Engineering Team

• MBR/Mebroot/Sinowal/Torpig is back – better than ever – TrustDefender Labs

• MBR Rootkits – Securology Blog

• Bootkit: the challenge of 2008 – Viruslist – Excellent historical review of boot kit history.

• Malware evolution: January – March 2008 – Viruslist – Even more material on boot kit exploits.

• Building malware defenses: From rootkits to bootkits – Noah Schiffman article from 2007. Light but good overview.

Unlike eEye’s BootRoot and the Kumars’ Vbootkit, the developer of Kon-Boot, Piotr Bania, has decided not to release the Kon-Boot source code so examination is based (currently) on known technologies and examination of systems on which Kon-Boot was used.

IANMR (I am not Mark Russinovich) but it seems that the process by which most root kits work is fairly well understood now.

Based on what I have read and the research others have done on this and other boot kit tools that are "open" in the code, it likely hijacks the memory during the BIOS to bootloader process. 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/login-authentication processes. With these patched, the operator can access these profiles without any password input needed. What makes this tool (and Vbootkit) interesting is that they take the normal stay-resident MBR boot kit design and do it all on the fly (apparently) leaving no trace on the system behind. That's pretty sophisticated stuff. Particularly when it has been coded to work on both Windows as well as Linux kernels.

Because of the BIOS memory injection it appears to perform, some system BIOS’s may not be supported and could cause Kon-Boot to fail. So it isn’t a 100% success in all possible conditions.  Also some users have said it BSOD their systems in various comments around the web.  Some have even reported it nuked their systems for unknown reasons.

That certainly hasn’t been my experience. It was easy for me to get on a disk and booted all systems I tested it on with no ill effect (continue reading).

Many of the links posted above referencing boot kits have great illustrations and diagrams on how this works exactly.  I wasn’t able to get permission to use material from those presentations, so go check them out for all the great pictures, descriptions and technical details.

It is really fascinating and cool stuff on how the BIOS memory is hijacked, and how next the injected code in memory patches the kernel and tells it to ignore password requirements for the user accounts.

It is also this shared similarity with MBR boot kits likely leaves some (as seen in various comments around the web) that it must be leaving a MBR boot kit behind.

Does it Leave a Root Kit Behind?

This is the million-dollar question.

Many folks think so.

Limited testing seems to suggest that, as Piotr claims, it does not leave any lasting or persistent changes to system on which it is executed.

It is conceivable and technically possible it could infect the BIOS, MBR, as well as allocated/unallocated hard-drive space.  It might also change/patch critical Windows system files.

I tested Kon-Boot post-usage via a suite of root-kit scanners and found nothing amiss.  But that may or may not mean anything.  What was really needed was a detailed baseline system scan using change-detection program, reboot and use Kon-Boot, then reboot and take another system scan to check for file/folder changes. 

Fortunately for us, Miles Wolbe from TinyApps.Org Blog has taken this task upon himself to try to explore.

He has graciously given me permission to post his findings.

Miles’s plan was structured as follows:

1. Save images of BIOS, CMOS, Video BIOS, and MBR with NSSI (run from bootable CD) and save snapshot of Windows install with InstallWatch Pro
2. Boot with Kon-Boot, be amazed at password bypass, turn off computer
3. Repeat step 1
4. Perform diffs

And his results were as follows (as combined from numerous emails):

Here are the results of my Kon-Boot tests:

Computer:

Dell Inspiron 600m

Changes to system after running Kon-Boot and then rebooting:

   MBR: none
   Video BIOS: none
   BIOS: none
   File system / registry: see attached ZIP file

Tools used:

Phoenix WinPhlash and dumpvgabios (BIOS and Video BIOS) as described here:

http://icrontic.com/forum/showthread.php?t=30777

NSSI (MBR and Video BIOS) Also dumps BIOS, CMOS, PCI, and more, but these did not work well for me.

diff and md5 (comparison of dump files)

InstallWatch Pro (file and registry changes)

EFS file encryption is not circumvented by Kon-Boot. That is, if you bypass the login password for "Joe" via Kon-Boot and he has an EFS encrypted file named "doc.txt", you will not be able to open it ("Access is denied" message is returned).

After bypassing login password with kon-boot, the user accounts applet shows "create a password" for the current user instead of "change password". if you try to enter a
password, the following error appears: "Windows cannot change the password."

Just to clarify: the strange user accounts behavior persists only while kon-boot is
active.

Please note that while Kon-Boot will let a user into the password protected Windows account, it will not allow access to any encrypted/password-protected files that would also have to be authenticated.  I guess that is something.

Also, it does not seem to allow password-bypassing of Domain configured accounts or other network GINA supported authentication requirements. It only seems to work on Local Windows user accounts.

I haven’t had the time to try it, but I would also like to capture a memory-image ( Tools:Memory Imaging - Forensics Wiki) of a system running normally, then recapture the memory-image while Kon-Boot is running, then difference the results.

That might point out any memory resident changes Kon-Boot makes.

So, as far as we can tell at the moment it appears--based on limited testing--that Kon-Boot should be “safe” to run on a Windows system you might be authorized to access.  However, I highly encourage you to do your own controlled and protected testing before making any such deployments organization-wide.  Don’t blame us if something bad happens.

Messing around with boot kits and root kits is always a dangerous and dicey prospect.

As someone once said, “Trust, but Verify.”

Defeating Kon-Boot (Easy but Crippling Stuff)

So how can the system administrator defeat Kon-Boot deployments and enhance security.

Well some easy methods come to mind:

• Set a password on the BIOS to require entry before booting,

• Set a password on the Hard Drive (modern drives may support this) to prevent access before accessing from the hard-drive,

• Disable USB/Firewire booting of a system,
  • Physical memory attacks via Firewire/DMA - Part 1: Overview and Mitigation (Update) | Uwe Hermann

  • www.storm.net.nz Projects

  • Burn ISO Image to USB Flash Pen Drive (Kon-Boot to USB) - Raymond.CC Blog

• Disable PXE booting of a system,

• Change the boot order to prevent (or disable) booting from CD/DVD ROM drives.

Basically lock down the system so Kon-Boot can’t be used to boot the system.

Yeah.  It will annoy your users to hell, but it will assist with security.

However that may not be enough, or you may want to leave a certain amount of usability to the system.

BitLocker and TPM Protection

In a discussion with cdman183 at his Hype-Free blog he put me on another technique that seems very successful in blocking Kon-Boot/boot kit operation (assuming the MBR hasn’t been pre-infected); disk encryption / pre-boot authentication.

Microsoft offers its Trusted Platform Mode (TPM) and BitLocker solutions that help authenticate supported OS versions during the boot process to ensure they have not been modified.

• Trusted Platform Module - Wikipedia, the free encyclopedia

• Windows Trusted Platform Module Management Step-by-Step Guide – Microsoft TechNet

• Enabling Vista Bitlocker (without a TPM chip) – I Think I Broke It site

• Using Vista’s Boot Manager to Boot Linux and Dual Booting with BitLocker Protection with TPM Support - Port 25: The Open Source Community at Microsoft

• VBootkit vs. Bitlocker in TPM mode – Robert Hensing’s Blog contains some very good stuff so I’ve copied the items below from the above post (images not directly linked).

Before explaining how BDE mitigates this attack the following picture may help set some context for the scenario. 

This is what a 'normal' OS boot from a hard drive looks like when BDE has been configured to use a TPM 1.2 module.

(NOTE:  There may be some slight innacuracies in the 'All boot blobs unlocked' column according to Jamie but they aren't really important for the concept I'm trying to illustrate. :))

In a VBootkit system boot - I believe the boot process flow looks like this (any mistakes are mine)

In the picture above - you can see that the boot process has been detoured a bit by the presence of a Vbootkit CD causing an additional MBR to be read during the OS boot (this MBR presumably then jumps back to the one on the HDD after hooking INT13).

Well it is my understanding, based on my discussion with Jamie - that this will cause BDE in TPM mode to fail to boot the OS because the 'measurements' stored in the PCR in the TPM will be incorrect or will be unexpected in value - which will cause the TPM to fail to unseal the VMK which will lead to a boot failure. 

What this all means is that when the boot manager (BOOTMGR.EXE) goes to unseal the VMK stored in the TPM 1.2 module - the TPM will respectfully decline. :)

• BitLocker, TPM won’t defend all PCs against VBootkit 2.0 – Techworld – Basically the augment here is that it doesn’t work because many (most?) Windows OS versions are home/consumer version that do not contain the TPM support found in Windows Enterprise/Enthusiast versions.  Nor does all (mostly older) hardware support TMP solutioning.

Solutions for the rest of us

So what if you have a system that doesn’t support TPM mode protection against boot kit high-jacking and you don’t want to disable all the CD/USB/etc booting methods?

Well, like I said, go with whole-disk encryption and/or pre-boot authentication.

• PGP Whole Disk Encryption – This commercial solution offers protection against Kon-Boot.  I tested Kon-Boot against PGP WDE system. 

The system allowed Kon-Boot to load normally, Kon-Boot injected itself into the BIOS memory handoff, and then I was presented with the PGP WDE loader.  It did not change the requirement to enter a valid passphrase at all. You could not bypass this requirement.  So I entered a valid passphrase and the Windows system booted normally. It appeared that the PGP to Windows boot loading process completely scrubbed Kon-Boot’s memory presence away as I was not able to log into the local Windows accounts (which Kon-Boot bypasses) unless I entered a valid password.

Hurray.

PGP is a commercial solution. While they do offer lighter versions for home/SOHO users, it may not be practical for folks on a budget.

Fortunately at least two well known and trusted solutions are available for free.

• TrueCrypt - “freeware” – This product offers whole-disk encryption and requires pre-boot authentication.

In my test of this solution, I used a Virtual PC session of XP Pro.  I set a password and verified I could not log onto the account unless the correct password was used. Then I booted it with Kon-Boot and successfully bypassed the password.

Then I used TrueCrypt to fully encrypt the drive, set a volume password and tested again.

I booted the system again with Kon-Boot

Note that TrueCrypt could not boot the system and gave the following error:

Error: BIOS reserved too much memory: 569

It seems that once Kon-Boot had injected itself into the boot memory, there wasn’t enough left for TrueCrypt to do its thing and bring the system up.  So the boot kit hack failed.

It is possible that different system BIOS may offer different amounts of available memory so this might not be fool-proof.

But it is a start.

The third solution is awesome:

• CE-Infosys CompuSec – This German company offers a wonderful whole-disk encryption with pre-boot authentication solution.  It is 100% free.

In my test of this solution, I used a Virtual PC session of XP Pro.  I set a password and verified I could not log onto the account unless the correct password was used. Then I booted it with Kon-Boot and successfully bypassed the password.

Then I used CompuSec to fully encrypt the drive and set up pre-boot authentication with a password and tested again.

I booted the system again with Kon-Boot

CompuSec caught a checksum error and refused to let the system boot.

Rebooted without Kon-Boot, entered the pre-boot authentication password, and was on my way back to the protected system.  No Windows password bypassing was allows.

Granted, CompuSec takes a while to configure once installed (it does install quickly).

However, the developers provide almost unheard-of documentation and manuals on how to deploy, use and operate their product.

It would be good advice to read all such things before using/installing such a product, but even more so for those that deal with encrypting your entire system.

You don’t want to make a mistake here!

Final Thoughts

I don’t feel that I have done a good job really digging into Kon-Boot and boot kit threats.  There is so much technical information to process and a single blog post really can’t do it justice.

I do hope that this humble post might lead the curious into exploring those better technical materials I posted by real security field experts, as well as encourage others to do like Miles did and perform their own system testing and validations of the tool.

This is not new technology, though the implementations may be repackaged a bit. The security implications remain.

General Windows Local user accounts are inherently insecure to knowledgeable penetrators and a variety of proven methods exist to breach these accounts.

Solutions exist but they generally (by design) reduce the functionality and present numerous barriers for easy and convenient operation of Windows systems by users.

Pre-boot authentication, TPM, and whole disk encryption methods might be the best (current) solution to protect against boot kits.

It remains unknown it me (at this point) what would happen if a pre-MBR boot kit infected system had any of these solutions applied, post-infection.  Would the configuration fail? Would the MBR infection remain resident?  Would it work afterwards?

Special thanks and public gratitude to both Miles and cdman183 for their work and guidance in helping me to understand the implications, verifications of, and mitigation solutions for this current round of boot kit attack.

Like I said, really cool, but kinda frightening…

Cheers.

--Claus V.