thatsBroken

Let me start out by saying that ESX and ESXi both have the ability to allow management from a defined IP address or IP mask.  In addition, they both allow you to set a management interface and bind the management interface to only allow connections from an administrative subnet.  This is just security best practice and in this case, following best practice will mitigate much of the risk involved in this ‘Information Leakage’ issue.

Both ESX and ESXi have a web based management interface that can be used to browse the data store and download the vShpere (thick) client for managing the ESX/ESXi host.  This management interface seems a little dangerous to me in that exposes a massive web service (vim.wsdl) and at lest a portion can queried successfully without authentication.

The webservice endpoint is at https://esx-server-ip/sdk

The web service is configured to point to /usr/lib/vmware/hostd/docroot if you want to go snooping yourself.

I do vulnerability research and write code to detect remotely vulnerable hosts on a network.  Some of the best remote detection rules I’ve written depend on very obscure ‘information disclosure’ vulnerabilities.

Web apps there are all kinds of tricks to finding the exact build of an app by generating diffs of publicly accessible supporting java-script files.  Another trick is to enumerate all of the calls you can  make to a web service as an unauthenticated user and then start parsing the responses.  You’ll start to develop a fuzzy finger print that will generate ranges of possible versions.

This blog posting isn’t about any of these neat techniques.  This blog post is about sending a single specific post to the vmware sdk running on the management interface with no authentication or cookie trickery.

The following post request will generate an xml response that be parsed to identify the ESX version right down to the build level.  The build level is increased on every major update which provides exceptional granularity to patch detection.

POST /sdk HTTP/1.1\r\nContent-Type: text/xml; charset=\”utf-8\”\r\nSOAPAction: \”urn:internalvim25/4.0\”\r\nContent-Length: 410\r\n\r\n<soap:Envelope xmlns:xsd=\”http://www.w3.org/2001/XMLSchema\” xmlns:xsi=\”http://www.w3.org/2001/XMLSchema-instance\” xmlns:soap=\”http://schemas.xmlsoap.org/soap/envelope/\”>\r\n  <soap:Body>\r\n    <RetrieveServiceContent xmlns=\”urn:internalvim25\”>\r\n      <_this xsi:type=\”ServiceInstance\” type=\”ServiceInstance\” serverGuid=\”\”>ServiceInstance</_this>\r\n    </RetrieveServiceContent>\r\n  </soap:Body>\r\n</soap:Envelope>\r\n\r\n\r\n

What does the response look like?

Well you get a whole bunch of XML but the interesting bit is here:

<RetrieveServiceContentResponse xmlns=”urn:internalvim25″><returnval><rootFolder type=”Folder”>ha-folder-root</rootFolder><propertyCollector type=”PropertyCollector”>ha-property-collector</propertyCollector><viewManager type=”ViewManager”>ViewManager</viewManager><about><name>VMware ESX</name><fullName>VMware ESX 4.0.0 build-164009</fullName><vendor>VMware, Inc.</vendor><version>4.0.0</version><build>164009</build><localeVersion>INTL</localeVersion><localeBuild>000</localeBuild><osType>vmnix-x86</osType><p

So my question to you:  Is this a ‘vulnerability’ vmware needs to fix or just some undocumented feature that doesn’t really need to be fixed?  The build number matches directly to patches that increment the build when applied…

I’m writing up a proper post about reverse engineering your target to properly identify snapshot and restore points but I had to quickly share something I found in the binary:

In memory fuzzing is a form off process instrumentation that allows the analyst to bypass parsers, network limitations, encryption and data marshaling steps to deal directly with a functions inputs and test its integrity.

The upsides:

• It’s faster to get to your target function than creating mini-clients or modifying file formats (or generating 1.5 TB worth…)
• Once you’re up and running the process fuzz cases happen much faster and it’s easier to distribute fuzz space to multiple VMs
• It’s a lot more fun

The down sides:

• Found a bug? No you didn’t… yes you did… did you?  Now that you found your bug you need to get to that section of the code… did you fuzz with the proper bounds?
• There is a bit of a learning curve and not a lot of help out there.  This has been done in an ad-hoc manner for a few years but there are no real tools to get the job done simply.

So how exactly do we accomplish in memory fuzzing?  If you’ve been following along with the other posts you know I’m in love with pydbg and the PaiMei framework.  I want to continue to use this

framework but it should be noted that Dion Blazakis just had a fairly good shmoocon talk on BaSO4: A Dynamic Dataflow Analysis Tool for Auditing and Reversing and, from what I can tell, it can and should be used in tandum with in memory fuzzing. He has done work on analyzing the dependancies of call graph flow which would be useful in building a more intelligent in memory fuzzer. In anycase, he hasn’t released any code but its an IDA plugin which means it will be trivial to export the data using IDA Pro’s -A, -B and -S flags.

(Automatic disasm and creating of IDB / ASM files, Batch Mode with a a modified PIDA_dump.py to launch automatically, -S or script mode to define an IDC script that can be used to launch an IDAPython script to export more info… I’ll go over all of this in another post if anyone is interested)

…getting back to in-memory fuzzing, the basic steps are:

Initalize the debugger variables (DONE)
Attach to process (DONE)
Set your hooks (DONE)
When the entry point is hit time save memory state and continue (DONE)

Monitor process for memory access of function arguements, save address (IN PROGRESS)
When the exit point is reached revert to saved_state (DONE)
Allocate a space for our fuzz string or buffer with pydbg.virtual_alloc() (DONE)
Modify the functions argument pointers to our fuzz data (IN PROGRESS)
Monitor for stack integrity (IN PROGRESS)

Haz a nice cold coke. (IN PROGRESS)

There is much more to it than this of course.. but that’s the basic idea that I get…. here is a video of steps 1-4, step five is a whole new ball game so stay tuned. (Code is available at the end of the post).

The source code to the start of the in-memory fuzzer:

#!/usr/bin/env python

from pydbg import *
from pydbg.defines import *

import time
import random

snapshot_hook 	= 0x0040FBE8
restore_hook 	= 0x0040FBEB
snapshot_taken 	= False
hit_count		= 0
address			= 0

def set_entry(pydbg):
	return 1

def handle_bp(pydbg):
	global snapshot_hook, restore_hook
	global snapshot_taken, hit_count, address

	if pydbg.first_breakpoint:
		return DBG_CONTINUE

	print "ws2_32.recv() called from thread %d @%08x" % (pydbg.dbg.dwThreadId, pydbg.exception_address)

	context_dump = dbg.dump_context(stack_depth=4, print_dots=False)

	print context_dump

	if pydbg.exception_address == snapshot_hook:
		hit_count += 1
		print "hit the snapshot address"
		start = time.time()
		print "taking snapshot..."
		pydbg.process_snapshot()
		end = time.time() - start
		print "snapshot took: %.03f seconds\n" % end
		if hit_count >= 1:
			if address:
				print "freeing last chunk"
				print "%08x" % address
				pydbg.virtual_free(address, 1000, MEM_DECOMMIT)
		print "allocating memory for mutated data"
		address = pydbg.virtual_alloc( None, 1000, MEM_COMMIT, PAGE_READWRITE)
		print "Allocated 1000 bytes at: %08x" % address		

	return DBG_CONTINUE

def handle_av (pydbg, dbg, context):
    '''
    As we are mucking around with process state and calling potentially unknown subroutines, it is likely that we may
    cause an access violation. We register this handler to provide some useful information about the cause.
    '''

    crash_bin = utils.crash_binning.crash_binning()
    crash_bin.record_crash(dbg)

    print crash_bin.crash_synopsis()
    dbg.terminate_process()

dbg = pydbg()
dbg.set_callback(EXCEPTION_BREAKPOINT,handle_bp)
dbg.set_callback(EXCEPTION_ACCESS_VIOLATION, handle_av)

found_target = False

