Arguably, one of the most complex and lethal types of malicious code today is the "rootkit." As its name implies, this type of malware can gain "root" access, the highest privilege level in Unix systems, as well as deploy its "kit" of small, often malicious, executable packages. The code can provide continual and undetectable access into a machine.
Today's rootkits draw their power from having access to the kernel of the operating system. These "kernel-mode" rootkits run at the same lower level as all other trusted system processes, thus granting system control and providing effective ways to remain hidden.
The rootkit's powerful way of maintaining system access while remaining undetected has posed a challenge to the security community. To prevent kernel-mode malware and digital rights management (DRM) violations, Microsoft has enforced a policy with its Vista OS, requiring digital signatures for all device drivers. The security mechanism, however, has been criticized because it prevents legitimate 3rd parties from developing device drivers. Although the policy is also thought to be partially responsible for Vista's incompatibility with several peripheral devices, Vista's driver-signing policy has challenged others to create a variant of rootkits, reminiscent of boot sector viruses.
The 'bootkit'
Before the days of mass interconnectivity, malicious code traveled on portable storage media, like a CD-ROM or floppy disk. The malware, usually a virus hidden in the boot sector of a disk, acted as a digital parasite, infecting the host PC when introduced at the boot process. The infection would corrupt the machine by altering a hard drive's Master Boot Record, the boot sector code of any boot disk, or the disk partition table (DPT). While rarely seen today, the boot sector virus comes to mind when discussing the new rootkit technology that may defeat Vista's device driver signature requirement.
A "bootkit" leverages its kernel access and stealth by manipulating the boot process. Functionally, bootkits are no different than rootkits. They differ, though, in how they gain access. Traditional rootkits use elevated privileges while the OS is running. Bootkits, however, are installed from the boot sector of an external device and remain in memory throughout the system's boot process. This concept was first introduced in 2005, when security researchers from eEye Digital Security developed a method of exploiting the BIOS during startup. Their "BootRoot" project introduced custom boot sector code, allowing subversion and persistent real mode access to the Windows NT kernel.
In April of this year, at BlackHat Europe, researchers at India's NV labs introduced the "VBootkit", which also allows kernel subversion via custom boot code. Despite some of the controversial similarities between the two, the newer VBootkit contained some modified instruction code to work with Microsoft Vista's updated startup process, one whose boot loader architecture has changed. Regardless of which boot platform is used, however, there are several bootkit techniques that exploit this startup process.
The bootkit's custom boot sector code hijacks the startup routine after the ROM BIOS code executes, but before the true Master Boot Record (MBR) loads. Once loaded into the memory, the code executes a software interrupt instruction, also known as "hooking." It hooks to INT 13, an instruction which allows subsequent sector reading. Once accomplished, the bootkit utilizes a number of patching sequences throughout the boot process to change its structure and manipulate logical flow.
Several methods of code modification are employed at various stages to bypass digital signatures and checksums. In order for the bootkit code to remain undetected, a number of detours are used for its own relocation in memory. Rootkits can also recalculate and replace checksums, bit values that can be used to verify a file's integrity.
Once resident and undetectable in kernel space, a rootkit can execute additional payloads. At the very least, a covert channel is established, providing the malicious hacker with unrestricted access to the victim's machine. A rootkit's additional executable payloads may include ways to harvest usernames and passwords, disable certain applications (often security suites), use the machine as proxy for attacks or further spread its own rootkit.
These machine code methods used to manipulate instructions in kernel space demonstrate the severity of this malware subclass. While software exists for rootkit detection and removal, the bootkit stresses the importance of prevention. Its means of boot process injection emphasizes the need for implementing physical access policies to an overall security strategy.
Protection from bookit technology means protecting the machine's boot process. The system's BIOS can be configured to disable any boot devices other than the hard disk. Furthermore, to prevent any unauthorized changes, the system BIOS can be password-protected. Physically locking the computer case will restrict access to the motherboard containing the BIOS chip and its CMOS battery, both of which could be used to clear the BIOS password. For systems located in public areas, consider removal of external media components, such as floppy and CD/DVD drives. It may help to disable USB/FireWire ports and even configure specific machines to only operate in kiosk mode.
Regardless of their means of entry to a computer's kernel space, rootkits are a very powerful and real threat. While they account for a small fraction of 'in the wild' malware, most security software is a step behind and cannot detect their presence. Perimeter protection, enforcement of restricted user privilege levels, combined with a tight control of running services will provide a strong network defense against rootkit penetration. It is important for those responsible for IT security to follow the trends of rootkit technology in addition to the evolution of developers' defensive techniques.
About the author:
Noah Schiffman is a reformed former black-hat hacker who has spent nearly a quarter century penetrating the defenses of Fortune 500 companies. Today he works as an independent IT security consultant specializing in risk assessment, pen testing, cryptography and digital forensics, predictive analysis models, security metrics and corporate security policy. He holds degrees in psychology and mechanical engineering, as well as a doctorate in medicine from the Medical University of South Carolina. Schiffman is based in Charleston, S.C.
