Rootkit: Difference between revisions

This article may require copy editing for grammar, style, cohesion, tone, or spelling. You can assist by editing it. (May 2009) (Learn how and when to remove this message)

A rootkit is a type of software that is designed to gain administrator-level control over a computer system without being detected. In virtually all cases, the purpose and motive is to perform malicious operations on a target host computing system at a later date without the knowledge of the administrators or users of that system. Rootkits can be installed in hardware or software targeting the BIOS, hypervisor, boot loader, kernel or less commonly, libraries or applications.

The term rootkit is a portmanteau derived from the administrative (superuser or "root") account in historical operating system terminology (primarily Unix) and the word "kit", which refers to the software components that implement the tool.

Most rootkits are malware to help attackers gain access to systems over an extended period of time whilst evading detection, however there is also a subset that are classed as utility applications. An example of the latter is a rootkit that provides CD-ROM emulation capability so that games with anti-piracy features that require the original installation media to be inserted, can be fooled into believing that the physical media is present. Rootkit behavior varies(more detail), and not all perform equivalent or similar actions—a rootkit can be designed and developed by researchers to test the resistance of their systems to assorted potential attacks. However, malicious variations have the capacity to siphon and transmit sensitive data, for example: PINs, account passwords, credit card particulars, etc. Rootkits have been discovered that can operate successfully upon a variety of operating systems, the primary list being: Microsoft Windows, Linux, Mac OS, and Solaris.

Rootkits typically leverage security exploits to gain initial unauthorised privileged access to a system. However a rootkit can also leverage a Trojan in order to deceive a computer user into trusting the rootkit's installer as being something benign—in this case, social engineering is used to convince a user to install something useful that they expect to be safe to install and run on their computer system(s). The installation task is made easier if the principle of least privilege is not being implemented, as the rootkit does not have to explicitly request elevated (administrator-level) privileges. Other classes of rootkits can be installed only by someone with physical access to the target platform.

Once installed, a rootkit will usually take active measures to obscure its presence within the host system through subversion or evasion of standard operating system security tools and API's used for diagnosis, scanning and monitoring. Rootkits achieve this by modifying the behaviour of core parts of an operating system through the installation or modification of drivers or kernel modules. Obfuscation techiques range from concealing running processes from system monitoring mechanisms to hiding system files and other configuration data.^[1] Some rootkit programs, to that end, are defective in that they might crash the system, slow it down or introduce erratic behaviour and thereby ultimately get discovered.

A rootkit may also install a "back door" within host systems by, for example, replacing the login mechanism (such as the /bin/login program on Unix-like systems) with a similarly-acting, but malicious sub-system that accepts a secret login combination that allows an attacker access to a host system (typically as the root user) by bypassing standard authentication and authorization mechanisms. It is not uncommon for a rootkit to act to erase the system event logging capacity (under Event Viewer) of an operating system (esp. Microsoft Windows-based computing systems), in an attempt to hide evidence of any perpetrated attack vector, successful or not.

The term rootkit or root kit originally referred to a maliciously modified set of administrative tools for a Unix-like operating system, which granted "root" access. If an intruder could replace the standard administrative tools on a system with a rootkit, the modified tools would allow the intruder to maintain root access over the system while concealing these activities from the legitimate system administrator. The earliest known rootkit may have been that written in 1990 by Lane Davis and Steven Dake for SunOS 4.1.1.^{[citation needed]} There was an earlier exploit equivalent to a rootkit that was perpetrated by Ken Thompson of Bell Labs against a naval laboratory in California to settle a wager.^{[citation needed]} It is believed^{[by whom?]} that Thompson subverted the C compiler in a distribution of Unix used at the naval laboratory.

