In the last couple of days I have been reading and hearing about Rootkits and the panic that comes with it. Mainly on German forums and sites, although also e.g. on Joanna Rutkowska’s blog (author of the “famous” Bluepill hijacker technique). And it kept me thinking. But first let me summerize what I understand the fuzz is all about.
A Rootkit is some sort of malware. Depending on whom you ask or enlist it is a piece of software running on someone’s computer — preferably with an Internet connection — without the user or even administrator knowing. I understand the definition itself so that this program does not have to be hiding itself in the memory and/or on the hard drive from detection software but it may (regardless of the, to my knowledge and despite Joanna’s work, unanswered question if potentially it can do so at all). Rootkits like any other malware have to be transferred to the target computer in some way or another and are — the hiding once like any other — detectable in this non-executed state (via digital signature for example). Ones primed, i.e. executed, the code becomes a process in the computer’s memory and tries to hide itself with various methods in memory and hard drives (potentially also MBR or even BIOS, but as far as I read/heard non have been reported so far).
Another factor of Rootkits is that they most often start with a small subset of code/features/routines and, ones residing in memory, recruit more and more features via the computer’s net link through a so-called back door. The back door part is why the differentiation from Trojan Horses is blurry. I’d say the Trojan Horse technique is only one of many features of such a Rootkit but that doesn’t make it a Trojan Horse since it’s not all it can do.
One other of the many possible features, and first shown by the before named Bluepill, is to become a hypervisor (think of it as a sandbox for OSs) like Xen (virtual machines like VMware, Qemu/VirtualBox work differently). The fancy bit about bluepill’s method is that, while active, the OS’ kernel is virtualized, i.e. becomes a guest OS from being host OS before; Microsoft Vista kernel here. It’s done by forcing to swap kernel parts to pagefile.sys which than are modified on disc — no Vista kernel protection — and loaded back to memory. Let me point out: On-the-fly, no reboot or BIOS or MBR modification necessary! That means that the malware runs below the OS or, rephrased the other way around, the real OS runs on top of the malware.
From Darkreading:
The new Blue Pill comes with support for so-called “nested” hypervisors (think Blue Pill within a Blue Pill), and uses an architecture similar to that of the open-source Xen 3 virtual machine technology. It comes with “on the fly” loading and unloading features, as well as more features for avoiding detection, such as hibernating and temporarily uninstalling the hypervisor when Blue Pill detects that a tool is about to detect it.
Let me add: This utilizes Pacifica specification of AMD’s newer processors which have virtualisation technology (VT) build-in. It just has been started on AMD processors but there are also implementations for Intel processors with similar techniques.
Having said all that I came to think of how could it still be possible to detect and what are the remarkable bits here. Let me also point out that I am by no means an expert on anti virus, Rootkits, hypervisors or any of that. I just know a some basic, though advanced, computer issues, how they basically work, about TCP/IP stuff and Linux OS basics. And I claim to have common sense 
Ideas mentioned elsewhere to encounter the issue and comments on them:
Ok, now there is one point that is not technical at all: How do I detect something that can hide (let’s presume so) from a running system if I don’t see it and wouldn’t get alerted by any detection software? Imagine working on your computer and thinking: “Am I infected? Let’s check and boot to this detection LiveCD [see below]… checking… Good, not infected, so reboot to work system… keep on working… Oh, an now? Infected now?… LiveCD check… reboot to work, since still not infected… work a little… Hah, now is the time, I could now be infected… reboot….”.
The rumours are that it would be easy to detect the malware hiding on active systems when the system is dormant, i.e. not booted, e.g from some LiveCD. That’s one point I could believe to be true to some extant since I guess the malware has to have saved itself on system shut down to some place on the hard drive, BIOS (graphic card’s one, too), or some kind of non-volatile memory and, more importantly, cannot defend, i.e. hide, itself actively. But as with any malware detection by signature the signature of such “saved state hiding malware” has to be known which might be hard since it’s easy for malware to change it’s “saved state form” and thereby it’s signature. And also, is it handy and operably in real life to shut down, eg., servers “only” to detect potentially infected systems (again, assuming all the while it’s not possible to detect while the system is active)?
If it’s possible to only have one hypervisor (what I don’t know right now) then wouldn’t it be easy to just check if a hypervisor is present or can be enabled. If not because one is present already but not known about by the system -> suspicious. Matasano’s virtualized rootkit detector most likely is about even more than that (from Hacker Smackdown, June 28th, 2007):
Ptacek, Lawson, and Ferrie contend that virtualization-based malware is actually easier to detect than a normal (non-virtualized) rootkit because basically by definition it leaves a trail, introducing changes in the system’s CPU clock, for instance. And the malware would have to be bug-free to truly emulate a system, anyway, Ptacek argues. “The problem with virtualized rootkits is… They have to present the illusion they are talking to real hardware and that’s not an easy task,” he says. “In order to do that, you have to write a bug-free program whose job it is to emulate bugs. And we don’t know how to write bug-free programs.”
One very simply (that’s why I liked it!) detection method described in a German forum was to simultaneously do an outside port scan and ask the system “from inside” for open ports. Most likely the malware will show an open port to the outside (it wants to receive data here) but will hide this port to the system running the malware.
Ideas I haven’t read about so far or are not related directly but rather with malware in general but still fairly new:
- As a basic approach (operating) systems have to be transparent (best I know of open source) for experts to know what’s going on inside and users to trust “their” system. This is no new argument I assume.
- Digital signature (public/private keys) handling in kernel for processes similar to what I believe Vista does but holistically and, again, transparent. The idea is similar to that Debian (and other distributions since) have been using with their repositories and dpkg/apt system for years now but now within the computer itself. SecureApt as it’s called uses MD5 checksums (switch to SHA-1 when MD5 is broken) to uniquely and securely identify software packages retrieved from Internet repositories and to verify data (read byte stream) is unchanged on the way from the maintainer to the user’s computer. On top of that SecureApt uses OpenPGP (with GPG) private keys to sign repositories release summaries and public keys to verify the signature, i.e. deciding whether a repo is trusted or not. Why not taking this one step further to the kernel itself and have a module in the kernel implementing the idea of SecureApt but for processes (instances of programs from those repositories)? Though, I guess with quantum computers approaching this prevention method most likely will not hold long anyway.
- Security systems (German) like AppArmor or even better SELinux should be used more widely to protect more systems better from so-called 0-day attacks and the like. And thereby limit distribution of malware. These two methods, of course, do nothing to increase detection on harmed systems. It only prevents from becoming infected.
- Don’t by VT supported processors if you don’t need to. This, as with all security issues, will not work on a wide range since it’s more convenient to benefit from supposingly up to 95% performance enhancement for so-called paravirtualized guest systems (more precisely domUs). At least if you need to run unmodified OSs like MS Windows. If you can however modify the domUs, eg. Linux, you can have the same performance with eg. Xen. Let me point out that unlike virtualized guest operating system with paravirtualization the domU does know about it being virtualized and can, among others, access hardware directly.
- Another idea on how to become suspicious of possible infections includes a second system with net link to computers at risk. I’d call it a watch server or pass-through server. Maybe it could just be your firewall of choice. The idea is to watch the traffic from an to computers in your network just like a firewall does but watch for and learn some sort of network traffic signatures or patterns. This way you get a (statistical) profile of typical traffic regarding individual systems independent of applications running, user behaviour or or the like. Just plain network traffic. This, of course, has to be done while one is certain of no infections in the network. If one can guaranty this it could be possible after this learning phase to detect suspicious traffic.
Maybe everything said here is not new at all to others. But one thing I reckon will be true: After all it will always be a game of cat-and-mouse, since the bad guys will try to detect methods like those mentioned here to hide themselves and the good guys will always try to be smarter. The most interesting part I find about self hiding malwares is that malware is turning the tables now (well, not entirely): With conservative viruses it was evolving new techniques unknown to the anti-virus guys. Now it’s (partly) malware becoming virus-detection-detectors.
And one other thing once again became clear to me: The need for researchers to “do bad things”, i.e. to develop, test, execute, issue and whatever else necessary malware of whatever kind to be able to come up with antidote! Unfortunately there are movements on the way in Germany (German, heise, 06.07.2007 14:23) and as I understand in other parts of the would, too, to prohibit this.
Happy hacking 
Update 2007/10/11:
In slashdot there has been a note on VM-Based Rootkits Proved Easily Detectable pointing out an article from researchers from Stanford, CMU, VMware, and XenSource “Compatibility Is Not Transparency: VMM Detection Myths and Realities” (pdf). Unfortunatelly, untill now I haven’t had the time to read it.
Resources:
9.0.48.0:
all posts
