Linux

Linux and Windows compromised at boot

It's not just theory any longer: your computer can be compromised at boot. Chad Perrin reports on a recent proof-of-concept, a boot compromise tool called Kon-Boot.

There's a lot of debate over what constitutes a "secure" operating system. The debates seem to become most heated when people compare the Big Three of home desktop OSes -- Microsoft Windows, Apple MacOS X, and the Linux family of operating systems. Of course, as I pointed out in Is Linux the most secure OS?, it's difficult to convincingly offer a definitive declaration that any given operating system is "more secure" than another.

OpenBSD is rightly proud of its record of only two identified remotely exploitable vulnerabilities in default configuration through its entire stable release history, but even this is not proof positive that an OS is the "most secure", considering that security needs change from one system deployment to another.

Ultimately, any of the widely used general purpose OSes can theoretically be compromised. The recent popularity of virtual machines, allowing one to simultaneously run multiple virtual computers on a single physical hardware platform, has provided hints of one particular threat that may apply even to an OS running outside of the controlled environment of a virtual machine: compromise by altering the OS image in memory during boot. This kind of danger has become something of a common bogeyman for VM users, as they worry that some piece of malware may be able to break free of the limits of the VM, and affect the OS in ways that have not previously been a concern for operating system installs on "bare metal".

In theory, however, there is no specific reason something similar cannot be done to a system running without the virtual machine environment, as long as malicious security crackers can find ways to access the machine's boot process itself. This may be prohibitively difficult to achieve remotely, at this time at least, but it presents a very worrisome state of affairs for cases where a security cracker may have physical access to the computer.

In the case of Microsoft Windows and certain Linux distributions, this concern is not just theory. It is also a very concrete reality. Piotr Bania has put together a proof of concept, a boot compromise tool called Kon-Boot, which so far has been tested and confirmed to work on at least four Linux distribution releases and a slew of common MS Windows releases.

The tool can be used for legitimate purposes, from security research purposes to simple recovery of a system where the administrative password has been lost. In the words of the creator:

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.

If you want to protect your computer against root compromise by someone with physical access to the machine, this provides an excellent case for removing any CD, DVD, and floppy boot capability, eliminating any external device ports that may be used to introduce boot capability outside of the internal hard drive, and lock the case.

You may also want to lock it in a closet, and perhaps use an operating system that hasn't yet been targeted by this particular boot compromise tool, such as MacOS X or a BSD Unix OS like FreeBSD. Though it may only be a matter of time before these other OSes are similarly compromised, at least for the time being you can be reasonably certain they're ahead of the game, even if only by chance.

Ultimately, the moral of the story is simple: be careful who you let near your computers, and under what circumstances you allow access.

Worried about security issues? Who isn't? Delivered each Tuesday, TechRepublic's IT Security newsletter gives you the hands-on advice you need for locking down your systems and making sure they stay that way. Automatically sign up today!

About

Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools.

58 comments
tolosaero
tolosaero

the problem is with the test drive v.X of the computer.Tell me the price and how the computer operates again

jpr75
jpr75

I downloaded the latest .iso image, burned it to a CD, and booted up my test Win7 RC PC with it. It loaded up to this splash screen that just sat there with a scroll bar advertisement at the bottom. I finally hit any key (spacebar) to see if it would do anything, and it loaded some data and then switched to a F8 like Windows boot menu. I chose Windows 7 from the menu (only option listed), Windows booted up to the normal Windows login screen. I tried logging in using the local Administrator account (that is enabled) and any random password. I was denied access. Tried 3 more times, and tried with no password. Windows would not let me in. So, unless there is some trick not mentioned on the web site, it does not work. Per the web site, "No special usage instructions are required for Windows users, just boot from Kon-Boot CD/Floppy, select your profile and put any password you want. You lost your password? Now it doesnt matter at all ". Anyone else get this to work?

compuwysepc
compuwysepc

We've been able to change or remove the Windows passwords for a long time with the use of offline utilities, so where's the shock element in this scenario?

george.hickey
george.hickey

... if you have physical access and an installation or a Live CD. That's why God invented door locks! ;o) If you can't physically secure the machine, use full disk encryption - it's the only thing that offers a reasonably good defence against someone who knows what they're doing... just don't lose the keys!

dcolbert
dcolbert

For Win32 products since NT 4.0 at least, if you have physical access to a machine you can simply reinstall NT non-destructively over the top and gain access to all data contained on the drive. Once you have physical access to a machine, it is pretty easy to get by almost all 1st level OS security unless there is some specific data encryption going on at the file level.