Historically, there was a culture among computer science undergraduates during the 1960s and 1970s, most notably at MIT and Stanford University. Many of this pioneer generation of computing scientists experimented with the "hacking" of computer systems (in the original sense of that word, see The Jargon File for some details); some of their activities and experimentation resulted in the equivalent of rootkits – although these early excursions were mostly hands-on, and not via autonomous, widely disseminated LAN or MAN-based applications for use by many.

By definition, a rootkit cannot elevate an attacker's privileges before it runs on the target system. The first and primary obstacle for an attacker is to install the penetration mechanism for the rootkit in question. Installation of the remaining payload thereafter requires the intruder to have root or administrator access to a system, which is typically achieved by having physical access or exploiting a security vulnerability that allows privilege escalation upon a host system. Alternatively, the installation segment of the rootkit may simply be started unwittingly by any user with administrative-rights access: for example, via a Trojan application. Once installed, the rootkit maintains surreptitious (or stealth) administrator-level access by subverting the system in some way, and actively hides its presence from other processes.

In 2005, Sony BMG caused a scandal by including a rootkit program – created by First 4 Internet – on many of its music CDs that, in an attempt to enforce DRM,^[2] installed software on any Microsoft Windows computer which played any new (at the time) Sony CD. Effectively, the rootkit opened a backdoor, thus allowing root access to anyone who either: (1) had foreknowledge of or, (2) was simply aware of the rootkit's installation and presence.^[3] The scandal raised the public's awareness of rootkits, while the public relations fallout for Sony was compared by one analyst to the Tylenol Scare.^[4] In light of adverse publicity, Sony BMG recanted and released patches to repair the breaches, but initial attempts to do so failed to remove the rootkit's backdoor. Subsequently, Sony BMG lost a class-action lawsuit brought about due to their aforementioned infractions.

A successfully installed rootkit allows unauthorized users to access the system as root, regardless of the authorized_users_only mechanisms in the operating system, and thus to have full control of the "rootkitted" or "rooted" system on demand. Most rootkits typically hide files, processes, network connections, blocks of memory, or Windows Registry entries from other programs used by system administrators to detect specially privileged accesses to computer system resources. However, a rootkit may masquerade as, or be intertwined with, other files, programs, or libraries with other purposes. While the utilities bundled with a rootkit may be maliciously intended, not every rootkit is malicious. Rootkits may be used for both productive and destructive purposes.

Many rootkits hide utility programs. Those that do so usually aim to abuse a compromised system, and often include a so-called "back door" to give the attacker subsequent access at will. A simple example might be a rootkit that hides an application that spawns a command processing shell when the attacker connects to a particular network port on the system. Kernel rootkits may include similar functionality. A back door may also allow processes started by a non-privileged user to run as though they were started by a privileged user (including the root user) and to carry out functions normally reserved for the superuser. Rootkits are hard to detect with common antivirus programs and therefore a specialized scan of the system will be necessary, though such scanning software may not be able to find and remove the backdoor access a rootkit has installed. Some rootkits, in that sense, are quite ingeniously designed.

Many other utility tools used for abuse can be hidden using rootkits. These include tools for further attacks against computer systems with which the compromised system communicates, such as sniffers and keyloggers. A possible form of abuse is using a compromised computer as a staging ground for further attacks (see zombie computer). This is often done to make the abuse appear to originate from the compromised system (or network) instead of the attacker's. Tools for such attacks can include denial-of-service attack tools, tools for relaying chat sessions, and e-mail spam distribution. Rootkits are normally used in conjunction with other malicious programs as a means to conceal them from users, administrators, and anti-malware software.

It has become increasingly popular for virus writers to make use of rootkit techniques. The reason is that they make it possible to hide malware from PC users and antivirus programs. Numerous source code samples for ready-made rootkits can be found on the Internet, which inevitably leads to their widespread use in various Trojans or spyware programs, etc.

