|
Results for rootkit
|
On this page:
|
[very common] A kit for maintaining root; an automated cracking tool. What script kiddies use. After a cracker has first broken in and gained root access, he or she will install modified binaries such as a modified version login with a backdoor, or a version of ps that will not report the cracker's processes). This is a rootkit.
A rootkit is a general description of a set of programs which work to subvert control of an operating system from its legitimate operators. Usually, a rootkit will obscure its installation and attempt to prevent its removal through a subversion of standard system security. Techniques used to accomplish this can include concealing running processes, files or system data from the operating system.[1] Rootkits have their origin in benign applications, but in recent years have been used increasingly by malware to help intruders maintain access to systems while avoiding detection. Rootkits exist for a variety of operating systems, such as Microsoft Windows, Mac OS X[2] [3] , Linux and Solaris. Rootkits often modify parts of the operating system or install themselves as drivers or kernel modules.
The term rootkit (also written as root kit) originally referred to a set of precompiled Unix tools such as ps, netstat, w and passwd that would carefully hide any trace of the intruder that those commands would normally display, thus allowing the intruders to maintain root access (highest privilege) on the system without the system administrator even seeing them.
The first rootkit (that was ever called a rootkit) was written by Lane Davis and Riley Dake for SunOS 4.1.1. The term is no longer restricted to Unix-based operating systems, as tools that perform a similar set of tasks now exist for non-Unix operating systems such as Microsoft Windows, regardless of the existence (or lack of existence) of a root in the operating system.
For a short time in 2005, Sony BMG introduced a CD copy protection program that would automatically install on Microsoft Windows users' computers. The copy protection measures included by Sony BMG on several compact discs. Sony BMG included the Extended Copy Protection (XCP) and MediaMax CD-3 software on music CDs. XCP was put on 52 titles[4] and MediaMax was put on 50 titles.[5] The software interferes with the normal way in which the Microsoft Windows operating system plays CDs, opening security holes that allow viruses to break in, and causing other problems. The rootkit was found to be malicious forcing Sony BMG to recall all CDs that included this software and publicly releasing a patch on their website to repair the damage caused by the program.
A rootkit can take full control of a system. A rootkit's purpose is typically to hide files, network connections, memory addresses, or registry entries from other programs used by system administrators to detect intended or unintended special privilege accesses to the computer resources. However, a rootkit may be incorporated with other files which have other purposes. It is important to note that while the utilities bundled with the rootkit may be malicious in intent, a rootkit is essentially a technology; it may be used for both productive and destructive purposes.
A rootkit is often used to hide utilities. These are often used to abuse a compromised system, and often include so-called "backdoors" to help the attacker subsequently access the system more easily. For example, the rootkit may hide an application that spawns a shell when the attacker connects to a particular network port on the system. Kernel rootkits may include similar functionality. A backdoor may also allow processes started by a non-privileged user to execute functions normally reserved for the superuser. All sorts of other tools useful for abuse can be hidden using rootkits. This includes tools for further attacks against computer systems which the compromised system communicates with, such as sniffers and keyloggers. A possible abuse is to use a compromised computer as a staging ground for further abuse (see zombie computer). This is often done to make the abuse appear to originate from the compromised system or network instead of the attacker. Tools for this can include denial-of-service attack tools, tools to relay chat sessions, and e-mail spam attacks. A major use for rootkits is allowing the programmer of the rootkit to see and access user names and log-in information for sites that require them. The programmer of the rootkit can store unique sets of log-in information from many different computers. This makes the rootkits extremely hazardous, as it allows trojans to access this personal information while the rootkit covers it up.
Rootkits are not always used to attack and gain control of a computer. Some software may use rootkits to hide from 3rd party scanners to prevent detection or tampering. Some emulation software and security software is known to be using rootkits.[6] Alcohol 120% and Daemon Tools are commercial examples of the use of non-hostile rootkits.
Rootkit is a term now loosely applied to cloaking techniques and methods.[7]
There are five different kinds of rootkits: firmware, virtualized, kernel, library and application level kits.
A firmware rootkit uses device or platform firmware to instantiate a persistent image of rootkit malware. The rootkit can hide in firmware because firmware often is not inspected for code integrity. John Heasman demonstrated viability of creating firmware rootkits in both ACPI[8] and in a PCI expansion ROM.[9]
Virtualized rootkits are the lowest level of rootkit currently produced. These rootkits work by modifying the boot sequence of the machine to load themselves instead of the original virtual machine monitor or operating system. Once loaded into memory a virtualized rootkit then loads the original operating system as a Virtual Machine thereby enabling the rootkit to intercept all hardware calls made by the guest OS. The SubVirt laboratory rootkit developed jointly by Microsoft and University of Michigan researchers is an example of a Virtual Machine based rootkit or VMBR.
Kernel level rootkits add additional code and/or replace a portion of kernel code with modified code to help hide a backdoor on a computer system. This is often accomplished by adding new code to the kernel via a device driver or loadable module, such as Loadable Kernel Modules in Linux or device drivers in Microsoft Windows. These rootkits often have serious impacts on entire system stability if mistakes are found to be present in the kit's code.
Kernel rootkits can be especially dangerous because they can be difficult to detect without appropriate software.
Library rootkits commonly patch, hook, or replace system calls with versions that hide information about the attacker.
Application level rootkits may replace regular application binaries with trojanized fakes, or they may modify the behavior of existing applications using hooks, patches, injected code, or other means.
Rootkit binaries are usually detected by most[citation needed] signature or heuristics based antivirus programs, at least until they're run by a user. There are inherent limitations to 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 tools and libraries upon which all programs on the system depend. Some rootkits modify the running kernel via loadable modules on Linux and many other forms of UNIX, and possibly through VxDs, virtual external drivers, on MS Windows platforms. The fundamental problem with rootkit detection is that the operating system currently running cannot be trusted. 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 that run on live systems currently only work because the rootkits detectable have not yet been developed to hide themselves fully.
The best[citation needed] and most reliable[citation needed] method for rootkit detection is to shut down the computer suspected of infection and check its storage by booting from an alternative medium (e.g. rescue CD-ROM or USB flash drive). A non-running rootkit cannot hide its presence, and most established antivirus programs will identify rootkits armed via standard OS calls (which are supposedly doctored by the rootkit) and lower level queries, which ought to remain reliable. If there is a difference, the presence of a rootkit infection can be assumed. Rootkits attempt to protect themselves by monitoring running processes and suspending their activity until the scanning has finished.
Security vendors envision[citation needed] a solution by integrating rootkit detection into traditional antivirus products. Should a rootkit decide to hide during the scan process, it will be identified by the stealth detector. If it decides to temporarily unload from the system, the traditional antivirus will find it using fingerprint detection. This combined defense 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 the creators of the tools on both sides of this conflict.
There are several programs available to detect rootkits. On Unix-based systems, two of the most popular are chkrootkit and rkhunter. For the Windows platform there are many free detection tools such as F-Secure Blacklight. Another Windows detector is RootkitRevealer from Sysinternals which will detect all current rootkits by comparing the results from the OS to the actual listing read from the disk itself (cross-checking). However, some rootkits started to add RootkitRevealer to a list of files it does not hide from--so in essence, they remove the differences between the two listings, and the detector doesn't report them (most notably commercial rootkit Hacker Defender Antidetection). Another method is to compare content of binaries present on disk with their copies in operating memory - some differences can be introduced by legal operating system mechanisms (e.g. relocations), but some can be very likely classified as system call hooks introduced by a running rootkit (System Virginity Verifier).
As always[citation needed], prevention is better than cure. If the integrity of the system install disks is trusted, cryptography may be used to monitor the integrity of the system. By "fingerprinting" the system files immediately after a fresh system install and then again after any subsequent changes made to the system (e.g. installing new software), the user or administrator will be alerted to any dangerous changes to the system's files. In the fingerprinting process a cryptographic hash function is used to create a fixed-length number that is dependent on every bit of data contained in the file being fingerprinted. By calculating and comparing hash values of files (the essence of the fingerprint) at regular intervals, changes not made by any intended user of the system can be detected.
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 (by a rootkit) root-of-trust ensures that the rootkit does not compromise the system at its most fundamental layer. Rootkit detection using a TPM is further described in Stopping Rootkits at the Network Edge, January 2007.
There is a body of opinion that holds this to be forbiddingly impractical. Even if the nature and composition of a rootkit is known, the time and effort of a system administrator with the necessary skills or experience would be better spent re-installing the operating system from scratch. Since drive imaging software makes the task of restoring a “clean” OS installation almost trivial, there is no good reason to try to dig a rootkit out directly. "I suppose traditional rootkits could be made to be as hard to remove as possible even when found, but I doubt this is much incentive for that, because the typical reaction of an experienced sysadmin on finding a rooted system is to save the data files, then reformat. This is so even if the rootkit is very well known and can be removed 100%." Rootkit Question
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 (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 one runs the rootkit's ps command it may check the copies of init and inetd on the system to ensure that they are still compromised, and "re-infecting" them as necessary. The rest of the payload is there to ensure that the intruder can continue to control the system. This generally involves having backdoors in the form of hard-coded username/password pairs, hidden command-line switches or magic environment variable settings which subvert the 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 the 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 usernames 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).
Of course there are 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 can be easily conflated.
Like most software used by attackers, lots of implementations are shared and are easily available on the Internet. It is not uncommon to see a compromised system where a sophisticated publicly available rootkit hides the presence of unsophisticated worms or attack tools that appear to be 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. Since these are often not fully optimized for stealth, they sometimes leave evidence of their presence on a system. Even so, when such rootkits are used in an attack they are often very effective.
This entry is from Wikipedia, the leading user-contributed encyclopedia. It may not have been reviewed by professional editors (see full disclaimer)
Join the WikiAnswers Q&A community. Post a question or answer questions about "rootkit" at WikiAnswers.
Copyrights:
 |
 | Hacker Slang. The Jargon File. Copyright © 2007. Read more |
 |
| Wikipedia. This article is licensed under the GNU Free Documentation License. It uses material from the Wikipedia article "Rootkit". Read more |
Search for answers directly from your browser with the FREE Answers.com Toolbar!
Click here to download now. 
Get Answers your way! Check out all our free tools and products.
Mentioned In:
