Kon-Boot CD:110KB Floppy image/CD ISO to remove your Windows admin and Linux root pwd(piotrbania.com)
piotrbania.com
Kon-Boot CD:110KB Floppy image/CD ISO to remove your Windows admin and Linux root pwd
http://www.piotrbania.com/all/kon-boot/
6 comments
I recently did some testing of Kon-Boot to see if there were any other hidden surprises (i.e., undocumented, permanent malware infections, etc). MD5 checksums of MBR, BIOS, and Video BIOS images did not change before and after running Kon-Boot on a Dell laptop, nor did Windows-based antimalware apps turn anything up. I strongly encourage others to run their own tests. Even better of course would be for Piotr to kindly release the ASM source code.
Thank you for checking. I wonder if there's any more general solution to the problem of "I don't know whether this is evil code". Checksumming all storage seems a good one. If only it were possible to inspect all system calls and make sure none made permanent changes. I wonder what the state of research is on statically proving assembly code to be non-self-modifying. If so, maybe it'd be possible to prove that certain classes of actions aren't taken (i.e. writing to video BIOS, etc.)
I also did before and after snapshots of the registry and file system. As with any normal boot, there were some minor changes to both, but nothing that stood out particularly. A checksum of the hard drive would of course be different after every boot, with or without Kon-Boot.
I must concur with miles. 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). "Trust but verify" I think someone once said. I certainly am not a programming expert so I can't disassemble such a tool. 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. In the past this is the kind of tool that our technicans and other system administrators would have rejoiced over. 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. Sure we could change their password from our admin service account, but then we would have to leave a note for a callback. This is a transparent "solution" that leaves the passwords intact...just completely ignored. 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. That is why (as miles suggests) Piotr's release of the source code could be valuable. It likely won't detract from the hard work he has done, but would allow skilled coders to understand and "proof" his work. I can only imagine he has his reasons. 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 ( [Dailydave] Nitin Kumar & Vipin Kumar: "please remember to give necessary credit to the authors" PKB. - http://lists.immunitysec.com/pipermail/dailydave/2007-April/... ) and compare it to the eEye BootRoot project http://research.eeye.com/html/tools/RT20060801-7.html . 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. 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. 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 bootkit design http://www2.gmer.net/mbr/ 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. This similarity with MBR bootkits likely leaves some (as seen in the comments) that it must be leaving a MBR bootkit behind. 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 - http://www2.gmer.net/mbr/mbr.exe or GMER - http://www.gmer.net/index.php 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). As miles stated, the MBR is not changed by Kon-Boot. Mitigation? Pretty severe stuff: disable CD/DVD, USB, PXE booting of the system in BIOS. Then password the BIOS. 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. Only then will you likely stand a chance against a Kon-Boot attack...at least on Windows systems. Please Piotr, release your l33t coding! We are dying to know your method!
It installs a root-kit.
My dear zerp, could you please expand a bit on your claim? As stated, it leaves a trifle too much to the imagination. Would you be so kind as to provide filenames, registry keys, et cætera? An ample dollop of detail is just the thing.
Check the boot sector. If I need to spoon feed you, then you shouldn't be running code you don't understand, noob.
As I carefully explained, the boot sector was completely unchanged. However, I'm sure we would all deeply appreciate a link or two to your undoubtedly significant body of work on the web. The way you boldly buck mainstream orthodoxy by replacing the familiar "rootkit" with "root-kit", along with the vigorous application of name calling instead of salient facts, points to a mind unfettered by mere convention. Before tearing myself away from this enlightening discussion, a final word: having registered with this site a mere 4 hours ago, it is perhaps a tad imprudent of you to be wielding the "noob" monicker so injudiciously.
> the boot sector was completely unchanged
perhaps it installs "blue pill."
perhaps it installs "blue pill."
perhaps it installs "blue pill."
Blue Pill doesn't run under Intel Celeron, older Pentium Dual-Core, or Pentium M processors (which lack the necessary VT technology), so if such a payload were included, it wouldn't load on my test system.
For those who want to test it, here are some ideas on blocking and detecting Blue Pill-like infections:
http://northsecuritylabs.blogspot.com/2008/06/catching-blue-...
More information:
http://en.wikipedia.org/wiki/Blue_Pill_(malware) http://en.wikipedia.org/wiki/Intel_VT
Blue Pill doesn't run under Intel Celeron, older Pentium Dual-Core, or Pentium M processors (which lack the necessary VT technology), so if such a payload were included, it wouldn't load on my test system.
For those who want to test it, here are some ideas on blocking and detecting Blue Pill-like infections:
http://northsecuritylabs.blogspot.com/2008/06/catching-blue-...
More information:
http://en.wikipedia.org/wiki/Blue_Pill_(malware) http://en.wikipedia.org/wiki/Intel_VT
It is conceivable that a Blue Pill-like rootkit could be implemented purely in software, in a manner similar to the pre-hypervisor VMWare.
It is conceivable that a Blue Pill-like rootkit could be implemented purely in software
My only concern was searching for persistent infections.
My only concern was searching for persistent infections.
A similar looking project, Vbootkit 2.0, is now open source:
http://www.nvlabs.in/archives/8-Vbootkit-2.0-is-now-open-sou...
Only works in 64 bit version of Windows 7 at present.
http://www.nvlabs.in/archives/8-Vbootkit-2.0-is-now-open-sou...
Only works in 64 bit version of Windows 7 at present.
Perhaps a useful tool for an IT shop. Nothing shocking though as there are few safeguards when an attacker has physical access to a machine. Thankfully, the author isn't implying security vulnerabilities. A good hack, for sure.
I tested it and it seem to work as claimed. Resetting Linux passwords via the boot loader or a live CD isn't hard. But Kon-Boot looks useful for resetting password on Windows machines.
The key difference with Kon-Boot is that you aren't resetting the password, but bypassing it altogether. The machine leaves virtually no trace of having been compromised (though careful study of log files, registry keys, etc could turn up some clues). For simply resetting a Windows user password, Offline NT Password & Registry Editor is swell:
http://home.eunet.no/pnordahl/ntpasswd/
http://home.eunet.no/pnordahl/ntpasswd/
how does he do it?
I have to do this fairly often to both Windows and Linux machines. The only safeguard is to encrypt your disks.