However, rootkits are not always used to maintain control of a computer. Some software may use rootkit techniques to hide from third-party scanners to detect tampering or attempted break-ins, for example in a honeypot. Some emulation software and security software is known to use rootkits.^[5] Alcohol 120% and Daemon Tools are commercial examples of the use of non-hostile rootkits. Kaspersky antivirus software also uses some techniques somewhat resembling rootkits to protect itself from malicious virus actions. It loads its own drivers to intercept system activity and then prevents other processes from doing harm to itself. So while its processes are not hidden, such processes cannot be terminated by standard methods.

Rootkit is a term now somewhat loosely applied to cloaking techniques and methods.^[6]

There are at least six kinds of rootkits: firmware, hypervisor, boot loader, kernel, library, and application level kits.

A firmware rootkit uses device or platform firmware to create a persistent malware image. The rootkit can successfully hide in firmware, because firmware is not often inspected for code integrity. John Heasman demonstrated the viability of firmware rootkits in both ACPI firmware routines^[7] and in a PCI expansion card ROM.^[8]

In October 2008, the press reported that criminals had tampered with European credit card reading machines while they were still in the supply chain, and that these devices were intercepting customers' credit card details before transmitting the data to international criminals via the mobile phone network.^[9] In March 2009, researchers Alfredo Ortega and Anibal Sacco^[10] published details of a BIOS-level rootkit for PC's that is able to survive harddisk replacement and re-installation of the operating system.^[11]

A fully detailed article was later published by the researchers in the Phrack Magazine #66.

A few months after this research they presented at the Black Hat Vegas Security Conference some new research discussing a related attack. They found that most laptop BIOSes comes with a "legal" rootkit preinstalled known as Computrace LoJack. This is an anti theft technology system that, as the researchers showed^[12] can be abused by an attacker for malicious purposes.^[13]

These rootkits work by modifying the boot sequence of the machine to load themselves as a hypervisor under the original operating system. By exploiting hardware features such as Intel VT or AMD-V, the rootkit is able to load the original operating system as a virtual machine, thereby enabling it to intercept all hardware calls made by the original operating system, which is now a guest. The "SubVirt" laboratory rootkit, developed jointly by Microsoft and University of Michigan researchers, is an academic example of a virtual machine based rootkit (VMBR),^[14] while Blue Pill is another.

In 2009, researchers from Microsoft and the North Carolina State University demonstrated a hypervisor-layer anti-rootkit called Hooksafe that is able to provide generic protection against kernel-mode rootkits (see next section).^[15]

A variant on the theme, called a bootkit is used predominantly for attacks (Evil Maid Attack^[16]) against full disk encryption systems. A bootkit replaces the legitimate boot loader with one controlled by an attacker; typically the malware loader is able to persist through the transition to protected mode when the kernel has loaded. For example, the "Stoned Bootkit"^[17] uses a compromised boot loader to subvert the system, which can subsequently be used to extract information and keys when the victim uses the computer. Apart from preventing unauthorized physical access to machines (a particular problem for portable machines), a Trusted Platform Module, configured to protect the boot path, is the only known defense against this attack.

Kernel-level rootkits add additional code or replace portions of an operating system, including both the kernel and associated device drivers. Most operating systems support kernel-mode device drivers which execute with the same privileges as the operating system itself.^[18] As such, many kernel mode rootkits are developed as device drivers or loadable modules, such as loadable kernel modules in Linux or device drivers in Microsoft Windows. This class of rootkit is perceived as dangerous simply because of the unrestricted security access the code has obtained, regardless of the features the rootkit may employ. Any code operating at the kernel level may have serious impacts on entire system stability if bugs are present in the code. The first and original rootkits did not operate at the kernel level, but were simple replacements of standard programs at the user level. One of the first widely known kernel rootkit was developed for Windows NT 4.0 and released in Phrack issue 55 in the mid-1990s by Greg Hoglund.^[19]

