Dead Disco - The unpatching trojan

Dead disco
Dead funk
Dead rock and roll
Remodel
Everything has been done

- Emily Haines /Metric

I think Emily of the Canadian (now relocated to L.A.) band Metric works in InfoSec for a day job. Do you ever get the feeling that Everything has been done? Walk into a club, same songs I heard back in 98. Turn on the radio, Eminem still whining about his nasty ex-wife, change the station, same crappy Green Day songs (oh, wait, this one is new! new lyrics about a sad boulevard! wee!). I get the same feeling with relation to security as well. Is there anything new out there?

The Canadians don't get enough credit in my book. Everyone pokes fun, because they call routers, rooters. And processors, proucessors. There is a lot of innovation comming out of Canada, Metric being a prime example. One area of security and hacking in general that is following the lead of our innovative Canadian brothers are rootkits. Greg Hoglund and friends run a great Windows rootkit site, if you haven't spent an afternoon looking through code and posts there in the last 6 months, you are really missing out on some really cutting edge stuff. The Hacker Defender rootkit (a little dated, but full of features) is impressive. Like all modern Win32 rootkits, it loads as a device driver and is generally undetectable by traditional means (Tripwire, port scanning infected box, etc.). In a nutshell, say I load netcat on a box. I can hide the network sockets netcat is using, the running netcat process, the nc.exe file on the filesystem, the couple of kilobytes netcat takes up on the drive, the registry run key I added to restart next at next boot, etc. Hacker Defender also hooks itself into every running process, meaning that I can use the Hacker Defender client to talk to the rootkit remotely on any port I can reach (IIS on 80/tcp, Compaq Insight Manger on 2381/tcp, etc.). This doesn't impact regular use of these services, meaning I don't have to open a new listening socket to communicate with it. You can also do classic port redirection in the same manner, connect to IIS on your hacker defenderized box, redirect to SQL Server a layer back in the DMZ.

Because rootkits are so useful (both for pen testers and malicious hackers), there has been a lot of pressure and market demand to find ways of detecting them. Rootkits like Hacker Defender make use of a technique called function call hooking, essentially you replace a call to a function with a call to your rootkit. Then have the rootkit call the original function so the system behaves normally. The rootkit can then act as a "filter", it can edit out output from the kernel (such as a hide all files that begin with INFOSEC). This proccess of hooking is unfortunately dectectable, via programs like Vice.

The same dude, Jamie Butler, that wrote Vice also came up (maybe he didn't actually invent the idea, but it doesn't matter) with a method of defeating it, a technique called Direct Kernel Object Modification(DKOM). What a DKOM rootkit does is take advantage how how Windows keeps track of running processes. A grossly simplifed description of this hack is that the new Win32 DKOM rootkit will modify a data structure called EPROCESS, which contains a linked list that Windows can move either forward or backwards on to determine which processes are running. Think of it like a chain with many links, each link representing an active process. The DKOM rootkit will remove one link from the chain, by having the previous link now point to the next link, and the next link point to the previous link. The process still runs in Windows, but is now hidden. You can also do other cool stuff that you otherwise couldn't with a call hooking rootkit. You can add priveldges to a running process, change the process owner (makes computer forensics pretty hard if you can't tell who is running what program), and others.

So what's the lesson here? Let's recap: Czechoslovakian guy writes cool rootkit -> other guy thinks of way to find his rootkit -> another dude figures out how to hide his rootkit again.

We can continue this process: smart polish girl outsmarts last 3 dudes -> some Italian dude outsmarts the girl -> society eventually collapses because homo sapiens ate 4.6 billion years of built up resources in a couple thousand years.

