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…

***** ACCESS VIOLATION *****
AppleMobileDeviceService.exe:0040fe9a mov eax,[eax] from thread 276 caused acces
s violation
when attempting to read from 0x6b736643

SEH unwind:
008cffdc -> AppleMobileDeviceService.exe:00403930 sub esp,0×14
ffffffff -> kernel32.dll:7c839ad8 push ebp

In previous posts we started fuzzing AppleMobileDeviceService.exe using a technique called In Memory Fuzzing.  This approach was outlined in chapter 19/20 of Fuzzing:  Brute Force Vulnerability Discovery.

This article will briefly touch on the topic of reverse engineering your binary to determine your enrty and restore hooks.  These hooks are very important as they tell the debugger where to take its first memory snapshot and when to revert back to this state.

As fuzzing becomes more complex it will be up to you to determine the changes made in memory during this time and take this into consideration when looking into crashes.

Since we are interested in hooking data received via winsock the best place to start is the imports section of the binary.  When we double click recv and jump to xRefs we see only one.

The decompiled look at this function goes a little something like this:

If recv returns FFFFFFFF (or -1) there is an error. And v7 points to it.  If not, v7 is set to 0.  If everything looks good, return the data.

Cool, so this is just a little wrapper to recv with some error handling I guess.  I wonder where this function is called from…

…We’re on the right track so lets set breakpoints after the return of the calls to this function.

(set a breakpoint on all of them!)

When we attach our iPhone IDA hits a breakpoint.  If you set breakpoints after all calls to our recv() wrapper you’ll get a breakpoint at the first packet receved, the address is 004133F3…

We take a look at ESP:

If you look at ESP+4 (009CFEE4) you may notice this is a dword pointer, by pressing D a couple of times it will convert this to an address that you can double click on or mouse over to de-reference…

So, there we have it… a pointer to our data (ESP+4) and a spot to hook, 004133F3.

If we take a look at the call graph:

We can see a pretty logical restore hook:

Zooming in we snag the address and hope for the best.

We will take a look at using code coverage tools to determine the best entry and restore hook points as soon as I get my paws on BaSO4

You can grab the script here or just copy-and paste from the end of this posting.

Here is a video of the basic fuzzer in action:

In Memory Fuzzing iPhone Device Service from jeremy Richards on Vimeo.

And here is the source to the fuzzer:

#!c:\python\python.exe

"""
In Memory Fuzzer 0.02a
"""

import time
import random
import utils
import struct

from pydbg import *
from pydbg.defines import *

snapshot_hook  = 0x00413495
restore_hook   = 0x00413604
snapshot_taken = False
hit_count      = 0
address        = 0

########################################################################################################################
### callback handlers.
########################################################################################################################

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

    if dbg.exception_address == snapshot_hook:
        hit_count += 1
        print "snapshot / mutate hook point hit #%d" % hit_count

        # if a process snapshot has not yet been taken, take one now.
        if not snapshot_taken:
            start = time.time()
            print "taking process snapshot...",
            dbg.process_snapshot()
            end = time.time() - start
            print "done. completed in %.03f seconds" % end
            #context_list = dbg.dump_context_list(stack_depth=4, print_dots=True)
            print dbg.dump_context(stack_depth=4, print_dots=True)
            #print dbg.hex_dump(dbg.read_process_memory(dbg.context.Eax, 20))
            snapshot_taken = True

        if hit_count > 1:
            if address:
                print "freeing last chunk at %08x" % address
                dbg.virtual_free(address, 1000, MEM_DECOMMIT)

            print "allocating chunk of memory to hold mutation"
            address = dbg.virtual_alloc(None, 1000, MEM_COMMIT, PAGE_READWRITE)
            print "memory allocated at %08x" % address
            print "generating mutant...",
            mutant = struct.pack('hllll',random.randint(0, 255),0,2,2,0)
            print "done. generating mutant"
            print "writing mutant into target memory space"
            dbg.write(address, mutant)
            print "modifying function argument to point to mutant"
            dbg.write(dbg.context.Esp + 4, dbg.flip_endian(address))
            print dbg.hex_dump(dbg.read_process_memory(address,16))
            print "continuing execution...\n"
            dbg.bp_set(restore_hook)

    if dbg.exception_address == restore_hook:
        start = time.time()
        print "restoring process snapshot...",
        dbg.process_restore()
        end = time.time() - start
        print "done. completed in %.03f seconds" % end
        dbg.bp_set(restore_hook)

    return DBG_CONTINUE

def handle_av (dbg):
    print "***** ACCESS VIOLATION *****"

    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():
    if proc_name.lower() == "applemobiledeviceservice.exe":
        found_target = True
        break

if found_target:
    dbg.attach(pid)
    dbg.bp_set(snapshot_hook)
    dbg.bp_set(restore_hook)
    print "attached to %d. debugger active." % pid
    for addr in dbg.breakpoints.keys():
        print "bp at %08x" % addr
    dbg.run()
else:
    print "target not found."

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"

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)

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

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:

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?

PEEK! has the ability to track and print to screen the registers and stack when calls to recv() and recvfrom() are made. When these functions return EAX holds the buffer length of the recieved packet… unless there is a failure and it returns -1 (or FFFFFFFF). Unfortunately pydbg is instructed to do this without first checking the value of length.:

read_buf = create_string_buffer(length)

Which results in this:

File “C:\Python25\lib\ctypes\__init__.py”, line 70, in create_string_buffer
buftype = c_char * init
OverflowError: cannot fit ‘long’ into an index-sized integer

What’s the right ay to fix this? Should we edit pydbg to make sure it doesnt try to create a buffer 4294967295 in length? Maybe… but for now we’ll edit PAIMEIpeek.py because its easier, faster, and I don’t have commit to the svn

To resolve this, I modified each hook container call back like so:

    ####################################################################################################################
    def socket_logger_ws2_recvfrom (self, dbg, args, ret):
        '''
        Hook container call back.
        '''

        self.msg("ws2_32.recvfrom(buf=%08x, len=%d)" % (args[1], args[2]))
        self.msg("Actually received %d bytes:" % ret)
        if int(ret) == 4294967295:
            self.msg("ERROR received from ws2_32:%d" % ret)
        else:
            self.msg(dbg.hex_dump(dbg.read(args[1], ret)))

    ####################################################################################################################

Yes, its a hack but it accomplishes what I need to continue monitoring so it’s good enough for now.

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’