Kernel rootkits can be especially difficult to detect and remove, because they operate at the same security level as the operating system itself, and are thus able to intercept or subvert any operation made by the operating system. Any software, such as antivirus software, running on the compromised system is equally easily subverted. In a situation such as this, no part of the system can be trusted. One response in such a case is to perform system offline analysis by booting a second known good or 'trusted' system from removable media such as a live CD. Investigation and rootkit removal actions can then be performed safely from a trusted operating system without requiring another physical computer system, as the hard drive of the infected system can be mounted as a secondary resource without executing anything on the untrusted volume. Alternatively, the volume can simply be formatted and the operating system re-installed from trusted media.

Library rootkits commonly patch, hook, or replace system calls with versions that hide information about the attacker. They can be found, at least theoretically, by examining code libraries (in the Windows world, the term used is DLL) for changes or against the originally distributed (and so, presumably, malware free) library package; this approach may not succeed if the code is subverted only in memory, or if the rootkit presents only the unmodified version to utilities performing scans. Digital signatures help to detect unauthorized changes to code libraries.^[20] However, the most common of these schemes checks only whether the code has been modified since release by the "publisher"; subversion prior to that time is not detectable.

Application level rootkits may replace regular application binaries with Trojan fakes, or they may modify the behavior of existing applications using hooks, patches, injected code, or other means.

There are unscrupulous companies whose business consists of disseminating rootkits for the purpose of generating paid involuntary page referrals. Such programs would redirect a visit to a popular website like Google to that of a client of the distributor of the rootkit.

Rootkit binaries can often be detected by signature or heuristics-based antivirus programs, at least until they're run by a user and are able to attempt to conceal themselves. There are inherent limitations for any program that attempts to detect rootkits while the program is running under the suspect system. Rootkits are suites of programs that modify many of the core system tools and libraries upon which all programs on the system depend. Some rootkits attempt to modify the running operating system via loadable modules on Linux (and some other UNIX varieties), and through VxDs, virtual external device drivers on MS Windows platforms. The fundamental problem with rootkit detection is that if the operating system currently running has been subverted, it cannot be trusted, including to find unauthorized modifications to itself or its components. In other words, actions such as requesting a list of all running processes, or a list of all files in a directory, cannot be trusted to behave as intended by the original designers. Rootkit detectors running on live systems currently work because the rootkits they can detect have not yet been developed to hide themselves fully against these detectors. A reasonable analogy might be: if one asked a brainwashed person if they had been brainwashed, the logical answer being that any answer they give cannot be trusted.

The best, and most reliable, method for operating system-level rootkit detection is to shut down the computer suspected of infection, and then to check its storage by booting from an alternative trusted medium (e.g. a rescue CD-ROM or USB flash drive)^{[citation needed]}. A non-running rootkit cannot actively hide its presence, and most established antivirus programs will identify rootkits armed via standard OS calls (which are often tampered with by the rootkit) and lower level queries, which ought to remain reliable. If there is a difference, the presence of a rootkit infection should be assumed. Running rootkits attempt to protect themselves by monitoring running processes and suspending their activity until the scanning has finished; this is more difficult if the rootkit is not allowed to run. ^{[citation needed]}

Security software vendors have attempted a solution by incorporating rootkit detection into their existing antivirus products. Should a rootkit attempt to hide during an antivirus scan, it will be identified by the stealth detector; if it attempts to temporarily unload itself from the system it will be detected by fingerprint (or signature) detection. Since anti-virus products are almost never entirely capable of catching all viruses in public tests, this approach may be doubted on past behavior. But this combined approach may force attackers to implement counter-attack mechanisms (so called retro routines) in their rootkit code that will forcibly remove security software processes from memory, effectively killing the antivirus program. As with computer viruses, the detection and elimination of rootkits will be an ongoing struggle between tool creators on both sides of this conflict.

