Pre-boot attacks: Kon-boot and other tools

Date : June 08, 2009


Last month, one of the Cert-IST members called our attention to the release of a new hacking tool, called Kon-boot, which allows to login onto a computer as the administrator without knowing the associated password. Nothing new until now since there have been bootable CD-ROMs for several years, which allow to reset and set a new password for the administrator’s account on a computer. Yes, but the new Kon-boot hacking tool we are going to introduce in the present article, allows among other things to take the full control of a system without altering any data on the hard disk of this compromised computer. In addition, it is the original operating system which will be booted by Kon-boot (the one installed on the hard disk) and not a specially build operating system that is executed from the bootable CD.

Before dealing with the thick of things, we would like to point out the fact that testing such hacking tools may be very dangerous. In fact, nothing can tell if there are or not malicious hidden features in the given tool, particularly in a utility like Kon-boot for which the source code has not been released on Internet. Thus, we advise you to be very careful when performing such tests, and we recommend the use of a dedicated machine isolated from the rest of the network.


Basically, how does it work?

The Kon-boot utility, which is free for download, is shipped as a bootable CD image. Its author mentions that it is compatible with most versions of Windows (2003 and 2008 Server, XP, Vista and even several pre-releases of Windows 7) as well as with various Linux distributions.

The attack may be performed as follows:

  • First, insert the bootable CD into the targeted computer’s drive.
  • Boot or reboot the computer, ensuring that the CD-ROM is the first bootable drive (the CD must appear before the hard disk in the boot sequence set in the BIOS).
  • Just after the BIOS checks, a splash screen appears to indicate and confirm that the computer has booted from the Kon-boot CD.
  • Here, you just have to hit the “ENTER” key so that Kon-Boot starts the hacking process and gives back the control to the originally installed operating system, which will boot exactly as usual.
  • The operating system login screen will then appear.
    On Windows, you just have to choose the account name you want to compromise and enter whatever password you like, an empty password can do the trick as well.
    On Linux, you just need to enter “kon-usr” at the login prompt and you will automatically be logged-in with root privileges (UID 0).

From this experience, we can deduce that, just before handing over to the legitimate operating system, Kon-boot has performed some low-level hacking tricks, which allows it to keep one or several backdoors on the system along its execution.

At this point, we have to admit that this tool is somewhat frightening from a system administrator’s point of view. In fact, there are already well-known techniques allowing to achieve the same goal but they all have some drawbacks and may e.g. leave some evidences of the compromise:

  • Password cracking tools such as Ophcrack and L0phtcrack can/do 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.
  • Using a bootable CD that overwrites and resets the administrator’s password leaves evidence to the end-user that something has been breached.
  • Finally, yanking the drive or booting with a Live CD in order to access to data is feasible but may be time-consuming and difficult depending on the hardware used.

The major benefit of Kon-boot from a hacker’s perspective is that it allows him to boot directly on the operating system installed on the machine, to login under the administrator account and to perform tasks of his choice. Of course, an incident response investigation might find some evidence tracks of an illegal access afterwards, but with the password left intact, it might take a while to notice the breach.

On another hand, system administrators and security experts who have to troubleshoot and investigate systems may often find users who have forgotten or do not want to provide them the password. So, we suppose it could be a useful tool for legitimate and authorized situations (incident response, Forensic etc.).


Kon-boot is not alone

