Word Zero-Day, So Sayeth Microsoft

Published: 2006-12-05. Last Updated: 2006-12-05 23:05:27 UTC
by Ed Skoudis (Version: 1)
0 comment(s)
Microsoft released an announcement of a zero-day vulnerability in Microsoft Word.   Read about it here.

Of particular interest, they say:

"Microsoft is investigating new public reports of limited 'zero-day' attacks using a vulnerability in Microsoft Word 2000, Microsoft Word 2002, Microsoft Office Word 2003, Microsoft Word Viewer 2003, Microsoft Word 2004 for Mac, and Microsoft Word 2004 v. X for Mac, as well as Microsoft Works 2004, 2005, and 2006.  In order for this attack to be carried out, a user must first open a malicious Word file attached to an e-mail or otherwise provided to them by an attacker."

Microsoft's advice?  They say, "Do not open or save Word files that you receive from un-trusted sources or that you receive unexpectedly from trusted sources. This vulnerability could be exploited when a user opens a specially crafted Word file."

Ok... sure.  Thanks.

--Ed Skoudis
Intelguardians.
Keywords:
0 comment(s)

IBM Tivoli Storage Manager Buffer Overflow Vulns and Patches

Published: 2006-12-05. Last Updated: 2006-12-05 16:28:18 UTC
by Ed Skoudis (Version: 1)
0 comment(s)
Looks like IBM Tivoli Storage Manager has a few buffer overflow vulnerabilities.  Read more about them here, courtesy of Tipping Point.

The money quote:

"These vulnerabilities allow attackers to execute arbitrary code on vulnerable installations of IBM Tivoli Storage Manager. Authentication is not required to exploit these vulnerabilities.  The specific flaws are similar and exist in the processing of messages by the Tivoli Storage Manager service, bound on TCP port 1500. "

Patches from IBM described here.

Looks like IBM thinks they cannot be exploited, as they say, "This problem relates to an internal buffer overflow in TSM but IBM does not believe it is possible to exploit this buffer overflow for remote code execution, however, this exposure can be used to crash the TSM server."

Either way... if you use Tivoli, you should analyze this carefully.





Keywords:
0 comment(s)

Fun With Windows Netstat

Published: 2006-12-05. Last Updated: 2006-12-05 15:25:10 UTC
by Ed Skoudis (Version: 3)
0 comment(s)
I've often lamented the fact that Windows does not have a built-in lsof-like tool.  On Linux and UNIX, lsof gives all kinds of details about what various processes are up to.  Sure, we've got the Microsoft Sysinternals Process Monitor tool, which is really cool, but is not built in.  And, of course, Windows doesn't include a built-in sniffer?

One technique that I've been using a lot in incident handling, vulnerability assessment, malware analysis, and other sysadmin work over the last few months involves the traditional, humble netstat tool.  Although netstat is limited, I've found a specific use of it to be tremendously helpful.  Here are some scenarios.

Fellow handler Mike Poor and I were at a client site, and Mike was doing a network scan.  I had one of the client's laptops, on which we could install no additional software.  I wanted to see when Mikey's wide-ranging scan reached my box, which did have an open port.  Here's what I ran:

C:\> netstat ?na 1 | find "[Scan_Host_IP_Addr]"

The netstat command, used this way, shows TCP and UDP port activity.  The ?n means to list numbers.  The ?a indicates that we want all connections and listening ports.  In Windows netstat, the 1 means we want to run every second, repeatedly dumping the output on standard out.  That's a really nice feature of Windows netstat, because we can have it run continuously (every second) and scrape its output for what we want.  And, here we are looking through our output with the find command to see an indication of when Mike's box had accessed ours.  Note that I'm using find here, but another alternative would be the findstr command.  The find command can locate strings nicely, but findstr can process regular expressions.  I believe in using the appropriate tool for the job, and these simple searches work just fine with find.  If you want regexp stuff, use the more powerful findstr command.  Anyway, because the 3-way handshake or an actual connection will likely last more than 1 second, this technique will work.  Sadly, the technique does not work to capture sub-1-second events.  As Mikey continued the scan? Bingo!  We could see with 1-second accuracy when it reached my box.

I've used this technique elsewhere as well.  A gentleman taking the SANS Security 504 class had a dilemma.  He was seeing a weird ICMP Host Unreachable message in his network.  When he looked at the destination address, it was going from his router back to his Domain Controller.  So, his DC was pushing out a packet to a machine that his router couldn't reach.  But, what process on his DC was sending this packet?  On the Domain Controller, we ran:

C:\> netstat ?nao 1 | find "[Dest_IP_Addr]"

Here, I've added the ?o flag, which makes Windows netstat print the PID.  You can then look up that PID using "wmic process list brief", "tasklist", or, if you insist, Task Manager (yuck!).  Then, you can see what process is emitting that packet, provided that it is using the TCP or UDP stack of Windows to send it, and that it takes at least a second.  Note that netstat also offers the ?b flag, which makes it show the EXE and its associated DLLs that are using TCP and UDP ports.  However, I didn't use ?b here, because it seriously hurts performance.  For whatever reason, it takes netstat a lot of CPU cycles to get the EXE and DLL info, cycles that we cannot spare on a Domain Controller.  And, running "netstat ?naob" every second would be a serious drain on processor resources.

Sadly, the -o and -b options in netstat are not available in Windows NT and 2000.  As far as I'm concerned, those older Windows are barely manageable at all.  WinXP and 2003 are much better, and netstat supports -o and -b in them, to say nothing of wmic, tasklist, taskkill, etc.

Here's another one.  We were working on an investigation where an evil process would start up, and eventually (not instantly) listen on TCP port 2222.  We wanted to know when it started listening, so we ran:

C:\> netstat ?na 1 | find "2222"

And, here's one final one for you.  I was working on an investigation, and we had a process listening on a given TCP port (let's say, for example, it was TCP port 4444).  We wanted to know when the bad guy connected to it.  We ran:

C:\> netstat ?na 1 | find "4444" | find "ESTABLISHED"

This will print nothing until the output of netstat includes an established connection on port 4444.  So, with approximately 1-second accuracy, we were able to see when someone connected to the port, knowing that our bad guy had come calling.  Also, this output includes the source IP address connected to the port, a helpful thing in an investigation.

Now, obviously you could do all of this with a sniffer, with more accuracy and detail.  But, netstat is built-in, and these command are easy and quick to type.

--Ed Skoudis.
Handler on Duty
Intelguardians

Keywords:
0 comment(s)

New Hacker Challenge

Published: 2006-12-05. Last Updated: 2006-12-05 14:38:04 UTC
by Ed Skoudis (Version: 2)
0 comment(s)
Hey, challenge fans!  If you like Windows, Linux, netcat, chimneys, ciphertext, and so on, I've posted a Christmas-themed hacker challenge.  You remember the movie, A Christmas Story... with the Messy Marvin kid, the interesting lamp, and the Red Rider Beebee gun.  That's the theme, but adapted to a hacking scenario.  If you enter by December 22, you are eligible to win a prize.

--Ed Skoudis
Intelguardians
Keywords:
0 comment(s)

Comments


Diary Archives