Blogs

Anatomy of a WINS server hack (MS04-045) . . .

Okay - so here is my analysis of a recent WINS hack a customer experienced. The customer caught this by analyzing their netflow data from their routers . . . they suddenly started sending tremendous amounts of packet love and affection to various IP's around the Internet and they traced the packets to a Windows box on their network and thus the IR process was kicked into full swing.

They immediately pulled the plug, ran WOLF and started analyzing the data. As you will see these miscreants leave behind some tells that indicate that they are slightly more skilled than the miscreants from the previous blog post who went up against Windows File Protection . . . and lost.

As with most IR cases we don't have direct, objective first-hand knowledge of how the compromise occurred - all we can do is piece together the puzzle based on the evidence at hand and make a subjective assumption about what we think probably happened. Sometimes it's a no brainer and you see something like XP_CMDSHELL being run in the event logs and the customer tells us they have a blank SA password and no firewall - other times we have to do some educating guessing. :) We rely heavily on Occam's Razor and find it to hold true most of the time.

Okay - with this case I was lucky in that this customer was more sophisticated than most and the customer was able to give me some 'leads' in the form of a process name and a date and time that the gratuitous love and packet affection occured on their network. When you don't see anything suspicious in the volatile data on a machine (i.e. running processes / suspicious network connections) its very important to have a lead in the form of a date or time to go on usually - otherwise you're just looking for a needle in a hay stack.

Using WOLF Hound (our trusty IR data viewer) I told it to show me everything that happened on the file system and in the event logs on the 9th.

First we see some unusual events logged from the WINS service on this machine (a Windows 2000 SP4 machine b.t.w. - you will see me blog very little about WS2003 servers . . . I wonder why that is?).

After the suspicious WINS event log entries we that FTP.EXE gets run (last access time) and it looks like it was run (probably) to pull down a file called przsvc.exe.

Using FTP to suck stuff down to the box . . . well that's hardly interesting, that's been demo'd in hacking books and hacking classes for years . . . 'that's soooo last century'. What's interesting about this crew is that they also seem to have the ability to download files via HTTP (probably by calling WININET API's) just in case you're doing some egress filtering and don't allow outbound FTP. We've seen this done via scripting combined with ADODB.Stream to persist the fetched data before and it's not really hard to write a compiled program to do the same thing and run it as SYSTEM if you know what API's to call. Could this be new functionality of this particular BOT variant (spoolsrv.exe is an SDBot variant b.t.w.).

You may notice below that the 'Default User' profile's TIF (Temporary Internet Files) folder is being written around 16:52 . . . it turns out you can repro this yourself - fire up a copy of Internet Explorer running as the SYSTEM account (left as an exercise to the reader) and download some files - observe where they go. That's right, they go into the 'Default User' profile. So now it seems we have evidence that someone was running something on the box (SDBot) with elevated privileges and downloading files via IE (less likely) or by calling the same API's IE calls (more likely).

This is a little more sophisticated than usual - but it's not a new technique - we've seen this used on occasion in the past but usually from vbscripts wrapped inside of .CHM files that were downloaded and run via Internet Explorer 0-days.

So what I found interesting about this batch file is that it's like a crude dead mans switch. Delete whatever I pass in on the command line and then delete myself when done - nice. So say I start a server process and its running and then I call this batch file with the path to the server process as the first parameter. If the file is in use, the delete operation will fail and this batch file will simpy loop until the process is ended (assuming a process or a DLL is what is being passed in to the batch file as %1) and the file can finally be deleted. Finally - when the filename I pass in to the batch file as %1 does finally manage to get deleted - the batch file will delete itself . . . since it was still there - it doesn't look like it was ever called.

After this series of events - all was quiet on this server until a few days later when all we see is the previously downloaded malware that was placed in the IE TIF folder get accessed (although this looks to have been due to an incremental backup of the file system by some backup network backup software according to the event log):

What's interesting is the way in which this malware (have not received a specimen yet) was loading - it was using a lesser known autostart technique that has been used in the past by things like Beast and Sub7.

So to conclude, I have a theory based on suspicious WINS related event log entries that this box was comrpomised using a WINS remote shell exploit. Fortunately we have a tool that allows me to get the patch-level of a machine during the data collection phase - MBSA. MBSA was able to show me what I needed to see:

Copied from: mbsacli_patch_status.txt========================== Patch NOT Found MS04-041 885836 A required registry key does not exist. It is necessary in order for this patch to be considered installed. [SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\KB885836\Installed]

Patch NOT Found MS04-043 873339 File version is less than expected. [C:\WINNT\system32\hypertrm.dll, 5.0.2195.6684 < 5.0.2195.7000]

Patch NOT Found MS04-044 885835 File version is less than expected. [C:\WINNT\system32\lsasrv.dll, 5.0.2195.6902 < 5.0.2195.6987]

Patch NOT Found MS04-045 870763 File version is less than expected. [C:\WINNT\system32\wins.exe, 5.0.2195.6870 < 5.0.2195.7005]

This box is at severe risk as it is missing multiple security updates that are remotely exploitable including SQL updates! Worse still - the box only has a 6 character minimum password policy and the passwords never expire!

Given that this box was not behind a firewall it's only a matter of time before the admin password is guessed and/or another remotely exploitable vulnerability is used to take control of this machine.

Our advice to this customer is to follow standard best practices for internet facing boxes as documented in all of our Windows 2000 hardening guides which can be found at http://www.microsoft.com/security/guidance

At the very least they need to immediately consider:

Increasing the strength of their password policy (I recommend 10 character or more minimums and educate people about the use of pass-phrases)

Set a password expiration of no more than 70 days

Shut down un-needed servcies (this box was running everything and then some)

Install all critical security updates for both the OS and the server applications within 24 hours (even more critical since this box is plugged directly into the Internet with an Internet routable IP) or better yet turn on Automatic Updates or consider using SUS etc.

For the love of God use a firewall to screen inbound access to some of those high profile ports!

On the plus side this customer DID have account logon auditing enabled on this server and I can confirm that no Windows accounts were harmed in taking over of this server (this time).

> Post-it notes stuck to every monitor.
> Slips of paper under every keyboard.
> That's more secure?

Yes. Abuse will be done by insiders, not by every random scanner coming in over the internet.

Sergey Simakov

28 Jan 2005 10:50 AM

Norman: yes, but current trends in system security breaks is increasing numbers of insiders

Nektar

28 Jan 2005 10:52 AM

So WUS and Microsoft Update website are coming this year. Very good.
Actually I believe that Windows Update Services WUS is a bad name that will cause confusion. There is already the Windows Update website that updates only Windows. So customers will wrongly think that WUS is only for updating Windows. In any case the unified updating service will be called Microsoft Update so why not call WUS Microsoft Update Service or just leave the old Software Update Services name? This will not make people think that WUS is only for Windows.
I guess though in the end Microsoft Update website will be available in 2006 and not this year since there is no beta yet so it seems that its release date might slip again.

Bob Dietz

28 Jan 2005 6:05 PM

You've mentioned WOLF in several of your reports. Is WOLF -

* Available for download?
* A product currently offered for sale?
* A product in development?
* An in-house tool that is only available to members of your IR team?
*

Robert Hensing

28 Jan 2005 6:19 PM

It's the last one - sorry, not available for download or public consumption in any way. Its a support tool used by our IR team.