Exploiting Office: MS08-011 – Attacking using Malformed .WPS
Microsoft Office Exploitation is still to be continued in today. Microsoft Office and Internet Explorer is the target because they are the applications that used everyday and has the more possibility to interact with external entities that other applications. However, exploiting Microsoft Office is not trivial, you must know a lot of Office document format - Word, Excel, PowerPoint and etc. I try to learn these files formats from internet and I found that it's not easy and time consuming. I think may be trying to learn the file format from exploit may be the easier way. So, I pick up the MS08-011 Microsoft Works files (.WPS) vulnerability to be the case study.
According to Microsoft Security Bullentin, MS08-011 occurs when Microsoft Office or Microsoft Works Suite try to convert the crafted .WPS files to be other format. The vulnerability in this case is stack-based buffer overflow which is easier to exploit. I set up Microsoft Windows XP SP2 and Microsoft Office 2003 SP3 as the test-based. To exploit this vulnerability, you have to install Import Converter. If you have not yet installed it, Microsoft Word will install it when you try to open .WPS file:
I use Chujwamwdupe's exploit which tested on Windows XP SP2 de and Office 2003 SP3. This is the result:
Microsoft Word crashs, however, the calculator is launched which means that it exploits successfully without any modification. In the exploit, it use the return address 0x7c941eed which point to "jmp esp" instruction. in XP SP2 de. When I lookup this address in my machine, it's point to the same instruction, that's why I don't have to change any part of the exploit.
I start to debug the vulnerability by changing the return to 0x41414141 and re-run the exploit. However, it seems that all of information on the stack are destroyed by the exploit, so I can't trace back to see what's happened. Umm.... may be I have to find more details from the exploit code instead. In the code, the author said that when you change the length of TEXT section to the value more than 0x10 , the overflow will occur. I start to locate the magic characters of .WPS file "CHNKWKS" and the locate the "TEXT" characters. After the "TEXT" field, I see only one character that is not null:
I think may be this is the key to trick the overflow. I change this value to 0x01 and re-run the exploit:
At this time, it crash in different position from the old one, 0x61092ae7 (wkcvqd01!DllGetClassObject + 0x158fd). I put the assumption that the overflow situation may be related to this function, so I start to disassembly the code section and it's lucky because the code is easy to understand:
Shortly describe, this code copy data from the address pointed by esi to the address pointed by edi. esi got the address from eax, and edi got the address from ecx. Each of loop will copy 12 bytes and check the loop condition value which stored at address pointed by ebx + 0Ah. I set the value 0x01 back to 0x2f, then set the breakpoint in debugger at 0x61092ae7. When I run the exploit, the message breakpoint hit occurs on the screen and I run the debugger step by step until I see something interesting:
At this step, the loop condition is loaded from address pointed by ebx + 0xa to esi, and it's value is 0x2f !!! Yezzz, this value which I suspect is an important key in the exploit. It's functionality is the number of loop, for each loop the program will copy 12 bytes from source to destination totally 12 * 0x2f = 564 bytes to memory. If you calculate length of shellcode + number of bytes after 0x2f + length of the return address, you will see that it is 362 + 20 + 4 = 386 bytes which small enough for the value 0x2f to copy all of we need.
I continue the debugger until exit the loop, the stack looks like this:
Our return address is stored at 0x001242e8 and starting of the shellcode is at 0x001242ec. After this step we will see 2 "pop" instruction and 1 "ret" instruction, then flow of execution transfers to 0x61091b25, wkcvqd01!DllGetClassObject + 0x1493b:
I continue run step-by-step until the instruction "ret" again:
Now, it's easy to understand what's happened next ;) Microsoft Word will returns to address on the stack which point to "jmp esp" instruction. After that, the program will landing on the stack which our shellcode is stored:
End ^=^
According to Microsoft Security Bullentin, MS08-011 occurs when Microsoft Office or Microsoft Works Suite try to convert the crafted .WPS files to be other format. The vulnerability in this case is stack-based buffer overflow which is easier to exploit. I set up Microsoft Windows XP SP2 and Microsoft Office 2003 SP3 as the test-based. To exploit this vulnerability, you have to install Import Converter. If you have not yet installed it, Microsoft Word will install it when you try to open .WPS file:
I use Chujwamwdupe's exploit which tested on Windows XP SP2 de and Office 2003 SP3. This is the result:
Microsoft Word crashs, however, the calculator is launched which means that it exploits successfully without any modification. In the exploit, it use the return address 0x7c941eed which point to "jmp esp" instruction. in XP SP2 de. When I lookup this address in my machine, it's point to the same instruction, that's why I don't have to change any part of the exploit.
I start to debug the vulnerability by changing the return to 0x41414141 and re-run the exploit. However, it seems that all of information on the stack are destroyed by the exploit, so I can't trace back to see what's happened. Umm.... may be I have to find more details from the exploit code instead. In the code, the author said that when you change the length of TEXT section to the value more than 0x10 , the overflow will occur. I start to locate the magic characters of .WPS file "CHNKWKS" and the locate the "TEXT" characters. After the "TEXT" field, I see only one character that is not null:
I think may be this is the key to trick the overflow. I change this value to 0x01 and re-run the exploit:
At this time, it crash in different position from the old one, 0x61092ae7 (wkcvqd01!DllGetClassObject + 0x158fd). I put the assumption that the overflow situation may be related to this function, so I start to disassembly the code section and it's lucky because the code is easy to understand:
Shortly describe, this code copy data from the address pointed by esi to the address pointed by edi. esi got the address from eax, and edi got the address from ecx. Each of loop will copy 12 bytes and check the loop condition value which stored at address pointed by ebx + 0Ah. I set the value 0x01 back to 0x2f, then set the breakpoint in debugger at 0x61092ae7. When I run the exploit, the message breakpoint hit occurs on the screen and I run the debugger step by step until I see something interesting:
At this step, the loop condition is loaded from address pointed by ebx + 0xa to esi, and it's value is 0x2f !!! Yezzz, this value which I suspect is an important key in the exploit. It's functionality is the number of loop, for each loop the program will copy 12 bytes from source to destination totally 12 * 0x2f = 564 bytes to memory. If you calculate length of shellcode + number of bytes after 0x2f + length of the return address, you will see that it is 362 + 20 + 4 = 386 bytes which small enough for the value 0x2f to copy all of we need.
I continue the debugger until exit the loop, the stack looks like this:
Our return address is stored at 0x001242e8 and starting of the shellcode is at 0x001242ec. After this step we will see 2 "pop" instruction and 1 "ret" instruction, then flow of execution transfers to 0x61091b25, wkcvqd01!DllGetClassObject + 0x1493b:
I continue run step-by-step until the instruction "ret" again:
Now, it's easy to understand what's happened next ;) Microsoft Word will returns to address on the stack which point to "jmp esp" instruction. After that, the program will landing on the stack which our shellcode is stored:
End ^=^
posted by Trirat Puttaraksa at
1:03 PM
|
0 comments