t123456789876
t123456789876

...you can just remove the hardrive and leave with it. This is why what you describe is not considered a security hole of the OS. The only way to avoid that kind of vulnerabilities is to encryped the whole disk, which is worth only for really critical material.

NickNielsen
NickNielsen

Remote exploit coming soon. Oh, bugger!

dreamor
dreamor

This really isn't an OS vulnerability. I'm not a hacker/cracker, but if I have physical access to a machine I can break in regardless of your OS and without use of this tool. The only thing that would make it difficult is an encrypted disk. If a hacker/cracker has the right tools and your machine is on (key is in memory) then they can get by that too. IT Security, like all types of security, is about making things harder to compromise not making it impossible.

Neon Samurai
Neon Samurai

.. always something interesting waiting in my morning meeting. Thanks for another addition to the PDF library.

seanferd
seanferd

Now I know where to direct all the "pasoward beakers" in the forum! Kthx! But seriously, this boot vulnerability is a bit creepy. Let's see who bothers to deliver patches.

apotheon
apotheon

It's always nice to find another reason to feel good about my choice of FreeBSD as my OS of choice -- even if the same problem may eventually arise for FreeBSD, just as it has for Linux-based and MS Windows systems.

Dumphrey
Dumphrey

not in the current form of this "exploit" but in its design and future possibility. This exploit writes to the OS and kernel on Boot. The fact is, *nix and BSD passwords have been difficult to recover in the past. Not impossible, but difficult. DES became unreliable, and so many distros switched to PAM modules, which allowed more robust encryption. This is now on its way to being null and void. A compromised machine could have code installed that would apply this "patch" by forcing a reboot, then deleting the code. And since its root level, and pre-os, you would be very very hard pressed to find the problem. To sum it up very briefly, this "exploit" is the precursor to "passwords/phrases don't mean $hi7".

apotheon
apotheon

How does an installation CD give you root access on the already installed system? That'd just let you install a new OS.

Slayer_
Slayer_

And heck I know an easier way that involves screen savors and the recovery console on the CD.

Neon Samurai
Neon Samurai

With truecrypt, full disk is easy enough to do that it doesn't even need to be a critical system. If workstations are not shared among users, they could easily be encrypted leave each user with a dedicated machine, long passphrase and standard login password. The biggest challenge is having users choose strong passphrases. If your workstations are shared among users then they either have to share the passphrase or have an office wide standard passphrase; both are not ideal though.

apotheon
apotheon

In some respects, that's sorta the point: there's a way in, and the best you can really do is take great care to deal with the unknown vulnerabilities that must inevitably exist. Certainly, some OSes make certain types of compromises much less likely than others, but that doesn't mean that nobody can ever find a way to gain the same kind of unauthorized access to the system. A key function of the security professional is to comfort the disturbed. Another, though, is to disturb the comfortable. Hopefully, I've managed to do a little of the latter with this article.

Slayer_
Slayer_

You really don't need a tool to break into a computer if your phsycially sitting infront of it. I've probably done it 20 times now, people phone in saying they lost their admin password, I break in and reset their password for them.

apotheon
apotheon

Excellent! Often enough, spreading knowledge is its own reward. Thanks for the kind words.

apotheon
apotheon

Actually, you can't just patch this away. The problem is something outside of the operation of the OS itself, as it is currently constructed, basically. How do you patch the OS against something that basically tells the computer to boot an OS other than what's on the hard drive? This thing tells the system to boot something that's exactly like the OS on the hard drive, except for a modification. It is, in fact, a dynamic patch to the OS, itself. The fix to this has to be something outside the OS.

rbees
rbees

seams to have no files on it. I did boot with it in the drive and it did seam to do what it is suppose to. I did not log into my system with it. Strange that it seams to have no files on it. I have check it both in Debian Squeeze with Midnight Commander as root and Vista. Both report it as empty. Yet when booting it clearly has something on it.

RipVan
RipVan

"you want to protect your computer against root compromise by someone with physical access to the machine, this provides an excellent case for removing any CD, DVD, and floppy boot capability, eliminating any external device ports that may be used to introduce boot capability outside of the internal hard drive, and lock the case. You may also want to lock it in a closet... etc..." You forgot to mention stationing a guy with a sword outside of the closet. :P

mckinnej
mckinnej