for (pid, proc_name) in dbg.enumerate_processes():
	#print proc_name.lower()
	if proc_name.lower() == "applemobiledeviceservice.exe":
		found_target = True
		print "[+] Found Target:\"%s" %proc_name.lower()
		break

if found_target:
	dbg.attach(pid)
	print "[+] Attached to :" + str(pid)
	dbg.bp_set(snapshot_hook)
	dbg.bp_set(restore_hook)
	print "[+] Hooks set, entering debug loop..."
	dbg.debug_event_loop()
else:
	print "Target not found\n"

You don’t get this often… the advisory released by the vulnerability researcher includes a ton of PoC code that can be used to, among other things, detect the MS10-012 patch without authentication.

The script connects to a target over TCP 445 and sends it a negotiation request.  The response is parsed for the 8byte challenge token and stored.  After approximately 2000 request we get our first duplicate challenge token.

At the end of a 5 minute test run my results were:

Challenges: 49,328
Duplicates: 198

… um, wow. (10.7.0.122 = PATCHED and 10.7.0.140 = UNPATCHED)

I notice that anyone with a computer that has itunes + iphone gets a nifty little service called AppleMobileDeviceService.exe. I also noticed that it listens on a TCP port and it runs as SYSTEM.

Before anyone gets super excited, I’m not going to drop a 0day in this post. I’m simply going to show you the process/menthod I used to listen to the network chatter…

I used my modified version of PAIMEIPeek.py to trace all calls to send() and recv(). I added context dumping as well so that I can see what registers hold the content that I sent. This is going to be used later to get/set the pointer to the buffer recv() fills.

Here is a video of the recv() and send() hooks doing their thing:

* NOTE: Switch to full screen for best resolution.  I have no idea what this will look like scaled

The vulnerability researcher responsible for part of MS10-012, Hernan Ochoa, from Hexale / Core Security and author of UHooker will be releasing an advisory on the Weak NTLM Entropy. I am hoping his post goes into detail and he provides some kind of proof of conecpt. Keep an eye on thatsBroken for a breakdown and review of this vulnerability…

Using TurboDiff 1.0.1b2 from core I am doing a binary diff of srvsys between MS09-001 and MS10-012

The file size has grown by almost 20k so we can expect to see some signifigant change. Thankfully TurboDiff does a great job of matching functions… lets take a look:

