Submitted by At the Black Hat Conference in Amsterdam, security experts from India demonstrated a special boot loader that gets around Vista’s code signing mechanisms.
Vista’s Code Signing Compromised
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
so much for signed drivers.
from the article
“the “boot kit” managed to run with kernel privileges and issue system rights to a CMD shell when running on Vista RC2 (build 5744), even without a Microsoft signature.”
hello ? Vista went RTM November 2006, who on earth is using RC2 ???
“Nitin and Vipin Kumar told heise Security in an interview that this approach would also work on Vista Final (build 6000). They said that the only thing that stopped them from subsequently porting their kit to the final version of Vista was the cost.”
I’m sure if they are determined to make a live CD that can boot vista and subsequently hack it, they will. If someone has access to your PC and can boot it with any CD then what hope do you have ?
TPM it seems is the answer (Trusted Platform Module).
“The two experts remind everyone that although Microsoft is able to raise the bar higher for boot kits by adding on additional queries and increasingly clever algorithms, the only way completely to stop unsigned program code from being executed is by using TPM hardware.”
interesting….
cheers
anyweb
The article says it will also work on Vista RTM:
Nitin and Vipin Kumar told heise Security in an interview that this approach would also work on Vista Final (build 6000). They said that the only thing that stopped them from subsequently porting their kit to the final version of Vista was the cost.
They probably know it works on Vista final because they did it on a pirated copy, and they don’t want to reveal that, so they just said they did it on RC2 and “just know” it also works on gold-master Vista.
This isn’t a matter of someone else “hacking” your PC–it’s a matter of you “hacking” your PC back from Redmond. This has some serious implications for the kernel-level DRM in Vista.
Edited 2007-04-04 18:02
It’s a matter of taking a machine that is fundamentally unlimited in function (i.e. Turing complete) and then marketing software that claims to prevent undesired functionality from being implemented. There’s always a way to change the behavior of a machine with nothing but the system binaries and some considerable skill.
How do you think a debugger works? It patches instructions on the fly to produce traps wherever you want to stop execution. That’s the same fundamental principle used here to sidestep the trusted code restrictions. Of course Microsoft doesn’t ship a kernel debugger with Windows, but they can’t prevent an expert kernel hacker from shoving a primitive “debugger” into the kernel image and then using it to noop the offending code before it runs. I use this technique all the time (with a real kernel debugger) to work around broken code in development kernels.
Patching a live running kernel image is tricky (this is an understatement), and I wouldn’t recommend running such a kernel in a production environment unless you really trust the source of the patch, but it is possible. OS vendors have been discussing for years how they want to be able to patch a live kernel in order to eliminate downtime due to kernel updates. Several trademarks have been reserved for such features, although nobody has brought it to market… yet.
I’m really surprised that you think Windows doesn’t have a kernel debugger. It’s had one since the beginning of the NT project. You have to enable it by booting with /debug. You can connect by USB, Firewire, or Serial port and do all kind of wonderful things to it. You can access it using ntsd.exe, which is shipped with windows, or using WinDBG, a free download from Microsoft. There’s also the LiveKD option, which lets you inspect, but not modify the system while its running.
Patching a live running kernel is also something that Windows can do. I don’t know who does it or why, but there’s a mechanism for hotpatching. Interestingly, all x64 binaries following the Windows ABI explicitly start their function with a 2-byte nop and a 5 byte empty region before the entry point to support hotpatching. I think the x86 kernel also structures its entrypoints in the same way to support hotpatching.
The main reason these guys used bochs is that they needed a way to debug the code without tipping off to the system that it was being debugged. The KMCS code probably doesn’t run or has anti-debugging techniques embedded to prevent people from simply using the KD to inspect it.
I stand corrected. My Windows knowledge is sadly out of date…
“The two experts remind everyone that although Microsoft is able to raise the bar higher for boot kits by adding on additional queries and increasingly clever algorithms, the only way completely to stop unsigned program code from being executed is by using TPM hardware.”
I have yet to be convinced of that (that TPM would block untrusted code). It wouldn’t be sensible anyway. Think of all those websites that use Javascript somewhere – would it make sense to block them because they’re unsigned? Then the web will look rather dull. But if you run them and your browser has a security leak – bang! you’re pwn3d.
My guess – not verified, but maybe someone here can confirm this – is that TPM blocks unsigned *machine* code, i.e. the stuff that is interpreted by the CPU, not by some program. This may help, but a lot of security problems nowadays don’t come from untrusted machine code, but from untrusted script code.
As far as I’m aware, the TPM itself has no capabilities to block code. The vendor’s code would perform that function. The TPM would just give you a secure facility for generating hashes of interesting attributes of the system’s current state and/or storing keys used to encrypt/decrypt that data so it can be analyzed in some way or compared to previous states. It’d basically be similar to how MS currently uses TPMs (when available) to gather and compare certain boottime metrics (attributes of the BIOS, bootloader, etc.) to determine whether the system has changed/been tampered with before releasing the keys to decrypt the harddrive.
It’d basically be similar to how MS currently uses TPMs (when available) to gather and compare certain boottime metrics (attributes of the BIOS, bootloader, etc.) to determine whether the system has changed/been tampered with before releasing the keys to decrypt the harddrive.
That’s the key point. The TPM has been designed to block code to sit in the middle, AFAIK, that is between the hardware and the software it starts (OS). It is supposed to get hard to (say) remove an encrypted PC HD and to decrypt in your own lab because you would need keys which reside in TPM.
I’m not suprised by what researchers found as this is just why TPM exists. As many protection schemes showed, software only has a low degree of security when it’s not coupled with h/w. Of course, we’re talking to hi-end systems here.
“”The two experts remind everyone that although Microsoft is able to raise the bar higher for boot kits by adding on additional queries and increasingly clever algorithms, the only way completely to stop unsigned program code from being executed is by using TPM hardware.”
I have yet to be convinced of that (that TPM would block untrusted code)”
well, tpm hardware is exactly that, hardware.
EG: the TPM chip on the motherboard and (for example) a fingerprint reader on the computer.
image a scenario where a TPM enabled computer has the fingerprint reader installed and TPM enabled, in order to BOOT the computer to a CD (or any other device) the owner MUST swipe their finger to complete the security process at BIOS boot time (before cd/hd/dvd/nic/usbkey are accessed)
so in that case TPM could indeed be useful.
I use TPM on my laptop with fingerprint scanning to unlock the bios password (to boot the computer) and login to the domain.
The first part of that process is OS independant (so linux/osx/windows is fine) the second part is windows only).
cheers
anyweb
“image a scenario where a TPM enabled computer has the fingerprint reader installed and TPM enabled, in order to BOOT the computer to a CD (or any other device) the owner MUST swipe their finger to complete the security process at BIOS boot time (before cd/hd/dvd/nic/usbkey are accessed)”
Lol, you could invite them to beer, take the bottle with the fingerprint and generate a fake one (of some kind of material), wait until they leave their place. Go in with your fake finger, boot the computer (use boot kit as needed), if he had password, find it with the hw keylogger you attached some time before to his keyboard. Log in the computer, attach your usbdisk, then you can copy all the porn the guy has been downloading during the years. Now you can go home, ‘mission impossible’ accomplished.
Sorry for the joke, but i couldn’t hold myself.
I guess if things keep up like this with Microsoft stuff (vista, ooxml et all), chairs must be running out in the premises. 😀
Rofl, I feel bad for Microsoft’s poor DEVELOPERS, DEVELOPERS, DEVELOPERS.
I could see the positive from this: Imagine having control other Vista’s core in the same way you do with open source OSs.
Plus it’s a tricky one to build into malware (unless they write the program into the boot sector? Can that be done?)
My thoughts exactly.
Growing up, the biggest problem when getting infected was a boot sector virus. They usually came on a diskette and no matter what you did, every time you rebooted, blahmo! At the time, the only thing you could do was C:>fdisk /MBR and even then, you couldn’t be certain you got rid of it. Usually, the little critter copied itself into memory and check every so often to see if the boot sector still contained a copy of itself and if not, just copy itself back in there.
Later, anti virus apps got better at dealing with them but they where incredibly popular, not to mention effective, until the net come along.
Yeah – that’s what I was thinking about when I asked. Seems like yonks ago and wasn’t sure if my memory was going in old age lol
Back on topic though: I can’t see many people writing MBR virii for Windows when Worms and Trojens are much easier to code and just as effective.
….That said, building a bot net with systems you have kernel access to could be tempting to a few.
Microsoft could just release a patch to look specifically for any widely-deployed bootkit and bluescreen the machine as soon as it is detected. Neither patchguard nor kernel mode KCS are meant to be the the final solutions in their classes. They are meant to be patchable to handle new exploits.
Protected media is harder to protect indefinitely though.
I think other researches showed that there is no way to know if your system (OS) is runinng in a protected / virtualized sandobox if the loading technology doesn’t reveal that to you.
I don’t think it’s a matter of patches. Simply, software has its limits and provides a certain degree of protection which can be circumvented unless you can lock it in a scheme which depends on a non-software variable key. Which could be in your finger thumb or a password (or multiple passwords or whatever).
The key of this is the fact that the software DOESN’T contain the key to unlock itself (or it will be found, in a way or another) and that software itself will be unusable of any machine / mix of h/w unless the arbitrary original key is provided.
“Microsoft could just release a patch to look specifically for any widely-deployed bootkit and bluescreen the machine as soon as it is detected.”
LOL, the worlds first ever OS vendor sponsered DOS. So once the patch is out the black hats just see what can trigger it and now you have 200,000 vista machines blue screening.
Great idea there chief!
I’m assuming that a bootkit like this would be applied by the machine’s administrator for the purpose of pirating protected content. I’m also supposing that you’ll want to know if your machine has a bootkit taht as installed without your knowledge.
Either it harms you if you’re a pirate, or informs you that you’re compromised if you’ve been unaware. I don’t see a problem with this idea.
The problem here is that most people would then think their PC was dead and spend money trying to get it fixed. It would be a MESS. It would be like the blaster worm where you PC would just keep rebooting. But in this case it would just keep giving you a crazy blue screen. (And MS never puts good messages in those blue screens!)
They need to add a checker to Windows Defender or something. Then it could tell you if you have strange code running. Without crashing your PC every time you boot up.
Whoops!
Hope nobody was actually relying on this….