Federico Biancuzzi,
2005-09-27
SourceSecurityFocus interviews Greg Hoglund and Jamie Butler on the state of Windows rootkits and how quickly they have evolved. Watch for some detailed Infocus technical articles on the subject of rootkits coming in October.
Could you introduce yourselves?
Greg Hoglund: I'm well known for starting rootkit.com, but I do other stuff too like run a company called HBGary, Inc.
Jamie Butler: I am a kernel developer and contributor at rootkit.com, where I go by the name Fuzen. I really enjoyed working with Greg on the book Rootkits: Subverting the Windows Kernel. Most of my time is spent at the bit and byte level.
When did you hear about rootkits for the first time?
Greg Hoglund: Working at an ISP when the first 'rootkit' was circulating for *nix systems. At the time I thought they were a lot more mystical than they really are. But, of course then, rootkits hadn't merged with the kernel yet.
Jamie Butler: I am not sure of the exact time frame that I learned about rootkits. I guess I knew of their existence since the early UNIX Trojan system file replacements. However, I did not become active in the research until 2001 when I was working on my Master's degree. At that time, I was looking for modifications to the operating system in memory used to hide things. After that research, I realized that you could alter data structures directly in kernel memory to hide without modifying any operating system code. That is what the FU rootkit, which I wrote, is intended to demonstrate. It is not malicious but more proof of a premise.
It's 2005 and the first book on Windows rootkits has hit the market. Why did it take so long? Was all this time needed by the community to reverse-engineer Windows internals?
Greg Hoglund: All the time wasn't really needed, it is just that no one talked about what they knew. If you had a good trick, the last thing you wanted to do is tell everyone about it so it could get fixed. Rootkits are only as good as the tricks they use. Being in the kernel lets you perform a lot more tricks. And, by the way, the system-modifications used by rootkits aren't new at all. Viruses were hooking the interrupt table in '86.
Jamie Butler: The technology that rootkits use is no different than any other device driver. The fundamental information about the operating system needed to write a rootkit has been documented in many books. The Windows Internals books from Solomon and Russinovich, the Undocumented Windows 2000 Secrets book by Schreiber, and the Windows NT/2000 Native API Reference by Nebbett are invaluable resources. Greg and I just use this knowledge, build upon it, and show how an attacker might use it for malicious purposes.
How much is the development of a rootkit influenced by OS source code unavailability?
Jamie Butler: Well, I think the fact that the source code is unavailable for the most part makes the rootkit game that much more challenging. However, source code for operating systems of the LINUX variant does exist, but rootkits are developed for LINUX too. The *NIX rootkits have not advanced as quickly as their Windows counterparts I would argue. No one wants to play tic-tac-toe. A game of chess is so much more fulfilling.
Is this rapid change happening because of the market share of Windows, or because it's a better platform for development of... rootkits?
Jamie Butler: Market share does play a big part. If an attacker writes a Windows rootkit, it can run on the majority of computers in use. Also, homogeneous computer systems make writing rootkits and exploits a lot easier. If the systems are relatively the same, the rootkit developer does not have to alter his or her code.
There are multiple versions of Windows, multiple localized versions, and an infinite number of possible patch levels. How does a rootkit developer address this moving target?
Jamie Butler: Yes, for an attacker that is writing shellcode for a buffer or heap overflow these different versions of Windows present a challenge; however, for the most part, in the kernel things behave relatively the same. Once I write code for Windows NT 4.0, it only takes a few minutes to have that ported over to 2000, XP, and 2003. Under the covers, they are very similar.
Does this mean that automatic tools such as worms could install rootkits without a manual per-host setup?
Jamie Butler: Well, that depends. It is possible to write a universal rootkit that runs on all versions of the Windows server family such as NT, 2000, XP, 2003. Notice it is possible but requires careful consideration and programming by the attacker. When you start adding third party software such as anti-virus and personal firewall products, the attacker's job becomes more difficult because these types of protection software also alter the kernel.
What type of interaction would trustworthy computing (also known as Palladium and TCPA) have with rootkits and OS security?
Greg Hoglund: I haven't looked at it. But, it will be defeated just like everything else. It will take a long time to mature. Assuming it ever sees the light of day, it will get beat up pretty badly coming out of the gate, but then get better over time. Don't trust technology, there is always risk. Maintenance and close attention is what keeps planes flying.
Have you already seen what's possible with Windows Vista?
Jamie Butler: I have not played with Vista yet. I am waiting for more software from Microsoft and security vendors to support 64-bit. Then, I am going to look at Vista 64-bit. I know Microsoft is starting to put some of the Next Generation Trusted Computing Base (NGTCB) technology into Longhorn, but it is being rolled out in stages. How much of Palladium actually makes it into the final product is yet to be seen.
In the book you write that Windows XP-SP2 introduced hot-patching, that is supporting the insertion of new code without rebooting. This feature is perfect for a rootkit playing with functions hooking. Is this another example of new features precedence over security?
Jamie Butler: Yes, this will be exciting for the rootkit community. Hot-patching is becoming a market necessity for large, critical servers, but it also plays into the hands of the attacker making things easier. Since hot-patching is a relatively new feature, we will have to see how it plays out.
OpenBSD's default kernel, called GENERIC, doesn't support LKM (Loadable Kernel Modules). Is this the best solution to fight kernel rootkits?
Jamie Butler: Well, it is a good place to start. However, many choose ease of use over security. Do you really want to have to administer this nightmare in a large company every time someone wants to install a peripheral device such as a printer? Also, even with driver loading turned off, people have shown that you can still introduce code into the kernel by writing to the file that represents physical memory or by exploiting kernel level buffer and heap overflows.
The book is focused on rootkits development, and includes just a single chapter at the end about defense, detection in particular. Don't you think that this book could be more useful to novice hackers than to those who would like to defend themselves, especially since we don't have access to Windows source code?
Jamie Butler: Rootkits have been around for years, and until this year they have been almost completely ignored. I wrote the FU rootkit as a proof-of-concept to bring more attention on the problem. The book is the same way. Vendors have been slow to adopt solutions. Greg and I are just exposing the true level of the threat. Be assured, your enemy already has the information. We only included one chapter on active defenses in the book because as soon as we spell out an algorithm for how to detect rootkits the rootkit authors will change their techniques.
Let's imagine that an admin is suspecting one of his Windows machines is owned by a rootkit. What would you suggest he do?
Jamie Butler: Well, there are some tools that can help identify rootkits. These are fairly young tools and rootkit developers have begun to hide from the rootkit discovery tools as well. One of the tools that an administrator might use to find evidence of a rootkit such as hidden files, Registry keys, and processes is Rootkit Revealer from Sysinternals. However, this tool does not identify processes hidden using data manipulation, which is what the FU rootkit uses. To detect the FU rootkit types of attacks, an administrator can use Blacklight by F-Secure. These are probably two of the more widely uses tools to detect rootkits in Windows. However, neither is perfect. If a rootkit is truly present, it is possible to hide from these tools as well, but it takes a great deal of effort in most cases. Also, once a rootkit is found, there is no good solution to get rid of it. Usually, a complete format and re-install of the computer is suggested because it is unknown how deeply the rootkit has compromised the machine.
Do you have any experience or story to share about rootkits hunting?
Greg Hoglund: Not really - I don't spend much time trying to detect rootkits. But, I do know that FU is one of the most widely deployed rootkits in the world. [It] seems to be the rootkit of choice for spyware and bot networks right now, and I've heard that they don't even bother recompiling the source - that the DLL's found in spyware match the checksum of the precompiled stuff available for download from rootkit.com. I think that is kinda lame, these spyware guys don't even bother to use the source.
Jamie Butler: This was an interesting story from someone at Microsoft who was trying to debug a problem caused by what turned out to be a rootkit.
How many companies or opensource projects used your code to develop or improve an anti-rootkit tool?
Jamie Butler: I am not sure how many companies use our research in their own tools, but I am sure that many monitor rootkit.com for developments. Symantec and others make signatures of the rootkits found there. Many anti-virus companies, forensics companies, and host based intrusion prevention companies have taken the class Greg and I teach called "Offensive Aspects of Rootkit Technology." Microsoft even seems to be more rootkit aware. They have stated that their 64-bit versions of the operating system will not allow hooking the system call table or the interrupt descriptor table. Hooking these is a common trick among rootkit authors. Also, modifications to process and thread objects are supposed to blue screen the new operating system. The FU rootkit is based upon modifying these and other key kernel objects so Microsoft evidently has taken notice.
This year seems to be the year of the rootkit. Other than file signatures, this is the first year we have really seen vendors take the threat of rootkits more seriously. Two tools were even released earlier this year: Rootkit Revealer from Sysinternals and Black Light from F-secure. Both of these were designed to find files, processes, and Registry keys that rootkits have hidden.
Is there any scenario where rootkits could be used legitimately?
Jamie Butler: There are many legitimate uses for rootkits and rootkit technology. However, some may be not use the terminology "rootkit." The same technology used by rootkits is used in security software to extend the protection of the operating system. An example of this is hooking the system call table in order to detect changes to the Windows Registry. Also, corporations use software to monitor their workers in order to enforce the company's IT policy. This corporate monitoring software uses stealth to hide its actions from the user so the user cannot remove it. The "stealth" that hides corporate spyware is the same that could be used in a rootkit. In addition to these examples, law enforcement can use rootkit technology to gather evidence on a suspect without the suspect's knowledge.
Privacy Statement
Copyright 2005, SecurityFocus