————————————————————-
matched functions: 14
[.] 000267f3 sub_267F3                                        – 00022df3 sub_22DF3
[.] 00027b74 sub_27B74                                        – 00024174 sub_24174
[.] 00028cd7 sub_28CD7                                        – 000252d7 sub_252D7
[.] 0002ad05 sub_2AD05                                        – 00027305 sub_27305
[.] 0002bbe8 sub_2BBE8                                        – 000281df sub_281DF
[.] 0002c4c3 sub_2C4C3                                        – 00028abb sub_28ABB
[.] 0002c9a7 sub_2C9A7                                        – 00028f9f sub_28F9F
[.] 0003aee7 sub_3AEE7                                        – 000374cf sub_374CF
[.] 0003c099 sub_3C099                                        – 00038681 sub_38681
[.] 0003e3a5 sub_3E3A5                                        – 0003a81b sub_3A81B
[.] 00045a7b sub_45A7B                                        – 00041f39 sub_41F39
[.] 0004c063 sub_4C063                                        – 00048519 sub_48519
[.] 00050033 sub_50033                                        – 0004c4fd sub_4C4FD
[.] 000520bd sub_520BD                                        – 0004e597 sub_4E597
————————————————————-
unmatched functions1: 53
00013052 sub_13052
0001319f sub_1319F
00013902 sub_13902
00014459 sub_14459
000156f8 sub_156F8
0001623d sub_1623D
0001dabb sub_1DABB
000207d1 sub_207D1
00020831 sub_20831
00020886 PsGetCurrentThreadId
00020891 PsGetCurrentProcessId
00020aab sub_20AAB
00020b8e sub_20B8E
00020cb3 sub_20CB3
00020d69 sub_20D69
00020e33 sub_20E33
00020ee4 sub_20EE4
00020f18 sub_20F18
00021055 sub_21055
000210f6 sub_210F6
000442a9 sub_442A9
0005c7a8 sub_5C7A8
0005c7ea sub_5C7EA
0005c805 sub_5C805
0005cc5d sub_5CC5D
0005cd7b sub_5CD7B
0005cdbd sub_5CDBD
0005ce42 sub_5CE42
0005cea4 sub_5CEA4
0005cedf sub_5CEDF
0005cf13 sub_5CF13
0005d059 sub_5D059
0005d0bc sub_5D0BC
0005d180 sub_5D180
0005d1fa sub_5D1FA
0005d22d sub_5D22D
0005d280 sub_5D280
0005d2d1 sub_5D2D1
0005d338 sub_5D338
0005d375 sub_5D375
0005d686 sub_5D686
0005d6b2 sub_5D6B2
0005d6ff sub_5D6FF
0005d749 sub_5D749
0005d7ed sub_5D7ED
0005d7f6 sub_5D7F6
0005d822 sub_5D822
0005d82b sub_5D82B
0005d851 sub_5D851
0005d85a sub_5D85A
0005d87f sub_5D87F
0005d888 sub_5D888
0005d8a7 sub_5D8A7
————————————————————-
unmatched functions2: 1
0004071f sub_4071F
————————————————————-
changed functions: 5
[.] 0002b782 sub_2B782                                        – [.] 00027d82 sub_27D82
[.] 0003cbc9 sub_3CBC9                                        – [.] 000391b1 sub_391B1
[.] 0003d0f3 sub_3D0F3                                        – [.] 000396cf sub_396CF
[.] 0003d7d3 sub_3D7D3                                        – [.] 00039ccf sub_39CCF
[.] 0004f9c9 sub_4F9C9                                        – [.] 0004be7f sub_4BE7F
————————————————————-
————————————————————-

I am working on narrowing down the NTLM Entropy changes in hopes that I can create an unauthenticated remote check.  The rest of the bugs in MS10-012 require authentication and appear to be cause by improperly parsing unicode file names strings with wildcards…

Of course there are were a ton of matched functions between the two files, I’ve included the:

14 Matched Functions ~ These are functions that have probably changed

53 unmatched functions ~ These are new functions in the updated srv.sys

5 changed functions ~ The number of basic blocks in this function has changed suggesting a significant change.

Here is what the TurboDiff results window looks like:

Choosing a function will bring up two function call graphs.  We’re most concerend about red blocks but don’t let the tricker bugs to spot slip past!

Here is a side by side shot showing the changed code:

When we take a closer look at this code however we can see its a false positive:

Hey all, I’m working on fuzzing an Apple service and I needed PAIMEIPeek to track send() as well as recv()… since recv() function tracing is already in PAIMEIpeek.py adding support for send() was pretty damn simple.

update:

paimei/console/modules/PAIMEIpeek.py
and
paimei/console/modules/_PAIMEIpeek/PeekOptionsDlg.py

The new options window:

I’ll continue fuzzing this project using a more advanced technique called “In Memory Fuzzing”.

Using functionality supported by pydbg I’ll be setting a pydbg.process_snapshot() on the recv hook and then a pydbg.virtual_alloc(). This will allow me to create space and import my munged XML into the process space using pydbg.write_process_memory(address, mungedxml)

Then, after the munged xml is in memory I’ll change context.esp+4 pointer to mungedxml… restore the hook… and use pydbg’s built in memory/stack corruption detection to look for faults.

What I’d like to start working on is a gui to setup hooks on functions, parse the input and replace them with sulley strings… I haven’t seen a good set of tools to do in memory fuzzing and PaiMei seems to be the perfect platform — any takers?

The versions of proc_peek_recon.py and proc_peek_recon_db.py are slightly broken.

They both suffer from the same problem. Simply change:

for xref in CodeRefsTo(location, True) + DataRefsTo(location):

