Don's Pages and my Music

▼

Tuesday, July 13, 2010

Special:Search

Rootkit

From Wikipedia, the free encyclopedia

Jump to: navigation, search
Acap.svg
 This article may require copy editing for grammar, style, cohesion, tone or spelling. You can assist by editing it. (May 2010)

A rootkit is a software or hardware device designed to gain administrator-level control over a computer system without being detected. Although rootkits can serve a variety of ends, they gained notoriety as malware, appropriating computing resources without the knowledge of the administrators or users of affected systems. Rootkits can target the BIOS, hypervisor, boot loader, kernel or less commonly, libraries or applications.

The term rootkit is a concatenation of the administrative account in (primarily) Unix operating systems (root user account) and the word "kit", which refers to the software components that implement the tool.

Contents

[hide]

Overview

The most common forms of rootkit either damage the systems they occupy or redirect the systems' resources for purposes ranging from pranks to gratifying their authors' egos to crime. Some are simply utility applications. An example of the latter is a rootkit that provides CD-ROM emulation capability allowing video game users to defeat anti-piracy features that require the original installation media. Rootkits can test resistance to assorted potential attacks. However, malicious rootkits siphon and transmit private/sensitive data, for example: PINs, account passwords, credit card particulars, etc. Some rootkits can operate successfully upon multiple operating systems.[citation needed]

Rootkits employ a variety of techniques to gain control of a system. The most common is to leverage security gaps. Another approach is to become a Trojan horse, deceiving a computer user into trusting the rootkit's installer as benign—in this case, social engineering convinces a user that the rootkit is beneficial. The installation task is made easier if the principle of least privilege is not applied, since the rootkit then 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 system.

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.) The replacement acts similarly, but accepts another login combination that allows an attacker direct access with administrative privileges to a system bypassing standard authentication and authorization mechanisms.

Once installed, a rootkit usually takes 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 behavior of core parts of an operating system through the installation or modification of drivers or kernel modules. Obfuscation techniques include concealing running processes from system monitoring mechanisms and hiding system files and other configuration data.[1] It is not uncommon for a rootkit to erase the event logging capacity of an operating system in an attempt to hide evidence of an attack. Rootkits that crash the system, slow it down or introduce erratic behavior are defective in that these changes are visible enough to get the attention of the system's users and lead to discovery. The "perfect rootkit" can be thought of as similar to a "perfect crime", one that nobody realizes has taken place.

History

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 intruder could obtain root access over the system while concealing these activities from the legitimate system administrator. Lane Davis and Steven Dake wrote the earliest known rootkit in 1990 for SunOS 4.1.1.[citation needed] An earlier exploit equivalent to a rootkit was perpetrated by Ken Thompson of Bell Labs against a naval laboratory in California to settle a wager.[citation needed] Thompson subverted the C compiler in a Unix distribution and discussed the exploit in the lecture he gave upon receiving the Turing award in 1983.[2]

In 2005, Sony BMG caused a scandal by including a rootkit program – created by First 4 Internet – on many of its music CDs in an attempt to enforce DRM,[3] installed software on any Microsoft Windows computer which played any new (at the time) Sony CD. The rootkit opened a backdoor, allowing root access to anyone who was aware of its presence.[4] The scandal raised the public's awareness, while the public relations fallout for Sony was compared by one analyst to the Tylenol Scare.[5] In light of adverse publicity, Sony BMG released patches to repair the breaches, but initial attempts failed to remove the backdoor. Subsequently, the company lost a related class-action lawsuit.[6]

Uses

Question book-new.svg
 This section needs additional citations for verification.
Please help improve this article by adding reliable references. Unsourced material may be challenged and removed. (June 2010)

Rootkits have many uses:

  • Provide the attacker with full access via a backdoor so the attacker can for example, steal or falsify documents.
  • Appropriate the compromised computer as a staging ground for attacks on other computers. The attack appears to originate from the compromised system (or network) instead of the attacker's. "Zombie" computers can launch denial-of-service attacks and distribute e-mail spam.
  • Aid virus writers. Numerous source code samples for ready-made rootkits are available on the Internet.
  • Detect attacks, for example in a honeypot.
  • Enhance emulation software and security software.[7] Alcohol 120% and Daemon Tools are commercial examples of non-hostile rootkits. Kaspersky antivirus software also uses techniques resembling rootkits to protect itself from malicious actions. It loads its own drivers to intercept system activity and then prevents other processes from doing harm to itself. Its processes are not hidden, but cannot be terminated by standard methods.
  • Conceal other software.[8]
  • Circulate content (documents, videos, etc.) as an annoyance.
  • Warehouse content for use in file-sharing networks.

