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

Secret Service hacker, how did he do it?

Nick Jacobsen pleaded guilty today to hacking into T-Mobile, specifically for violating 18 U.S.C. § 1030(a)(2)(C), accessing a computer without authorization. It looks like Nick was part of the carding community that has been recently attracting a lot of attention from the US Secret Service (little known, but the Secret Service have jurisdiction over counterfeiting crimes). Carders have gotten bold in the last couple of years, opening online exchanges (muzzfuzz.com, shadowcrew.org) for trading stolen credit cards, selling data used for identity theft, etc. When I first heard of this incident a few months ago, I was very interested on how he actually did it. There was very little information on how the attack was performed, and I decided to a little bit of research to see what I could find.

A summarization of affidavit, is that Nick was already under investigation by the Secret Service, hacked into T-Mobile, where was able to access accounts including those of agents in the Secret Service that were investigating him for other activities. He found that they had been monitoring his conversations over ICQ, (Nick's ICQ # was 23292256). Nick also discovered a number of Secret Service documents that an Agent, Peter Cavicchia, had left in his inbox unencrypted. Nick posted on muzzfuzz that he was selling T-Mobile account information, offering:

reverse lookup of information for a tmobile cell phone, by phone number at the very least, you get name, ssn, and DOB at the upper end of the information returned, you get web username/password, voicemail password, secret question/answer, sim#, IMEI#, and more.

Also of interest, he went on to access Paris Hilton's account and capture some of the pictures she had been taking with her camera. Now, here is where it gets interesting. How did Nick get into T-Mobile? Did he use an IIS exploit? Did he hack the web interface for T-Mobile accounts?

The affidavit from Nick's case states that he was observed logging into a specific server, http://login.sidekick.dngr.com, with Agent Peter Cavicchi's account information. While this site itself is hosted by Danger, Inc., the makers of the Sidekick device used by Agent Cavicchi, it appears that the same username/passwords that are used on the primary T-Mobile login page, https://my.t-mobile.com/Login, can also be used to log into this page. We also get some very valuable information from the affidavit, that will help us narrow down how Nick hacked these accounts (the CI is a Confidential Information, who was working with the Secret Service to bring Nick in, ethics is the semi-ironic pseudonym Nick chose for himself):

On or about October 19, 2004, Ethics sent a private message to the CI which contained a link that provides unauthorized access to the T-Mobile database. This link allows a user to input a phone number ultimately allowing access to the user’s personal information.

This information leads me to believe it was likely a web application attack, not a "traditional" buffer overflow attack against a server storing account information. Although it is possible to peform a buffer overflow against a program by passing input through a web app, we can also read Nick's resume on SecurityFocus, and see that he doesn't seem to have enough experience in that area. Unless he picked up a copy of The Shellcoder's Handbook last year. ;)

To further corraborate that Nick used a web application hack, most likely SQL Injection (a little research shows that the T-Mobile site uses IIS/ASP/SQL Server, which happens to be the easiest and most well documented platform for SQL Injection attacks), we can check out the website and try to put some invalid input into the T-Mobile login page. I was very surprised with the results, we can still put all sorts of crazy input into the login page! It is still vulnerable, even after one of the largest, most well known, and high profile hacks in the last couple of years! Let's try some (notice the error text on the resulting T-Mobile webpage):

https://my.t-mobile.com/Login/?rc=I%20like%20to%20eat%20cheese

Result:



https://my.t-mobile.com/Login/?rc=T-Mobile%20is%20not%20very%20secure,%20please%20use%20Nextel%20instead!

Result:



While this is a very, very lame bug, it could be used in a phishing attack on T-Mobile customers, especially if you hex encoded portions of the URL. We also find a little more serious bug here, we can inject script tags as well, which could possibly be exploitable and used to steal cookies and therefore circumvent authentication. The resulting HTTP 500 error lets us know that something is wrong with the site, causing a server error. (I have not taken the attack any further, and I would not recommend that you do so either):

http://my.t-mobile.com/Login/?rc=~script~alert('vulnerable')~script~

In order for this demo to work, you must replace the four ~ with a <>.

Result:



We can also find literally hundreds of injection vulnerabilties littered throughout the T-Mobile website. They seemed to have cleansed out all of the obvious injection holes accessible via browser input, but if you use a simple web proxy (I like Paros, we use it in both Ethical Hacking classes at InfoSec), you can find them by the hundreds on just about every dynamic page on the website! Here is one (once again, do not attempt to exploit this):

http://support.t-mobile.com/plan.html?treeName=plans&path='

Result:



Based on the affidavit, plus the fact that T-Mobile remains highly vulnerable to all sorts of web input attacks, I would say it is highly likely that Nick used some sort of web application bug to circumvent authentication.

~Jack
jack (at) infosecinstitute (dot) com

First Post

So, this is the first post in my blog. I feel it is only appropriate for me to talk about why I am doing this, what my intentions are, and my opinion on blogs in general.

I must be totally honest and confess to have never actually explicitly or intentionally viewed any persons blog. I may have landed on a few here and there searching for particular things on the internet, but I would have to say I would never regularly visit a blog to better inform myself about current events, security, or anything else I have an interest in. I guess I just don't trust them. All of this talk about the "blogosphere" (Am I the only one that thinks that is the silliest media-contrived slang term ever created?) replacing traditional media, I just don't buy into bloggers having the same journalistic integrity as, say, a journalist from The Wall Street Journal, The Washington Post, or even SecurityFocus. I don't think they ever will either, but I could see some exceptional bloggers being hired by a traditional media outlet. So, why am I doing this?

Well, two reasons, the first is that I am lucky enough to be relatively plugged-in to the information security/ethical hacking industry. I am also lucky in that I get to regularly teach hacking classes for InfoSec Institute, and students are always asking me for additional resources after the class. So this blog will serve as a place to find these resources if you are a previous student, or are simply looking for some interesting security information on the web.

The second reason is much more self-interested (selfish?). The marketing manager here at InfoSec has asked me to do this, as our website was hit by a recent google update (called Allegra, read more here if you care). It is high time we started adding original content to our web presence, so this is a good opportunity. I have also written two books, and consider myself to have average to above-average writing skills. I would like to improve my writing skills, and a blog looks like a good place to practice without having nasty editors hanging over my head. So here it is. Please leave comments, and if you like what you see, please link to this website.

~Jack

Testing

Lets see if this thing works.