To this:

for xref in list(CodeRefsTo(location, True)) + list(DataRefsTo(location)):

This will convert the generators that are returned by CodeRefsTo and DataRefsTo into lists that can be combined and iterated through.

Failure to do this will result in the following error:

Traceback (most recent call last):
File ““, line 1, in
File “C:\Program Files\IDA\python\init.py”, line 65, in runscript
execfile(script, g)
File “C:/paimei/proc_peek_recon_db.py”, line 357, in
main()
File “C:/paimei/proc_peek_recon_db.py”, line 354, in main
meat_and_potatoes(mysql)
File “C:/paimei/proc_peek_recon_db.py”, line 253, in meat_and_potatoes
for xref in CodeRefsTo(location, True) + DataRefsTo(location):
TypeError: unsupported operand type(s) for +: ‘generator’ and ‘generator’

Sulley is a fuzzing framework written in Python and largely based on SPIKE. It uses ‘legos’ to allow you to abstract session setup and teardown, vmware control to monitor and reboot target virtual machines and the ability to monitor memory for corruption… sound fun? It is!

If you’ve followed my previous posts and installed PaiMei, you already know how to grab Sulley by SVN. The SVN trunk is located at: http://sulley.googlecode.com/svn/trunk/

I checked mine out to C:\sulley and it was at revision 156.

Install CORE PCapy I installed this binary that says its for Python 2.5 / WinPcap 4.0 but I had WinPcap 4.1.1 and it installs fine. You’ll find C:\Python25\Lib\site-packages\pcapy.pyd if everything installed ok.

Now get Impacket 0.9.6.0 and extract it to C:\temp.

From a DOS prompt in “C:\temp\Impacket-0.9.6.0″ install with “C:\Python25\python.exe setup.py install” you should get:

C:\temp\Impacket-0.9.6.0>C:\Python25\python.exe setup.py install
running install
running build
running build_py
creating build
creating build\lib
creating build\lib\impacket
copying impacket\ImpactDecoder.py -> build\lib\impacket
copying impacket\ImpactPacket.py -> build\lib\impacket
copying impacket\nmb.py -> build\lib\impacket
copying impacket\ntlm.py -> build\lib\impacket
copying impacket\smb.py -> build\lib\impacket
copying impacket\structure.py -> build\lib\impacket
copying impacket\uuid.py -> build\lib\impacket
copying impacket\__init__.py -> build\lib\impacket
creating build\lib\impacket\dcerpc
copying impacket\dcerpc\conv.py -> build\lib\impacket\dcerpc
copying impacket\dcerpc\dcerpc.py -> build\lib\impacket\dcerpc
copying impacket\dcerpc\dcerpc_v4.py -> build\lib\impacket\dcerpc
copying impacket\dcerpc\dcom.py -> build\lib\impacket\dcerpc
copying impacket\dcerpc\epm.py -> build\lib\impacket\dcerpc
copying impacket\dcerpc\ndrutils.py -> build\lib\impacket\dcerpc
copying impacket\dcerpc\printer.py -> build\lib\impacket\dcerpc
copying impacket\dcerpc\samr.py -> build\lib\impacket\dcerpc
copying impacket\dcerpc\srvsvc.py -> build\lib\impacket\dcerpc
copying impacket\dcerpc\svcctl.py -> build\lib\impacket\dcerpc
copying impacket\dcerpc\transport.py -> build\lib\impacket\dcerpc
copying impacket\dcerpc\winreg.py -> build\lib\impacket\dcerpc
copying impacket\dcerpc\__init__.py -> build\lib\impacket\dcerpc
running build_scripts
creating build\scripts-2.5
copying examples\chain.py -> build\scripts-2.5
copying examples\crapchain.py -> build\scripts-2.5
copying examples\exploit.py -> build\scripts-2.5
copying examples\loopchain.py -> build\scripts-2.5
copying examples\ms05-039-crash.py -> build\scripts-2.5
copying examples\oochain.py -> build\scripts-2.5
copying and adjusting examples\ping.py -> build\scripts-2.5
copying and adjusting examples\rpcdump.py -> build\scripts-2.5
copying and adjusting examples\samrdump.py -> build\scripts-2.5
copying examples\smbcat.py -> build\scripts-2.5
copying and adjusting examples\smbclient.py -> build\scripts-2.5
copying and adjusting examples\sniff.py -> build\scripts-2.5
copying and adjusting examples\sniffer.py -> build\scripts-2.5
copying and adjusting examples\split.py -> build\scripts-2.5
copying and adjusting examples\tracer.py -> build\scripts-2.5
copying examples\win_echod.py -> build\scripts-2.5
copying doc\New SMB and DCERPC features in Impacket.pdf -> build\scripts-2.5
copying doc\SMBCommands.dot -> build\scripts-2.5
copying doc\SMBCommands.png -> build\scripts-2.5
running install_lib
creating C:\Python25\Lib\site-packages\impacket
creating C:\Python25\Lib\site-packages\impacket\dcerpc
copying build\lib\impacket\dcerpc\conv.py -> C:\Python25\Lib\site-packages\impacket\dcerpc
copying build\lib\impacket\dcerpc\dcerpc.py -> C:\Python25\Lib\site-packages\impacket\dcerpc
copying build\lib\impacket\dcerpc\dcerpc_v4.py -> C:\Python25\Lib\site-packages\impacket\dcerpc
copying build\lib\impacket\dcerpc\dcom.py -> C:\Python25\Lib\site-packages\impacket\dcerpc
copying build\lib\impacket\dcerpc\epm.py -> C:\Python25\Lib\site-packages\impacket\dcerpc
copying build\lib\impacket\dcerpc\ndrutils.py -> C:\Python25\Lib\site-packages\impacket\dcerpc
copying build\lib\impacket\dcerpc\printer.py -> C:\Python25\Lib\site-packages\impacket\dcerpc
copying build\lib\impacket\dcerpc\samr.py -> C:\Python25\Lib\site-packages\impacket\dcerpc
copying build\lib\impacket\dcerpc\srvsvc.py -> C:\Python25\Lib\site-packages\impacket\dcerpc
copying build\lib\impacket\dcerpc\svcctl.py -> C:\Python25\Lib\site-packages\impacket\dcerpc
copying build\lib\impacket\dcerpc\transport.py -> C:\Python25\Lib\site-packages\impacket\dcerpc
copying build\lib\impacket\dcerpc\winreg.py -> C:\Python25\Lib\site-packages\impacket\dcerpc
copying build\lib\impacket\dcerpc\__init__.py -> C:\Python25\Lib\site-packages\impacket\dcerpc
copying build\lib\impacket\ImpactDecoder.py -> C:\Python25\Lib\site-packages\impacket
copying build\lib\impacket\ImpactPacket.py -> C:\Python25\Lib\site-packages\impacket
copying build\lib\impacket\nmb.py -> C:\Python25\Lib\site-packages\impacket
copying build\lib\impacket\ntlm.py -> C:\Python25\Lib\site-packages\impacket
copying build\lib\impacket\smb.py -> C:\Python25\Lib\site-packages\impacket
copying build\lib\impacket\structure.py -> C:\Python25\Lib\site-packages\impacket
copying build\lib\impacket\uuid.py -> C:\Python25\Lib\site-packages\impacket
copying build\lib\impacket\__init__.py -> C:\Python25\Lib\site-packages\impacket

