Kon-Boot post (minor) update

Just a couple of additional notes regarding the recent post on Kon-Boot.

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

TrueCrypt 6.2 Update and Kon-Boot Protection

Commenter “Bozo” posted this question:

Hey Claus, could it be that TrueCrypt gathers some info about the BIOS (for example, size of BIOS and a hash code)? and the too much memory error reflects TrueCrypt detecting BIOS corruption?

And my response was thus:

I don't think so.

Now, I'm not a TrueCrypt advanced user. I've used it in this test for whole-desk encryption/preboot authentication, but mostly I use it to create truecrypt volume files that can protect key files.

As far as I know, TrueCrypt doesn't do any BIOS hashing. And I guess that's a good thing. Imagine the headache you would have if it did and you did a BIOS flash to upgrade the system. Bummer.

While I was responding, I did check in with TrueCrypt for more info and discovered some more items that could have a bearing on Kon-Boot.

On May 11th, 2009, True Crypt released version 6.2 with new features.

The boot loader now supports motherboards with BIOSes that reserve large amounts of base memory (typically for onboard RAID controllers). Note: In order to be able to take advantage of this improvement under Windows Vista, you will have to install Service Pack 1 or higher first. Service Pack 1 for Windows Vista resolved an issue causing a shortage of free base memory during system boot. (Windows Vista / XP / 2008 / 2003)

See also these links:

• Dell studio xps i7: "bios reserved too much memory" error with TrueCrypt 6.1a - Google Cache page
• [IVIZ-08-003] TrueCrypt Security Model bypass exploiting wrong BIOS API usageTrueCrypt 6.2 disk encryption software released - Heise Security

All this really left me with the impression that the TrueCrypt “pre-boot authentication” was programmed to load itself into the BIOS memory range before it allows the handoff to the system boot. I (still) haven't looked at a TrueCrypt encrypted system's MBR at the sector-level, but I suspect once the BIOS loads to the RAM section, that points to the MBR where it finds the instruction set to load the TrueCrypt loader which has to load into the same lower basic memory range shared with the BIOS.

Normally that wouldn't pose any problems, but in the case of a Kon-Boot, pre-load, it has already loaded it's own modified instruction set into that same BIOS memory range first. So when TrueCrypt comes along and tries to jump on the hay-ride trailer, there is no room left so it fails out.

When I did the first Kon-Boot protection test with TrueCrypt in my original post, I used version 6.1a as can be seen in the screen capture.

With the change of Version 6.2 and its support for systems that load/reserve larger amounts of base-memory for the BIOS, I didn’t know if TrueCrypt still provides that "protection" or not since it...just the situation which might occur with Kon-Boot jumping into the base system memory range first..

So I tested it this morning on an XP Pro virtual machine

I set a new local-user account 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 to verify Kon-Boot was working correctly.

Then I used TrueCrypt version 6.2 to fully encrypt the drive, set a volume password for pre-boot authentication.

I booted the system again with Kon-Boot

Nope; TrueCrypt still would not boot the system and gave the same error as last time:

Error: BIOS reserved too much memory: 569

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

I would say this, it looks like TrueCrypt's "protection" against boot kits (Kon-Boot specifically) is more accidental than by actual design (as in Microsoft's TPM mode).

The Real Benefit of WDE

As I mentioned in my earlier post, Microsoft’s Trusted Platform Mode (TPM) acts in concert with a TPM system-chip to authenticate the core system files during the boot process.  If the expected measurements are off, then the system won’t continue booting.

Whole Disk Encryption (WDE) is another solution offered by quite a few vendors both for $$$$ to free.

I mentioned three:

• PGP Whole Disk Encryption – commercial product.
• TrueCrypt – Open Source product.
• CE-Infosys CompuSec – Freeware product offered by commercial vendor.

In listing them and demonstrating their (current) ability to shrug-off Kon-Boot’s smoke-and-mirrors manipulation of the BIOS to boot-loader to kernel loading, I may have left the wrong perception of their protection.

Unlike TPM, I believe that the protection they offer against off-system (LiveCD) booting boot kits like Kon-Boot is purely incidental.  Specifically, while they do serve to prevent Kon-Boot from staying resident past their authentication scheme (if they will allow it at all), that isn’t actually the true security they provide to the system.

Whole disk encryption, when properly deployed, renders data on the entire disk (or encrypted volume(s)) completely inaccessible to unauthorized folks.  Period.

If anyone were to boot a system with a LiveCD, capture an image, or yank the drive, all they would find is apparently “randomized” garbage across most all the sectors.  Sure it is theoretically and practically possible that the passphrase could be brute-forced and broken, but WDE should discourage all but the most determined or persistent or resource-supported folks.

Because whole disk encryption solutions prevent unauthorized, unauthenticated access to the drive—period—boot kits like Kon-Boot, Vbootkit, and BootRoot just don’t work because the penetrator first has to authenticate the pre-boot loader protection, and un-encrypt the drive to get working. And then, if they did have (or breach) the WDE layer, they still wouldn’t be able to use Kon-Boot to get past the local-user password.

Granted, if someone can break the WDE layer authentication, then the have pretty much pwned the system and could off-load files from the system, booted to or past the OS security layer at will.  And if that is the case, you my friend have much more serious issues to worry about than Kon-Boot protection.

So, the whole disk encryption security layer isn’t based on Microsoft’s rather weak, traditional local-user account security management model, but on a hardened independent authentication layer first.

Does that make sense?

Of course, if there is a root-kit already embedded on the system (or gets embedded on the system while the system is running in a decrypted-state) then whole disk encryption won’t help terribly much.  Sure you still have to authenticate to get on the system, but once it is running, the root kit will kick off like any other system and start doing its dastardly deeds.

And that, gentle readers, will require another solution: GSD post : Anti-Rootkit Tools Roundup Revisited.

So yes, these (and possibly other) pre-boot authentication/whole-disk encryption solutions can block Kon-Boot, but the real security protection they offer is even greater.

Cheers!

--Claus V.