In my mind, if a criminal, and they would be a criminal at this point, has gained physical access to a machine, your security has already failed. From the sounds of it, it seems a lot easier to protect the machine physically than fret over defending it internally when it may not be possible. You have to look at this from a risk point of view. Although it is possible, it is not probable, at least in any production environment I've been in. What I see as a much more dangerous risk is getting machines compromised at the source. What if that shiny new box you're about to install is already infected? Now that would be a huge mess, especially if this thing has a way to propagate itself to other machines once it gets inside.

Neon Samurai
Neon Samurai

One of my side projects is popping my manager's password (without logging in as Admin; that would be cheating). Between this little utility and the Samurai liveCD, it's looking like a fun work day.

Jaqui
Jaqui

Found: 119 Secunia Security Advisories for openBSD Found: 164 Secunia Security Advisories for freeBSD. though it's not as bad as it could be still, Vista 555 vulnerabilities.

jpr75
jpr75

The web site is one page. There isn't a lot there. Either the hack works or it doesn't.

Neon Samurai
Neon Samurai

if you can bypass the authentication mechanism then it doesn't matter if that is a password or dna sample since it won't be compared and challenged.

wdewey@cityofsalem.net
wdewey@cityofsalem.net

Not an install CD. I am pretty certain you know what can be done by booting to a CD on a local machine so I won't add anything to that. Bill

apotheon
apotheon

Well, yeah -- I never said that being able to crack passwords on MS Windows wasn't possible before this. This is an interesting approach because it rewrites part of the OS itself (in RAM) during boot, though, which is certainly not a common exploit vector. This should be a bit more troubling for users of Linux-based systems and, by way of demonstration of the concept, to users of other non-Microsoft OSes, precisely because it allows easy compromise of something that is not typically easy to crack on most such systems. After all, with one of the affected OSes (such as the Ubuntu release indicated on the site), the system's vulnerability to administrative password compromise at boot is now identical to that of MS Windows; that's not exactly a reassuring description of the level of security provided.

seanferd
seanferd

from working on a BSD system? When I thought of patching, I thought of eliminating the ability to compromise accounts (break administrator or other account password). Of course, booting any other operating system that can read the FS of the installed OS can ... read the files. (If the disk is not encrypted with something worth it's salt.) I'll definitely have to look deeper into this and see what I'm missing. Thanks! And no, you probably don't need no steenking badgers ... er, patches.

Dumphrey
Dumphrey

to use encrypted boot/data volumes. Yes, Kon-boot can initiate the loading of the OS, but if the "hacker" does not have the password for the OS volume, the loading errors out and the volume will not mount. Eventually there will be a tool around this as well. But for the time being, volume encryption seems to be the answer.

Slayer_
Slayer_

The old cases with removable HDD's are the most secure, even if a hacker was in front of the computer, if you took the HDD home with you every night, they would get jack all. Just insure the drive is encrypted in a way that it will only work with the one system, and your set. The hacker would have to both steal the system and the HDD, and if they are both in different locations, then it is unlikely. Heck, make the HDD automatically wipe it's own memory, maybe blow out seals or something, when it is tried to be powered up by a system that is not it's own.

NickNielsen
NickNielsen

I strongly suspect the program resides only in the boot sector of the disc and doesn't use any of the sectors accessed by the OS when searching for files.

Dumphrey
Dumphrey

vertically challenged persuasion. And then gave them laser beam eye and chainsaw hands. No one will steal my breakfast cereal!!!! No really, this kind of security is normal in more controlled environments. Bolting the case down is also not unheard of. It reduces the chance of leaks in secure projects, loss of data, and limits infection vectors for worms and virus. I even know one man in my area that fills the usb ports with epoxy.

Neon Samurai
Neon Samurai

The building campus protects itself. The buildings protect themselves. The networks protect themselves. The servers protect themselves. The workstations protect themselves. The users protect themselves. Your Strategy should go from absolute perimiter down to the indavidual user with protective layers everywhere availabe inbetween. If physical security fails, that machine should do all it can to protect itself; hardened local system and strong passwords. If network security fails, the machine should still do all it can still; local firewall, strong passwords, encrypted protocols and storage. Simply leaving the inside wide open because a physical access point failed may indicate a problem with your security practices more than the inherent risks of physical access to a workstation or server box. Your better off to assume each security point will be breached so what can the hard points beyond that failure do. The licensed pilots out there have a similar approach; you don't stop flying the plane until it's buried in the ground or landed cleanly. There is no "oh my god we're going to die" giving up from the pilot when there is a plane full of passengers strapped to his ass.

apotheon
apotheon

What I see as a much more dangerous risk is getting machines compromised at the source. What if that shiny new box you're about to install is already infected? Install a non-default OS. That'd help.

apotheon
apotheon

The details matter. OpenBSD has had only two remotely exploitable vulnerabilities in default configuration.

Neon Samurai
Neon Samurai

It's a single page, it discusses the utility and gives the required steps to use it. While the TR journalists provide this kind of information. The regular visitors have discussed this in the past. We can't confirm ownership through a message forum so providing details on using such utilities falls to your preferred internet search engine or the developer's website.

Neon Samurai
Neon Samurai

With a remote console you can see everything from first screen flicker to login prompt. For schedualled boots, you can go through that way entering your long key phrase between post and OS loading. For random reboots, it's going to mean an admin connecting to the management console or visiting the physical box. When you get into server farms and centralized management consoles, things could be a problem. Anything automated would negate the reasons for encryption beyond protecting a dormant drive. With servers, it seems to be down to physical security. A server sitting under the tech's desk isn't a server.

g_panayiotis
g_panayiotis

I agree with Neon Samurai's last post on install cds, however I will say that almost all installation medium I have used from linux distros have a way to get a shell console. Another point is that this tool works on the assumption that the BIOS has been configured to boot the system from floppy or CD in the first place. Setting a HDD only boot, password locking the BIOS and password locking grub can seriously undermine an intruder's attempt. However the said individual can still physically break in the system and reset the system BIOS to circumvent some of these checks. Encryption is the best option but it is too cumbersome for a production server. Operators need to be there on a very short notice to provide the passphrase so that the system may boot again after a system restart.

Neon Samurai
Neon Samurai

"if you have physical access and an installation or a Live CD" You mentioned the install CD first but not all of them provide a system rescue terminal. Generally, the install CD will only provide an install unless your going to do some grub magic at the boot prompt. If your gunning for the admin shell that you can usually drop to during boot, you can add a password too it if the machine is an asset worth securing. This is a configurable option you can put in place. You can also password protect the boot loader so that anything but the normal load option requires a password. You get a hash of your password, drop it in the grub menu config. If your BIOS password is already in place and drives encrypted, a criminal won't be enabling "boot from CD" or decrypting the hard drive with a liveCD within any reasonable time. Based on the five or so specialized liveCD I have in my toolbag, drive encryption with a strong passphrase or cert keys isn't going to open up with a quick utility.

g_panayiotis
g_panayiotis

the point raised is that most installation CDs for linux distros offer some kind of cut down shell, in the same way live CDs offer full shells. from this point one can perform management tasks with "free" access to the HD. The point of the Kon-Boot exploit is that it allows you access to a system without reverting to some root password reset procedure, giving you the benefit of stealth. however, even using a password reset procedure can allow you basic access to authentication libraries and "patching" them would achieve the same result. there are counter measures to that and counter-counter-measures etc etc etc the point of the Tool is that no OS is secure when one has physical access to the machine. Barring disk encryption (which can be circumvented only on live systems), there is nothing to protect a physically exposed system to a professional this discussion cannot and should not be turned to a xOS vs yOS debate because this offers nothing. it is not a failure on the OS level. on the other hand I believe that some checksum/signature tools can detect anomalies in the kernel signatures in memory, which would indicate that such a tool is in place. can anyone comment on that?

apotheon
apotheon

Why did you mention an installation CD, then?

Neon Samurai
Neon Samurai

Run authskip.exe in the same directory as awsomegame.exe and it skips the disk or key authentication step during program startup. Same idea but at the OS level from what I can guess.

apotheon
apotheon

As I understand it, how the password authentication system is implemented is irrelevant, because this tool just bypasses the part that actually does a password comparison.

seanferd
seanferd

of storing account passwords in a BSD is inherently more secure, it is simply that this functionality has not been written into the program yet. Thanks again.

apotheon
apotheon

The reason it doesn't work on a BSD Unix system is simple: the guy who created it hasn't created a version that works on any BSD Unix OSes. Maybe someone else has, but we don't know about it. We just know for certain that it works on those MS Windows and Linux-based OSes listed on the site.

Neon Samurai
Neon Samurai

Ok.. two if you count bruteforcing the password assuming there is no kill limit for bad tries. But going through a cold boot memory attack isn't a weekend project for a skript kiddie. Get the machine after shutdown but within the retention limit of the ram, pop the ram and drop it into freezing fluid, analys it with a test bench and cold boot utils in hopes of getting the encryption cert out of it. That's no simple download of "mewannabebadass.exe" and run against a target IP.

Dumphrey
Dumphrey

but with kernel level boot mods, there is no foretelling the possible exploits to be found. Personally I have good faith in truecrypt, and even in the default libcrypt used by Debian during the OS partitioning and install. Even in a computer theft scenario, the avg script kid with a boot disk would not be able to crack even an old version of either encryption. To the best of my knowledge, all exploits against either program have come from well knowledgeable, practiced "professional hackers." The process is several degrees higher then facerolling a key for WEP.

Neon Samurai
Neon Samurai

well, Truecrypt, PGP Desktop and a few others. I hear the PGP guys are pretty good so it would be a matter of how fast customers update. Truecrypt's nature will be to adapt if issues are found. Windows native encryption I don't know enough about to speculate. There must be other options also but those are what I can think of off the top of my head. My theory is that by the time current volume encryption is found to be weak, we'll already have stronger math or utilities available.

Neon Samurai
Neon Samurai

I skimmed the website also and it indicates the same. " 3. Type 'kon-usr' as login, if it works you should be now in the system 4. !Remember! to restore the system when you are leaving, you can do this by typing 'kon-fix' as login again. " I'm guessing the "kon-fix" restore is to clean a system that's being left on versus clean a drive stored change that remains after reboot. I'll confirm later against a VM though. At 110k, it takes longer to type the scp command then to actually send to my playpen at home. I agree that any user made changes are being done to the live system and would be saved during shutdown of not at time of change. My concern is using it on a live system and having the patched kernel sucked out of memory and back onto the disk. Opening a system during a pentest or password recover; good. Leaving an account behind without a password requirnment; not good. Hm.. I may fire off an email linking back to the article and discussion. Maybe the developer will interested enough to join in as others have.

apotheon
apotheon

Volume encryption that "lives" outside of the OS may indeed plug this hole, temporarily. On the other hand, such encryption tools are likely to be vulnerable to the same kind of compromise, if someone goes to the effort of developing the compromise. Remember, the whole point of this compromise's function is to allow one to gain access without having to know the password. Offhand, does this live in memory only? Is it safe (ok, safe'ish), to run against a production system or will it write it's OS modifications too storage? I don't really know. I haven't tested it on a production system or anything like that. In theory, it shouldn't do any damage to the installed version of the OS, as the whole point is to affect what gets loaded when the system boots. On the other hand, any changes you make while the system is running under the influence of this should, indeed, be "permanent". That's you, though, and not the tool. You might try getting in touch with the tool's author to find out what kind of danger it may present on a production system, and decide for yourself how well you trust that person.