byte-compiling C:\Python25\Lib\site-packages\impacket\dcerpc\conv.py to conv.pyc
byte-compiling C:\Python25\Lib\site-packages\impacket\dcerpc\dcerpc.py to dcerpc.pyc
byte-compiling C:\Python25\Lib\site-packages\impacket\dcerpc\dcerpc_v4.py to dcerpc_v4.pyc
byte-compiling C:\Python25\Lib\site-packages\impacket\dcerpc\dcom.py to dcom.pyc
byte-compiling C:\Python25\Lib\site-packages\impacket\dcerpc\epm.py to epm.pyc
byte-compiling C:\Python25\Lib\site-packages\impacket\dcerpc\ndrutils.py to ndrutils.pyc
byte-compiling C:\Python25\Lib\site-packages\impacket\dcerpc\printer.py to printer.pyc
byte-compiling C:\Python25\Lib\site-packages\impacket\dcerpc\samr.py to samr.pyc
byte-compiling C:\Python25\Lib\site-packages\impacket\dcerpc\srvsvc.py to srvsvc.pyc
byte-compiling C:\Python25\Lib\site-packages\impacket\dcerpc\svcctl.py to svcctl.pyc
byte-compiling C:\Python25\Lib\site-packages\impacket\dcerpc\transport.py to transport.pyc
byte-compiling C:\Python25\Lib\site-packages\impacket\dcerpc\winreg.py to winreg.pyc
byte-compiling C:\Python25\Lib\site-packages\impacket\dcerpc\__init__.py to __init__.pyc
byte-compiling C:\Python25\Lib\site-packages\impacket\ImpactDecoder.py to ImpactDecoder.pyc
byte-compiling C:\Python25\Lib\site-packages\impacket\ImpactPacket.py to ImpactPacket.pyc
byte-compiling C:\Python25\Lib\site-packages\impacket\nmb.py to nmb.pyc
byte-compiling C:\Python25\Lib\site-packages\impacket\ntlm.py to ntlm.pyc
byte-compiling C:\Python25\Lib\site-packages\impacket\smb.py to smb.pyc
byte-compiling C:\Python25\Lib\site-packages\impacket\structure.py to structure.pyc
byte-compiling C:\Python25\Lib\site-packages\impacket\uuid.py to uuid.pyc
byte-compiling C:\Python25\Lib\site-packages\impacket\__init__.py to __init__.pyc
running install_scripts
copying build\scripts-2.5\chain.py -> C:\Python25\Scripts
copying build\scripts-2.5\crapchain.py -> C:\Python25\Scripts
copying build\scripts-2.5\exploit.py -> C:\Python25\Scripts
copying build\scripts-2.5\loopchain.py -> C:\Python25\Scripts
copying build\scripts-2.5\ms05-039-crash.py -> C:\Python25\Scripts
copying build\scripts-2.5\New SMB and DCERPC features in Impacket.pdf -> C:\Python25\Scripts
copying build\scripts-2.5\oochain.py -> C:\Python25\Scripts
copying build\scripts-2.5\ping.py -> C:\Python25\Scripts
copying build\scripts-2.5\rpcdump.py -> C:\Python25\Scripts
copying build\scripts-2.5\samrdump.py -> C:\Python25\Scripts
copying build\scripts-2.5\smbcat.py -> C:\Python25\Scripts
copying build\scripts-2.5\smbclient.py -> C:\Python25\Scripts
copying build\scripts-2.5\SMBCommands.dot -> C:\Python25\Scripts
copying build\scripts-2.5\SMBCommands.png -> C:\Python25\Scripts
copying build\scripts-2.5\sniff.py -> C:\Python25\Scripts
copying build\scripts-2.5\sniffer.py -> C:\Python25\Scripts
copying build\scripts-2.5\split.py -> C:\Python25\Scripts
copying build\scripts-2.5\tracer.py -> C:\Python25\Scripts
copying build\scripts-2.5\win_echod.py -> C:\Python25\Scripts
running install_data
creating C:\Python25\share\doc\Impacket
copying README -> C:\Python25\share\doc\Impacket
copying LICENSE -> C:\Python25\share\doc\Impacket
running install_egg_info
Writing C:\Python25\Lib\site-packages\Impacket-0.9.6.0-py2.5.egg-info

Go grab wxPython for the console:

http://downloads.sourceforge.net/wxpython/wxPython2.8-win32-unicode-2.8.10.1-py25.exe

Moving to Step Five: GraphViz, Oreas GDE, and uDraw