Kon-boot fits nicely into a class of hack/security tools called boot kits. Bootkits have been actually well known for a long time: let’s recall with nostalgia viruses in the 90’s which were spreading by infecting the MBR (Master Boot Record) also called the boot sector. In particular, they have recently started to regain notoriety in security circles with the release of a number of new proofs of concept and malwares:

  • eEye bootroot: This tool was presented at Black Hat USA 2005 by the researchers Derek Soeder and Ryan Permeh.  It is an example of a technology that allows to corrupt directly in memory the Windows system kernel during its loading.
  • eEye SysRQ2: This bootable CD image allows a user to open a fully privileged (SYSTEM) command prompt on Windows systems by pressing a combination of keys at any time after start-up. It was first demonstrated at Black Hat USA 2005 by researchers Derek Soeder and Ryan Permeh as an example of applied eEye Bootroot technology.
  • The MBRoot or StealthMBR Trojan: Discovered at the beginning of 2008, this Trojan alters the MBR and uses rootkit-specific techniques to hide its activity on the infected system. For instance, it systematically redirects all read/write operations of the MBR (first sector of the hard disk) to a copy of the original one, which makes detection and eradication of such a malware very difficult for the various antivirus solutions.
  • NVlabes Vbootkit 2.0: The source code of this bootkit was released in version 2.0 a few weeks ago. This proof-of-concept tool grants various abilities such as elevating permissions to SYSTEM level, starting a telnet server automatically or manipulating user passwords.

Modern bootkits are very similar to rootkits but operate differently. While rootkits require elevated privileges to be successfully installed, bootkits take advantage of the boot to inject directly their own code in the memory code of the operating system.

Some bootkits are persistent, meaning that they remain on the system even after a shutdown or a reboot of the machine: it is the case for example of the MBRoot Trojan mentioned above. On the contrary, some bootkits are memory-persistent only: they only affect a system when it is booted from a specific bootable media and they do not leave any evidence that the system could have been compromised (e.g. no data are modified on the hard disk).

Kon-boot is the last-born of these hacking tools and has the valuable quality to be non-persistent and very simple to use, as we explained in the previous paragraph.


Technical details

The source code of Kon-boot has not been published by its author so we have not the possibility to know what it does exactly to hack the operating system. However, we can make some hypothesis based on known technologies to determine how it works. In general, bootkits basically hook the 0x13 interruption routine that is usually provided by the BIOS of the computer. The role of this routine is to read sectors from the hard disk and to load them into a given location in RAM memory. By hooking this routine, bootkits such as Kon-boot or Vbootkit modify directly the code of the operating system when it is copied into main memory, just before its execution.

In order to evaluate how Kon-boot works, we have tested it on a laptop on which Windows XP was installed. We actually noticed that it was really easy to login with the administrator’s account on this computer. But fortunately for us, unfortunately for the hackers, we were then unable to perform some specific tasks under the Windows session. Here is a non-exhaustive list of things that Kon-boot does not allow to do:

  • First, it is not possible to change the password associated to the account used to connect. However, changing the password of other local accounts on the system seems to be possible.
  • The files encrypted with the EFS (Encrypted File System) Windows feature cannot be opened. An “access denied” message is displayed by the system.
  • In a more general way, it is not possible to use the private keys stored in the Windows certificates store (it is thus not possible to access to secure websites, or to decrypt e-mails.
  • Kon-boot does not allow to bypass the authentication on an Active Directory domain.


Recommendations and conclusion

Bootkits represent a real technical feat and a very interesting study topic regarding the security of a modern operating system boot process. In fact, considering the current design of the PC architecture, there is no “miracle drug” which would allow administrators to protect systems against these pre-boot attacks. In particular, when an operating system is at the early stage of its boot process, it has no technical way to check the integrity of the low-level routines it uses to access the hardware, since it directly depends on these low-level routines. In other words, it necessarily has to rely on the state in which the computer is.

That said, we have to put the risk induced by these pre-boot attacks into perspective. In particular, they all require physical access to the machine that the hacker wants to compromise.

In addition, the following recommendations will greatly help in mitigating the risk related to these pre-boot attacks. They basically consist in locking down the system in order to prevent the use of a bootkit:

  • Set a password at the hard disk level (ATA password): this may be done from the BIOS and will prevent malicious persons from booting the operating system that is installed on this hard disk. Most modern hard disks seem to provide this feature.
  • Disable USB/Firewire booting of the system: it will prevent the use of external disks.
  • Change the boot order to prevent (or disable) booting from CD/DVD ROM drives.
  • Disable network booting of the system (PXE boot).

A more robust solution might be to use a whole disk encryption application, particularly because these kinds of software provide a pre-boot authentication without which the disk contents can not be decrypted.


For more information:

Previous Previous Next Next Print Print