Neon Samurai
Neon Samurai

I read the article quickly so I may have missed the detail but wouldn't encryption mitigate this anyhow? If you boot from liveCD you can't mount the encrypted disk unless your bootable disk has the encryption software and you know the key/certs. If you boot this and your not the system's owner, you either get this not able to read the encrypted drive or able to read far enough to request the certs/passphrase. If you don't have them, you don't go any further. No need for removable drives. It does cause the issue of each user requiring an office wide passphrase or remembering there own and loosing the freedom to use any machine in the office. I may get some time today to try it against an open and encrypted system. Offhand, does this live in memory only? Is it safe (ok, safe'ish), to run against a production system or will it write it's OS modifications too storage?

Neon Samurai
Neon Samurai

Thing with ISO and repositories is that it'd be like poisoning the food supply; sounds easy but isn't at all. Repositories all do hashing checks to validate that a package was not changed during the download. The repositories themselves are well kept. If you download something outside of the repositories, md5 hashing checks apply there also. Same for any platform, download from trusted sites and validate the downloads. Actually, win7 is having some issues right now along the same theme. The win7 ISO from microsoft is good and anyone downloading an RC should go to MS for it. If you download the win7 infected ISO floating around the questionable websites; your a bot. Oh, the food supply reference: http://www.schneier.com/blog/archives/2009/05/attacking_the_f.html about half way down the blog page if the link above doesn't work.

wdewey@cityofsalem.net
wdewey@cityofsalem.net

I think the point was not that the box had a compromised OS installed it was that the installation source needs to be verified. If you have a compromised CD downloaded from what appears to be a valid source (Say the FreeBSD web site was hacked and compromised images were uploaded) then it doesn't matter what OS it is because the install is compromised. Bill

Editor's Picks