Types

There are at least six rootkit types: firmware, hypervisor, boot loader, kernel, library, and application level kits.

Hardware/Firmware

A firmware rootkit uses device or platform firmware to create a persistent malware image. The rootkit hides in firmware, which is not often inspected for code integrity. John Heasman demonstrated the viability of firmware rootkits in both ACPI firmware routines[9] and in a PCI expansion card ROM.[10]

In October 2008, criminals tampered with European credit card reading machines before they were installed. The devices intercepted and transmitted credit card details via a mobile phone network.[11] In March 2009, researchers Alfredo Ortega and Anibal Sacco[12] published details of a BIOS-level WIndows rootkit that was able to survive disk replacement and OS re-installation.[13] Full details are available.[14]

A few months later they found that most laptop BIOSes come with a "legal" preinstalled rootkit known as Computrace LoJack. This is an anti–theft technology system that, as the researchers showed[15] can be turned to malicious purposes.[16]

Hypervisor level

Hypervisor 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 loads the original operating system as a virtual machine, thereby enabling the rootkit to intercept all hardware calls made by the original operating system, which becomes 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),[17] while Blue Pill is another.

In 2009, researchers from Microsoft and North Carolina State University demonstrated a hypervisor-layer anti-rootkit called Hooksafe that provides generic protection against kernel-mode rootkits.[18]

Boot loader level (Bootkits)

A rootkit variant called a bootkit is used predominantly to attack full disk encryption systems as in the Evil Maid Attack.[19] The bootkit replaces the legitimate boot loader with one controlled by an attacker; typically the malware loader persists through the transition to protected mode when the kernel has loaded. For example, the "Stoned Bootkit"[20] uses a compromised boot loader to subvert the system, which extracts information and keys. 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

Kernel-level rootkits add additional code or replace portions of the 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.[21] 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 has unrestricted security access. Any bugs in code operating at the kernel level may seriously impact system stability. The original rootkits did not operate at kernel level. One of the first widely known kernel rootkits was developed for Windows NT 4.0 and released in Phrack[22] in the mid-1990s by Greg Hoglund.[23]

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 operating system operations. Any software, such as antivirus software, running on the compromised system is equally subvertible. In this situation no part of the system can be trusted.

Library level

Library rootkits commonly patch, hook, or replace system calls with versions that hide information about the attacker.

Application level

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.

Distribution

Malware can be embedded in video or other files which can be uploaded to unsuspecting users though common applications or via the user's request. Accessing such a file can release malicious code.

Detection

The fundamental problem with rootkit detection is that if the operating system has been subverted, it cannot be trusted to find unauthorized modifications to itself or its components. Actions such as requesting a list of running processes, or a list of files in a directory, cannot be trusted to behave as expected. Rootkit detectors running on live systems currently work because the rootkits they can detect employ poor camouflage. As with computer viruses, the detection and elimination of rootkits is an ongoing struggle between both sides of this conflict.

Several products detect rootkits. Unix offerings include Zeppoo, chkrootkit, rkhunter and OSSEC. For Windows, free detection tools include Microsoft Sysinternals Rootkit Revealer, avast! antivirus, Sophos Anti-Rootkit, F-Secure Blacklight, and Radix.

Alternative trusted medium

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 hide its presence, and most established antivirus programs can identify rootkits via standard OS calls (which are often tampered with by the rootkit) and lower level queries, which remain reliable. This also defeats the camouflage technique which suspends rootkit activity until scanning has finished; this is not possible if the rootkit is not running.[citation needed]

Antivirus

Antivirus products rarely catch all viruses in public tests, even though security software vendors incorporate rootkit detection into their products. Should a rootkit attempt to hide during an antivirus scan, an appropriate stealth detector notices; if it attempts to temporarily unload itself from the system, fingerprint (or signature) detection can still find it. This combined approach forces attackers to implement counter-attack mechanisms ("retro" routines) that kills the antivirus program.

Memory/disk comparison

Another method that can detect rootkits is comparing 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 likely be classified as system call hooks introduced by a running rootkit (System Virginity Verifier).

Cryptographic fingerprinting

A cryptographic "fingerprint" using a digital signature can help detect unauthorized changes to code libraries.[24] However, unsophisticated schemes check only whether the code has been modified since release by the "publisher"; subversion prior to that time is not detectable. The fingerprint must be reestablished each time changes are made to the system. The fingerprinting process creates a message digest dependent on every bit in each file being fingerprinted. By recalculating and comparing the message digest at regular intervals, changes in the system can be arbitrarily detected and monitored. Malware is typically unable to reestablish the fingerprint after installing itself, allowing the detector to flag the change and trigger removal.

Detection in firmware can be achieved by computing a cryptographic hash of firmware files 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 also be protected. 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.[25]

Removal

Since most rootkits hook system files needed at the lowest level of the OS, booting into Safe Mode will not usually allow removal.

Manual repair

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. The user may then examine and replace affected system files and delete unauthorized files and configuration entries while keeping the underlying system intact. A PE boots and loads a clean OS copy from separate media and does not rely on the infected underlying system structure. The PE approach may be employed when the system contains irreplaceable data that might be lost during a reinstallation or disk imaging process.

Re-installation

More often, manual repair is impractical. Even if its type and nature are known, re-installing the operating system and applications is simpler and quicker. Re-installation time can be greatly reduced by modern drive imaging software, especially when the source image includes necessary hardware drivers and software applications. This is true even if the rootkit is well-known and can be completely removed.[26]

Direct NTFS access

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 (NTFS) files. In effect, VxMS can map data, compare it to the NTFS file structure, and isolate any mismatches. VxMS technology was added to Symantec's Norton product line from the 2007 product year.[27][28][29][30][31]

Comparison with computer viruses and worms

Viruses

The key distinction between a computer virus and a rootkit is how they propagate. 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").

Rootkit payloads may attempt to maintain the rootkit's integrity (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. Some rootkits add port knocking checks to existing network daemons (services), such as inetd or sshd.

A virus can have any sort of payload. However, viruses typically attempt to spread themselves to other systems. In general, rootkits limit themselves to maintaining control of one system.

Worms

A program or suite of programs that scans networks for vulnerable systems and exploits those vulnerabilities to compromise those systems is referred to as a worm. Other worm forms sniff for user names and passwords, compromising those accounts, installing copies of themselves in each such account (and usually relaying the account information back to the intruder through some sort of covert channel).

Hybrids

Hybrids can install a rootkit, and a rootkit might include copies of one or more worms, packet sniffers or port scanners. Many e-mail worms are commonly referred to as "viruses," so all of these terms have somewhat overlapping usage and are often conflated.

Public availability

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 effective.

See also

