2005-11-17
1. Introduction
In our previous article, we discussed current rootkit development techniques. In this article, we take it a step further and focus upon upcoming, cutting edge trends in rootkit technologies. Then the third and final article in this series will discuss various methods of rootkit detection and countermeasures that can be used by security professionals.1.1 Persistent versus memory-based rootkits
Generally speaking, there are two types of rootkits: persistent rootkits and memory-based rootkits. The primary difference between these two types of rootkits lies in their "persistence" on an infected machine after a reboot. Persistent rootkits are capable of surviving a system reboot whereas memory-based rootkits are not. In order to survive a reboot, two conditions must be met. First, they must have some means of permanently storing their code on the victim system (such as on the hard disk). Second, they must place a hook in the system boot sequence so that they can be loaded from disk into memory and begin execution.1.2 Hiding a rootkit's presence
Rootkit writers have developed a number of clever techniques for hiding their rootkit's presence on a system. These techniques range from various hooking tricks to direct kernel object manipulation (DKOM). Nevertheless, even the most sophisticated kernel rootkits like FU have an inherent flaw. [ref 1] Although these rootkits are experts at controlling the execution path, for the most part they have not demonstrated an ability to control the view of memory that is seen by other applications. Thus, these rootkits must address two primary issues if they are to remain undetected. First, they must be able to conceal the presence of their own executable code. Second, they must be able to conceal their memory-based modifications (i.e., hooks) in operating system components. Without these capabilities, even the most sophisticated public kernel rootkits are "sitting ducks" for primitive in-memory signature detection scans - the same type of scans anti-virus products have been using for the past 20 years. Persistent rootkits must furthermore deal with hiding their code on a long tem storage medium and concealing a permanent hook in the system boot sequence. In this article, we will be addressing the first two issues and ignoring the third. Practically speaking, this confines our discussion to memory-based rootkits.2. Virtual memory concepts
Most modern architectures make a distinction between "virtual" and "physical" memory. Oftentimes, a system will have a great deal more virtual memory than physical memory. Consider a 32-bit system with 256 MB of installed RAM. On this machine we have 4 GB of virtual memory, even though our physical memory size is only 256 MB. In short, physical memory size is defined by the amount of physically installed RAM, and virtual memory size is defined by the width of the processor's address bus. Thus, with a 32 bit processor we are capable of addressing a maximum of 2^32 bytes, or 4 gigabytes of virtual memory. With a 64-bit machine, we would be capable of addressing 2^64 bytes, or over 16 exabytes of memory!- Lookup in the page directory to determine if the page table for the address is present in main memory.
- If not present, an I/O request is issued to bring in the page table from disk.
- Lookup in the page table to determine if the requested page is present in main memory.
- If not present, an I/O request is issued to bring in the page from disk.
- Lookup the requested byte (offset) in the page.
Figure 1. x86 virtual To physical address translation.
3. Shadow Walker: how it works
The Shadow Walker proof of concept currently consists of 2 drivers, a modified FU rootkit driver and a memory hook driver that is used to hide the FU rootkit. As Shadow Walker is intended only to be a proof of concept demonstration, it makes no effort to hide the memory hook driver or otherwise conceal the page fault handler and corresponding interrupt hook. It also possesses a number of implementational limitations, including lack of PAE (Physical Address Extension) and multiprocessor support. Shadow Walker is not intended to be a fully functional or weaponized rootkit and, in its current implementation, it is detectable from a variety of angles. Rather, it is intended to provide a chilling glimpse into the future of rootkit technology. A fully weaponized rootkit, worm, or spyware application based upon Shadow Walker is within reach of a skilled attacker and given the state of existing malicious code detection technology, it is a scary thought indeed. These methods make it possible for an attacker to hide both known and unknown malicious code from signature scanners, heuristic detectors, and integrity checkers. In the next paragraphs, we discuss the implementational details behind the virtual memory subversion techniques used by Shadow Walker.3.1 Background information
Although it is common knowledge that there are three basic types of memory access (read, execute, and write), it is less common knowledge that there are, in fact, only two types supported for most of the 32-bit x86 processors (read/execute and write/execute). Execute access is implied, meaning that all memory is executable and there is no direct, supported means of marking it otherwise. This quirk of the architecture has been the bane of buffer overflow intrusion detection systems because it meant that there was no easy way to make the stack non-executable . [ref 2] Not to be outdone, a group of software security developers discovered that another quirk of the architecture made it possible to implement "no-execute" memory with additional software support under UNIX. [ref 3] This implementation became known as PaX. Shadow Walker takes advantage of some of the PaX team's research to hide executing code on Windows systems.- They must be able to conceal the presence of their own executable code from in memory signature scans.
- They must be able to conceal their memory based modifications (typically, hooks) in operating system components from heuristic detection (with tools like VICE) and integrity checkers. [ref 4]
3.2 Shadow Walker's subversion of virtual memory
Shadow Walker must address three issues in its subversion of virtual memory. First, it must be able to differentiate and filter execute, read, and write accesses to certain memory ranges (i.e. the memory where its own executable code resides or the memory of some subverted operating system APIs). Second, it must be able to "fake" the read accesses when they are detected. Lastly, it must ensure that the performance of the victim system is not adversely affected.Figure 2: TLB Desynchronization
4. Concluding part two
Shadow Walker provides an example of an ironic, however, common yin/yang theme in computer security. It takes an originally defensive solution to a security problem (with the PaX-based buffer overflow protection) and inverts it into an offensive exploitation technique. The recent controversy surrounding Sony's usage of rootkit technology to provide Digital Rights Management is yet another compelling example. The lines between protection and exploitation between the "hacker" and the "security professional" are not as clearly defined as many would like to believe.5. References
[ref 1] Fuzen, FU Rootkit. [url]http://www.rootkit.com/project.php?id=12[/url][ref 2] Hardware support has subsequently been added for non-executable memory in 64-bit systems as well as some AMD Sempron and Intel Pentium 4 processors. Windows also provides limited software support in the form of Data Execution Prevention (DEP) as of Windows XP Service Pack 2 and Windows 2003 Server.
[ref 3] PaX. [url]http://pax.grsecurity.net/docs/pax.txt[/url]
[ref 4] Butler, James, "VICE - Catch the hookers!" Black Hat, Las Vegas, July, 2004. [url]www.blackhat.com/presentations/bh-usa-04/bh-us-04-butler/[/url] bh-us-04-butler.pdf
5.1 Further reading
Rutkowska, Joanna. "Concepts For The Stealth Windows Rootkit", Sept 2003 [url]http://www.invisiblethings.org/papers/chameleon_concepts.pdf[/url]6. About the authors
James Butler is the CTO of Komoku, which specializes in high assurance, host integrity monitoring and management. Before that, Mr. Butler was the Director of Engineering at HBGary, Inc. focusing on rootkits and other subversive technologies. He is the co-author and a teacher of "Aspects of Offensive Rootkit Technologies" and co-author of the newly released bestseller "Rootkits: Subverting the Windows Kernel."-
GitHub two-factor authentication开启教程
GitHub two-factor authentication开启教程
GitHub 2FA 登录验证 two-factor -
Windows rootkits of 2005, part one
Windows rootkits of 2005, part one
Windows of 2005 休闲 rootkits -
Windows rootkits of 2005, part three
Windows rootkits of 2005, part three
Windows of 2005 休闲 rootkits
举报文章
请选择举报类型
补充说明
0/200
上传截图
格式支持JPEG/PNG/JPG,图片不超过1.9M