Dale Preston's Web Log
Sunday, April 24, 2005

Rootkits and Hooks

I have spent most of this weekend reading about a pretty scary phenomenon: Rootkits. If you haven't heard of them, you'd better read on and follow the links at the end of this article. If you are familiar with them already, then you might want to skip the next section and jump right to Microsoft and Hooks.

Rootkits - What are they?

Rootkits are the latest craze among trojan and spyware authors. I assume you know that trojans are "back-door" programs - programs that are intended to allow unauthorized (and often undetected) access to your PC, servers, and network. Spyware are a type of program that, either in secret or in plain site, tracks your computer usage and potentially records everything from the Internet sites you visit, to your passwords, credit card numbers, emails, to every keystroke you type in any program.

Rootkits aren't really new. They've existed in Unix systems for many years - hence the term Root which describes a role in Unix/Linux which sort of matches a combination of Administrator and System in Windows. Rootkits are not even new to Windows. It has always been technically possible and financially worth the effort to write the more sneaky rootkits as compared to common spyware - it just hasn't been necessary. What makes them significant now is that with the proliferation of anti-spyware programs and the awakening of the Internet user to their threat, it is harder for the malware creators to spread their products so now they are turning to rootkits out of necessity.

What makes rootkits different from all the previous generations of these insidious applications is that they are virtually undetectable by current spyware and anti-virus scanners.

Rootkits - How they work

File Scans - One way that virus and spyware scanners find malware (a term generally used to describe any type of virus, trojan, spyware, etc.) is to scan your hard disk directory, retrieving the name of each file, opening that file, and searching its contents for known signatures matching the virus or spyware database in the scanner software. Rootkits intercept all requests to the file directories and remove the names of their own files from the lists that are returned. For instance, if I have a folder that has the following four files:

and I try to retrieve a list of the files in that folder, either using a DOS "DIR" command, by opening the folder in Windows Explorer, or by enumerating the files in my virus scanning program, the rootkit will intercept the request and return only:

If the virus or spyware scanner cannot see that the file exists, it cannot open it and scan it.

Registry search - In order for malware, or any other application, to automatically start with Windows or when a user logs in to the PC, it must hook itself to what Microsoft calls an Auto-Start Extension Point or ASEP. Most ASEP's exist within the Windows registry. Some exist in the file system but the previous section on file scans deals with how those would be exploited.

Malware scanners search the registry for known entries related to starting or configuring the malware that match data in the scanner's database. For instance, many malware programs, as do many legitimate programs, use the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run registry key to make sure they start each time Windows starts. Malware scanners use Windows functions to scan that section, and others, of the registry looking for known malware entries.

Rootkits intercept those Windows functions and return all the entries except their own, again eliminating the opportunity to scan the entry because the entry cannot be seen.

Task lists - Just like the Windows Task Manager, the malware scanner uses Windows functions to retrieve a list of all running processes on a PC. Then they examine each process and compare it to known signatures in their database.

Just like the file scan and registry search, the task list functions get hooked by the rootkit and omit the rootkit's own processes from the list.

Microsoft and Hooks

At the end of this article there are several links that will further your knowledge, fear, and understanding of rootkits. With all that information out there, you might wonder, why should I write yet-another-rootkit-article? The answer is in the title of this section. Microsoft and Hooks.

In researching rootkits, I came across a site, http://www.rootkits.com that openly publishes how to create and exploit rootkits. They run a message board that seems full of do-gooders writing intelligent and well-stated arguments against the owners of the site for their evil deeds and sharing the air that the rest of us breathe. While I agree on most every point these message board posters make, just remember that if the opportunity exists, someone will take it. Yes, blame the criminal, but you also have to blame those who create the opportunity. If I take my savings out of the bank and put it in a cash bag stored on my front porch, who do I blame when someone eventually walks away with my life-savings?

What has made many spyware programs such as keyloggers possible is the ability to hook the keyboard processes and record each key before sending the keystroke information to intended application. Similar hooks are available for network access, starting programs, logging into Windows, and more. There are many legitimate reasons for attaching to each one of those processes, and as many illegitimate reasons for each one. It is these hooks that allow most types of malware, rootkits or otherwise, to exist.

The problem with the hooks process is that there is no functionality in Windows that allows the malware scanners or the user to view the entire chain of processes that hook a process. For instance, if the normal flow for a keystroke is
    Keypress ->
    Keyboard driver ->
    Windows User32.dll ->
    The application the user is typing in