There are several programs available to detect rootkits. On Unix-based systems, three of the most popular are chkrootkit, rkhunter and OSSEC. For Windows, there are many free detection tools such as Microsoft Sysinternals Rootkit Revealer, avast! antivirus, Sophos Anti-Rootkit, F-Secure Blacklight, and Radix. Another method that can be used to detect rootkits is to compare the content of binaries present on disk with their copies within operating memory — however some valid differences can be introduced by operating system mechanisms, e.g., memory relocation or shimming, but some can be very likely classified as system call hooks introduced by a running rootkit (System Virginity Verifier). Zeppoo is another software product which detects rootkits under Linux and UNIX systems.

As always, prevention is often better than trying to seek a cure. Making certain a rootkit has been removed typically involves re-installation of all software. If the integrity of the system install disks is trusted, cryptography can be used to monitor the integrity of the system. By fingerprinting the system files immediately after a fresh system install and again after any subsequent changes are made to the system. An operable example being: after installing new software, the user or administrator will be alerted to any potentially malign and dangerous changes to integral and vital operating-system files. In the fingerprinting process a message digest is used to create a fixed-length digest dependent on every bit in the file being fingerprinted. By calculating and comparing message digest values of files at regular intervals, changes in the system can be arbitrarily detected and monitored.

Detection in firmware can be achieved by computing a cryptographic hash of firmware and comparing hash values to a whitelist of expected values, or by extending the hash value into TPM (Trusted Platform Module) configuration registers, which are later compared to a whitelist of expected values. Code that performs hash, compare, and/or extend operations must itself not be compromised by the rootkit. The notion of an immutable root-of-trust (i.e. by a rootkit), if implementable, ensures that the rootkit does not compromise the system at its most fundamental level. A method of rootkit detection using a TPM is described by the Trusted Computing Group.^[21]

Direct removal of a rootkit may be impractical. Even if the type and nature of the rootkit are known, the required time and effort by a system administrator with the necessary skills or experience may exceed the required time to re-install the operating system. Re-installation time can be greatly reduced by modern drive imaging software, and the source image may have been generated with necessary hardware drivers and software applications already installed, further reducing the incentive to repair the existing installation.

Traditional rootkits could be written to be extremely difficult to remove even when found; however, incentive to do so is minimal, because the typical reaction of an experienced sysadmin on finding a rooted system is to save the data files, then reformat the hard drive and reinstall the operating system. This is true even if the rootkit is well-known and can be completely removed.^[22] While most Anti-Virus and Malware Removal tools remain ineffective against rootkits, tools such as BartPE and other Preinstallation Environment(PE) or Live Distros can allow a user to boot an affected computer with a "clean" copy of an operating system suitable for reading and writing the disk contents. The user may then examine and replace affected system files and delete unauthorized files and configuration entries while keeping the underlying system intact. Since most rootkits hook system files needed at the lowest level of the OS, booting into Safe Mode will not usually allow removal of the rootkit process. A PE boots and loads a clean OS copy from separate media and does not rely on the infected underlying system structure, giving the user full control over the system disks. The PE approach may be employed when the system contains irreplaceable data that might be lost during a reinstallation or disk imaging process.

Symantec Veritas VxMS (Veritas Mapping Service), on the other hand, lets the antivirus scanner bypass Windows File System APIs, which are controlled by the operating system and therefore vulnerable to manipulation by a rootkit. VxMS directly accesses raw Windows NT File System files. In effect, VxMS can map data, compare it to the Windows file structure, and isolate any discovered mismatches. VxMS technology has been extended to Symantec's Norton product line from the 2007 product year.^{[23][24][25][26][27]}

The key distinction between a computer virus and a rootkit relates to propagation. Like a rootkit, a computer virus modifies core software components of the system, inserting code which attempts to hide the "infection" and provides some additional feature or service to the attacker (i.e., the "payload" of a virus).