Some people have worked on getting away from this arms race (please don't take this as me insulting the aforementioned rootkit writers). The fight here is that no matter what, we are adding files to the physical hard drive. Even thought these rootkits will fake out usermode programs at runtime (Tripwire, etc.). A suspicious admin can always take out the drive, run it through FTK, and find the new files on the system. Real time computer forensics offers the possibility of doing this remotely without having to take apart the box. There have been all sorts of neat innovations to counter a classic computer forensics investigation. One is to store your rootkit in the eeprom chip in your video card. So, now, if you yank your drive out and do some computer forensics on it, you won't find a thing. Even if you replace the physical drive, the hostile code on your video card will reinfect your hard drive. You can use this utility to find all writable eeprom memory attached to your motherboard that could be used to store a rootkit "off drive".

Another idea is to modify an existing program on the compromised host to remove or otherwise degrade security. This would be done via some sort of an "unpatch". This technique has the advantage of not adding new files to the filesystem, and can (under the right conditions) be less detectable. This is by no means a new idea. You can also find examples of hackers doing this in the wild, some guys hacked into sendmail, libpcap, dsniff, OpenSSH and placed trojan code into these heavily used open source programs. The trojan code would have the box connect out to IRC, and would allow a person in the know to control any unlucky admins that had installed trojaned versions. This trojaned code was detected quite quickly (due to strange build errors), and the network connection out to IRC.

A less subtle unpatch, and the focus of this post, is to reduce the security of a process with a listening network socket. The first well-known description of an this is an article from 1999 in Phrack 55, where the author describes a method of making a binary unpatch for the Windows NT kernel to remove all effective security (allow any user to kill or modify processes, even the null user). Chris Anley talks about patching Microsoft SQL Server in The Shellcoder's Handbook (Chapter 20, Alternative Payload Strategies pg. 477-479). Let's take a look at this in detail, because it is very cool.

Applications typically log in to a sql server with limited rights. The concept of this patch is to make it so that every user has the rights of dbo (DataBase Owner, UID 1) which can access and modify all tables . If you play with sqlservr.exe, you will find a function FHasObjPermissions. This function gets the current UID, checks to see if it is set to 1, and then raises an exception if not. Let's look at a dissasembly of this function:

004262BB E894D7FEFF call ExecutionContext::Uid (00413a54)
004262C0 663D0100 cmp ax,offset FHasObjPermissions+0B7h (004262c2)
004262C4 0F85AC0C1F00 jne FHasObjPermissions+0C7h (00616f76)

The first instruction (004262BB) calls a function (ExecutionContext::Uid) gets the current UID of the user. The second (004262C0) checks to see if the current UID is 1. The final instruction in this snippet jumps to another location if the UID is not 1. So, in order to unpatch SQL Server, we need to have the call to ExectutionContext::Uid always return 1, no matter what the true UID is. Let's take a look at the last three instructions in the disassembly of that function:

00413A97 668B4002 mov ax,word ptr [eax+2]
00413A9B 5E pop esi
00413A9C C3 ret

What we have here is the value stored in the AX register equaling the current UID when the function returns. After FHasObjPermissions calls ExectutionContext::Uid, it immediately does a comparision to see if the UID is 1. So, all we need to do to accomplish our goal is to replace the instruction at 00413A97 with a mov ax, 1. But, if we subtract from the number of instructions in the program, all of the jumps will be misaligned and the sqlservr will never run. So, we will need to change the instruction to set AX to 1 with an equal number (4) of bytes. This can be accomplished by moving the value stored at an offset known to be 1 into AX. We can do this all with a single instruction that copies a value stored in the instruction itself:

00413A97 66 B8 01 00 mov ax,offset ExecutionContext::Uid+85h (00413a99)

The value at 00413a99 is 01 (the third byte in this instruction). Now, to make this change, go and download Hiew. Open up sqlservr.exe (when SQL Server is not running), and search (F5) for the address .413a97. Do an edit at this address (F3), and replace 66 8B 40 02 with 66 BB 01 00. Save your changes, exit Hiew and re-run SQL Server. Log in as any user and attempt to view the contents of a table only readable by dbo (sysusers), and you will now be able to!

Other ideas for unpatching is to introduce a vulnerability into a program, instead of the outbound network connection as we saw with the OpenSSH and Sendmail trojans. Replace a strncpy with strcpy that copies input from recieved from the network. This newly introduced vulnerability is unique to the affected system, and could lie undetected for a long period of time. You can think of the new unpatch vulnerability as a special API known only to you.

So, I know a lot of you will say that this 3 byte unpatch will result in a different MD5 hash, so when tripwire is run against the sqlservr.exe binary, the sly admin will find we have made modifications. This is no doubt true. But if you have admin access to the box, you can always update tripwire hashes if the system stores them locally. Another technique to thwart against this is to research the application in question, and replace the binary with a previously vulnerable version instead of introducing your own. Windows will report the binary as current and fully patched, and the binary will now match a old or "known good" hash. This may cause the admin to ignore the hash mismatch (there are so many false positives with tripwire as is).

Comments, suggestions?

~Jack
jack (at) infosecinstitute (dot) com