the hooking process may have several hooks, some legitimate, some not:
    Keypress ->
    Keyboard driver ->
    Some desired keyboard hook ->
    Another desired keyboard hook ->
    A spyware's keystroke logger hook ->
    And another desired keyboard hook ->
    The application the user is typing in
I recently purchased an anti-spyware program for a client to search for keylogging software on their PC's. The program had to rely on its database of keyloggers to search for programs hooking the keyboard process. There is no functionality in Windows that allows the program to start at the keyboard and list every process or application that sees your keystroke on the way to the program for which the keystroke is intended.

In my example above, there is no way to see that the "A spyware's keystroke logger hook" is in the process flow. That is a serious flaw in the design of Windows. The same flaw exists for hooks in file enumeration and process enumerations.

In Microsoft Research's Strider-Gatekeeper technology, which neither you nor I - nor apparently anyone else - can get, Microsoft talks about reporting all suspicious hooks to the user (including, I assume, to malware scanners besides those sold by Microsoft) as a spyware solution. Good for them!

The problem is, and what really prompted me to write an article rather than just refer you to the work of others, is Microsoft's opposite stance about hooks when it comes to protection from rootkits. While, if they ever release it to the public, Microsoft's Strider GhostBuster Rootkit Detection system seems to have great potential for detecting rootkits, it requires running a test with the computer offline. They state that exposing hooks is not a solution to rootkit protection. I disagree. If Microsoft would simply add non-hookable functionality to enumerate hooks wherever they exist in the system, then programs would not be able to hide from malware scanners. The malware application could still establish the hooks and deny their existance as described above, but the operating system and the malware scanners would all know that the hooks exist. Hooks owned by hidden processes would immediately alert the malware scanner which could alert the user to run whatever rootkit tools may yet hit the market.

Rootkit Links

Start with Microsoft's Strider GhostBuster Rootkit Project. I suggest following each link from this page, downloading the Word and Adobe PDF documents you find on the linked pages, and reading them all. That should take about a day.

While I won't list each link that is on the Microsoft rootkit page above, one link, Sysinternals' RootkitReveler needs its own reference because, as far as I was able to find at the time of this writing, it is the only production application for detecting rootkits. And it's free!

And the mother of all rootkit links is http://www.rootkit.com.

What next?

Microsoft's Strider GhostBuster is based on Microsoft's WinPE for which availability is currently intentionally and specifically denied to the masses - it is only available to large customers and other select favorite customers - at any price. To create your own utility with similar functionality I suggest using BartPE which is free and available to anyone.

Create a BartPE build with Microsoft's Windiff.exe included. Then you can get a directory listing of the suspected disk from its native OS, which will give you the suspected lie. Boot with the BartPE build and create another directory listing of the suspect drive. This will give you the presumed truth. Any files in the truth - the BartPE build directory listing - that are not in the native OS listing are hidden files.

To create the directory listing from the native OS, execute both of the following commands in a command window:
  1. dir /b /s /ah > A:HiddenAttributeFilesNative.txt

  2. dir /b /s /a-h > A:\NoHiddenAttributeFilesNative.txt
The first command lists all the files with the hidden attribute set (which is not the same as hidden in terms of a rootkit file. The rootkit file would not show up in this listing when retrieved from within the native OS). The second command lists all the files that do not have the hidden attribute set. Make sure you have a blank formatted floppy in your drive or substitute some other storage medium that will be available to both the native OS and the BartPE OS. You can, of course, name your files anything you like. Just make sure you get both listings.

Then boot from the BartPE built OS and run the commands again, but alter the file names so you don't overwrite the original files:
  1. dir /b /s /ah > A:HiddenAttributeFilesBartPE.txt

  2. dir /b /s /a-h > A:\NoHiddenAttributeFilesBartPE.txt
Now you can run Windiff.exe to compare the two lists of hidden attribute files, and the two lists of files without the hidden attribute. Files that show up in the BartPE lists but not in the native OS lists should be investigated thoroughly or just assumed to be malicious.

If you don't have Windiff.exe on your PC, you can find it in the Support Tools folder of your OS installation CD.

If you find your computer infected with a rootkit, don't bother cleaning. Format your drive and reload your OS. It is the safest, fastest means available. Besides, this is a Windows environment and Windows always benefits from being reloaded often, right?

In a future blog, if no one else has already published one (pay attention Sysinternals--You guys could save us all a lot of effort here), I will publish a complete difference analyzer to provide similar (if basic) functionality to the Strider GhostBuster out-of-the-box functionality.

nice post yes sir, read it throughly and im gonna make that test. thx !!
Really nice articles for newbies for rootkits
Post a Comment

<< Home

Powered by Blogger