In the case of the rootkit the payload may attempt to maintain the integrity of the rootkit (the compromise to the system). For example, every time the rootkit's version of the ps command is run, it may check the copies of init and inetd on the system to ensure that they are still compromised, "re-infecting" as necessary. The rest of the payload is there to ensure that the intruder continues to control the system. This generally involves having back doors in the form of hard-coded user name/password pairs, hidden command-line switches or "magic" environment variable settings that subvert normal access control policies of the uncompromised versions of the programs. Some rootkits may add port knocking checks to existing network daemons (services), such as inetd or sshd.

A computer virus can have any sort of payload. However, the computer virus also attempts to spread to other systems. In general, a rootkit limits itself to maintaining control of one system.

A program or suite of programs that attempts to automatically scan a network for vulnerable systems and to automatically exploit those vulnerabilities and compromise those systems is referred to as a computer worm. Other forms of computer worms work more passively, sniffing for user names and passwords and using those to compromise accounts, installing copies of themselves into each such account (and usually relaying the compromised account information back to the intruder through some sort of covert channel).

There are also hybrids. A worm can install a rootkit, and a rootkit might include copies of one or more worms, packet sniffers or port scanners. Also many of the e-mail worms are commonly referred to as "viruses," so all of these terms have somewhat overlapping usage and are often conflated.

Like much malware used by attackers, many rootkit implementations are shared and are easily available on the Internet. It is not uncommon to see a compromised system in which a sophisticated publicly available rootkit hides the presence of unsophisticated worms or attack tools that appear to have been written by inexperienced programmers.

Most of the rootkits available on the Internet are constructed as an exploit or "proof of concept" to demonstrate varying methods of hiding things within a computer system and of taking unauthorized control. Since these are often not fully optimized for stealth, they sometimes leave unintended evidence of their presence. Even so, when such rootkits are used in an attack they are often very effective.

• Hacker con
• Computer virus
• Host-based intrusion detection system
• The SANS Institute
• 2005 Sony BMG CD copy protection scandal
• The Rootkit Arsenal: Escape and Evasion in the Dark Corners of the System

• Robert S Morris, Sr. (1984). "UNIX Operating System Security". Bell Systems Technical Journal. 62 (8). BSTJ.
• Greg Hoglund and James Butler (2005). Rootkits: Subverting the Windows Kernel. Addison Wesley. ISBN 0-321-29431-9.
• Nancy Altholz and Larry Stevenson (2006). Rootkits for Dummies. John Wiley and Sons Ltd. ISBN 0-471-91710-9.
• Ric Veiler (2007). Professional Rootkits. Wrox. ISBN 978-0-470-10154-4.
• Reverend Bill Blunden (2009). The Rootkit Arsenal: Escape and Evasion in the Dark Corners of the System. Wordware. ISBN 978-1598220612.

• Phrack Magazine #66
• Deactivate The Rootkit - Exploiting Stuff
• Implementing rootkit in Oracle RDBMS
• Rootkit Analysis: Research and Analysis of Rootkits
• Even Nastier: Traditional RootKits
• Sophos Podcast about rootkit removal
• Featured Article: Rootkit Unhooker v3.8 Its Past, Present and Future of the NTx86 Rootkit Detection by DiabloNova
• Rootkit research in Microsoft
• White paper on new-generation rootkit detection
• antirootkit.com
• Testing of antivirus/anti-rootkit software for the detection and removal of rootkits made by Anti-Malware Test Lab, January 2008
• Testing of anti-rootkit software made by InformationWeek, January 2007
• Sony, Rootkits and Digital Rights Management Gone Too Far (Mark Russinovich's first blog entry about the Sony DRM rootkit, from which the scandal ensued)
• Designing BSD Rootkits An Introduction to Kernel Hacking (book by Joseph Kong)
• How to remove spyware from your PC: rid yourself of rootkits
• Glossary of malware terminology ("Rootkit" has a negative connotation)
• White paper on hypervisor rootkit technology
• Review: Six Rootkit Detectors Protect Your System
• Article about writing simple rootkits for Linux
• Article about writing from scratch a library level rootkit for Windows