References


  1. ^ Brumley, David (16 November 1999). "invisible intruders: rootkits in practice". USENIX. http://www.usenix.org/publications/login/1999-9/features/rootkits.html.
  2. ^ Thompson, Ken (1983). "Turing Award Lecture" (pdf). http://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf.
  3. ^ Mark Russinovich (31 October 2005). "Sony, Rootkits and Digital Rights Management Gone Too Far". http://blogs.technet.com/markrussinovich/archive/2005/10/31/sony-rootkits-and-digital-rights-management-gone-too-far.aspx. Retrieved 2008-09-15.
  4. ^ "New backdoor program uses Sony rootkit". Kaspersky Lab. 10 November 2005. http://www.kaspersky.com/news?id=173737204. Retrieved 2008-09-15.
  5. ^ "Sony's long-term rootkit CD woes". BBC News. 21 November 2005. http://news.bbc.co.uk/2/hi/technology/4456970.stm. Retrieved 2008-09-15.
  6. ^ Mark Lyon (06 Feb 2006). "Settlement Notice". Sonysuit.com. http://www.sonysuit.com/.
  7. ^ Russinovich, Mark (6 February 2006). "Using Rootkits to Defeat Digital Rights Management". Winternals. SysInternals. Archived from the original on 31 August 2006. http://blogs.technet.com/markrussinovich/archive/2006/02/06/using-rootkits-to-defeat-digital-rights-management.aspx. Retrieved 2006-08-13.
  8. ^ Mark Russinovich (June 2005). "Unearthing Root Kits". Windows IT Pro. http://www.windowsitpro.com/Article/ArticleID/46266/46266.html.
  9. ^ Implementing and Detecting an ACPI Rootkit by John Heasman, presented at BlackHat Federal, 2006.
  10. ^ Implementing and Detecting a PCI Rootkit by John Heasman, November 15, 2006.
  11. ^ Austin Modine (10 October 2008). "Organized crime tampers with European card swipe devices: Customer data beamed overseas". The Register. http://www.theregister.co.uk/2008/10/10/organized_crime_doctors_chip_and_pin_machines/. Retrieved 2008-10-13.
  12. ^ Sacco, Anibal; Ortéga, Alfredo. "Persistent BIOS infection". Core Security Technologies. http://www.coresecurity.com/content/Persistent-Bios-Infection. Retrieved 2009-10-06.
  13. ^ Dan Goodin (24 March 2009). "Newfangled rootkits survive hard disk wiping". The Register. http://www.theregister.co.uk/2009/03/24/persistent_bios_rootkits/. Retrieved 2009-03-25.
  14. ^ Phrack Magazine #66
  15. ^ Sacco, Anibal; Ortéga, Alfredo. "Deactivate the Rootkit". Exploiting Stuff. http://exploiting.wordpress.com/2009/09/11/138/.
  16. ^ Sacco, Anibal; Ortéga, Alfredo. "Deactivate the Rootkit". Core Security Technologies. http://www.coresecurity.com/content/Deactivate-the-Rootkit.
  17. ^ "SubVirt: Implementing malware with virtual machines" (PDF). University of Michigan, Microsoft. 3 April 2006. http://www.eecs.umich.edu/virtual/papers/king06.pdf. Retrieved 2008-09-15.
  18. ^ Zhi Wang, Xuxian Jiang, Weidong Cui & Peng Ning (11 August 2009) (pdf Protection). Countering Kernel Rootkits with Lightweight Hook. Microsoft/North Carolina State University. http://research.microsoft.com/en-us/um/people/wdcui/papers/hooksafe-ccs09.pdf. Retrieved 2009-11-11.
  19. ^ Bruce Schneider (23 October 2009). ""Evil Maid" Attacks on Encrypted Hard Drives". http://www.schneier.com/blog/archives/2009/10/evil_maid_attac.html. Retrieved 2009-11-07.
  20. ^ Peter Kleissner (19 October 2009). "Stoned Bootkit". Insecurity Systems. http://www.stoned-vienna.com/. Retrieved 2009-11-07.
  21. ^ The 64-bit version of Windows XP and Server 2008 are a notable exception "Driver Signing Requirements for Windows". Microsoft. http://www.microsoft.com/whdc/winlogo/drvsign/drvsign.mspx. Retrieved 2008-07-06.
  22. ^ issue 55
  23. ^ Rootkit Evolution by Alisa Shevchenko (1 September 2008), An Overview of Unix Rootkits by Anton Chuvakin (February 2003)
  24. ^ "Signing and Checking Code with Authenticode". Microsoft. http://msdn.microsoft.com/en-us/library/ms537364(VS.85).aspx. Retrieved 2008-09-15.
  25. ^ "Stopping Rootkits at the Network Edge" (PDF). Trusted Computing Group. 4 January 2007. https://www.trustedcomputinggroup.org/news/Industry_Data/Whitepaper_Rootkit_Strom_v3.pdf. Retrieved 2008-07-11.
  26. ^ "Rootkit Question". Spywareinfoforum.com. http://www.spywareinfoforum.com/lofiversion/index.php/t52360.html. Retrieved 2009-04-07.
  27. ^ Posted by Flashlight (30 April 2007). "Tech Loop: Rootkits: The next big enterprise threat?". Techloop.blogspot.com. http://techloop.blogspot.com/2007/04/rootkits-next-big-enterprise-threat.html. Retrieved 2009-04-07.
  28. ^ "Security Watch: Rootkits for fun and profit - CNET Reviews". Reviews.cnet.com. 19 January 2007. http://reviews.cnet.com/4520-3513_7-6686763-1.html. Retrieved 2009-04-07.
  29. ^ Sponsored by Dell. "Six ways to fight back against botnets - Business Center". PC World. http://www.pcworld.com/businesscenter/article/137821/six_ways_to_fight_back_against_botnets.html. Retrieved 2009-04-07.
  30. ^ 12:00 AM. "Handling Today's Tough Security Threats: Rootkits - Malicious Code - STN Peer-to-Peer Discussion Forums". Forums.symantec.com. https://forums.symantec.com/t5/Malicious-Code/Handling-Today-s-Tough-Security-Threats-Rootkits/ba-p/305215;jsessionid=7D537BC23D36E015CD11EA806B389E54#A68. Retrieved 2009-04-07.
  31. ^ Hultquist, Steve (30 April 2007). "Rootkits: The next big enterprise threat? | Security Central". InfoWorld. http://www.infoworld.com/d/security-central/rootkits-next-big-enterprise-threat-781. Retrieved 2009-04-07.

Further reading

External links

Retrieved from "http://en.wikipedia.org/wiki/Rootkit"
Namespaces
Variants
Actions
Go there...
http://en.wikipedia.org/wiki/Rootkit

Don
at

No comments:

Post a Comment