Department of Labor IE 0-day Exploit (CVE-2013-1347) Now Available at Metasploit

Blog Post created by sinn3r Employee on May 5, 2013

Recently, the U.S. Department of Labor website was compromised and had been serving malicious code, capable of detecting and disabling some antivirus products such as Avira, F-Secure, Kaspersky, AVG, Sophos, etc.  It would also attack Internet Explorer 8 users with an 0-day exploit.  The Metasploit vulnerability research community was particularly interested in the exploit part, therefore that's what we'd like to talk about in this blog. Understanding how the evolving browser security landscape operates is key to formulating defense strategies, after all.


First off, according to Microsoft's advisory, only Internet Explorer 8 is vulnerable to this exploit, and we verified that with a fully patched Windows 7 with IE8.  If you are looking for an excuse to upgrade to something more recent, the following image demonstrates IE8's weakness:

Screen Shot 2013-05-04 at 11.44.20 PM.png

Some people say this is a CVE-2012-4792 (a patched vulnerability), we beg to differ.  CVE-2012-4792 is a cbutton use-after-free, but the DoL exploit doesn't use this object at all (Exodus has an excellent writeup about that vulnerability).  Instead, a mshtml!CGenericElement::`vtable' is created while appending a datalist element:


Allocating 0x4C bytes from InsertElementInternal: 0x0563cfb0
0:008> !heap -p -a poi(0x0563cfb0)
    address 06a99fc8 found in
    _DPH_HEAP_ROOT @ 151000
    in busy allocation (  DPH_HEAP_BLOCK:         UserAddr         UserSize -         VirtAddr         VirtSize)
                                 5087390:          6a99fc8               38 -          6a99000             2000
    7c918f01 ntdll!RtlAllocateHeap+0x00000e64
    635db42e mshtml!CGenericElement::CreateElement+0x00000018
    635a67f5 mshtml!CreateElement+0x00000043
    637917c0 mshtml!CMarkup::CreateElement+0x000002de
    63791929 mshtml!CDocument::CreateElementHelper+0x00000052
    637918a2 mshtml!CDocument::createElement+0x00000021
    635d3820 mshtml!Method_IDispatchpp_BSTR+0x000000d1
    636430c9 mshtml!CBase::ContextInvokeEx+0x000005d1
    63643595 mshtml!CBase::InvokeEx+0x00000025
    63643832 mshtml!DispatchInvokeCollection+0x0000014b
    635e1cdc mshtml!CDocument::InvokeEx+0x000000f1
    63642f30 mshtml!CBase::VersionedInvokeEx+0x00000020
    63642eec mshtml!PlainInvokeEx+0x000000ea
    633a6d37 jscript!IDispatchExInvokeEx2+0x000000f8
    633a6c75 jscript!IDispatchExInvokeEx+0x0000006a
    633a9cfe jscript!InvokeDispatchEx+0x00000098


And freed during garbage collection:

0:008> !heap -p -a poi(0x0563cfb0)
    address 06a99fc8 found in
    _DPH_HEAP_ROOT @ 151000
    in free-ed allocation (  DPH_HEAP_BLOCK:         VirtAddr         VirtSize)
                                    5087390:          6a99000             2000
    7c927553 ntdll!RtlFreeHeap+0x000000f9
    636b52c6 mshtml!CGenericElement::`vector deleting destructor'+0x0000003d
    63628a50 mshtml!CBase::SubRelease+0x00000022
    63640d1b mshtml!CElement::PrivateRelease+0x00000029
    6363d0ae mshtml!PlainRelease+0x00000025
    63663c03 mshtml!PlainTrackerRelease+0x00000014
    633a10b4 jscript!VAR::Clear+0x0000005c
    6339fb4a jscript!GcContext::Reclaim+0x000000ab
    6339fd33 jscript!GcContext::CollectCore+0x00000113
    63405594 jscript!JsCollectGarbage+0x0000001d
    633a92f7 jscript!NameTbl::InvokeInternal+0x00000137
    633a6650 jscript!VAR::InvokeByDispID+0x0000017c
    633a9c0b jscript!CScriptRuntime::Run+0x00002989
    633a5ab0 jscript!ScrFncObj::CallWithFrameOnStack+0x000000ff
    633a59f7 jscript!ScrFncObj::Call+0x0000008f
    633a5743 jscript!CSession::Execute+0x00000175


Even though the CGenericElement vftable is freed, the reference is stil kept:

0:008> dc 0x0563cfb0; .echo; dc poi(0x0563cfb0)
0563cfb0  06a99fc8 00000000 ffff0075 ffffffff  ........u.......
0563cfc0  00000071 00000000 00000000 00000000  q...............
0563cfd0  00000000 0563cfd8 00000152 00000001  ......c.R.......
0563cfe0  00000000 00000000 0563cfc0 00000000  ..........c.....
0563cff0  00000010 00000000 00000000 d0d0d0d0  ................
0563d000  ???????? ???????? ???????? ????????  ????????????????
0563d010  ???????? ???????? ???????? ????????  ????????????????
0563d020  ???????? ???????? ???????? ????????  ????????????????

06a99fc8  ???????? ???????? ???????? ????????  ????????????????
06a99fd8  ???????? ???????? ???????? ????????  ????????????????
06a99fe8  ???????? ???????? ???????? ????????  ????????????????
06a99ff8  ???????? ???????? ???????? ????????  ????????????????
06a9a008  ???????? ???????? ???????? ????????  ????????????????
06a9a018  ???????? ???????? ???????? ????????  ????????????????
06a9a028  ???????? ???????? ???????? ????????  ????????????????
06a9a038  ???????? ???????? ???????? ????????  ????????????????


And of course, this invalid reference ends up with a crash when used by mshtml!CElement::Doc():

0:008> g
(5f4.2c0): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=63aae200 ebx=0563cfb0 ecx=06a99fc8 edx=00000000 esi=037cf0b8 edi=00000000
eip=6363fcc4 esp=037cf08c ebp=037cf0a4 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010246
6363fcc4 8b01            mov     eax,dword ptr [ecx]  ds:0023:06a99fc8=????????


As of now, we are not aware of any patch from Microsoft specifically for IE8, but we will be updating this blog as soon as we hear something.  If you're a current IE8 user, then please consider the following workarounds:

  • For newer Windows, upgrade to Internet Explorer 9 or 10.
  • For Windows XP users, please use other browsers such as Google Chrome or Mozilla Firefox.
  • If for some reason you must use Internet Explorer 8, please use EMET.  Or, you can also try setting IE's security zone to High, and customize your Active Scripting settings.


Note that while Microsoft's advisory also suggests setting IE8's Internet security zones to 'High' for ActiveX controls, this, by itself, will not mitigate -- the exploitation technique used here does not leverage ActiveX controls at all. So, while that is generally good advice, it will not help in this case.


If you'd like to try out this Metasploit module to better validate your defenses, please feel free to download Metasploit here.  If you already have Metasploit Framework, you may just use the msfupdate utility to receive this module.  For Metasploit Pro users, you will see this module in the upcoming update.


Special thanks to: EMH



May 3rd - Microsoft advisory 2847140, no patch yet.
May 5th - Metasploit releases ie_cgenericelement_uaf exploit
May 8th - Microsoft releases "fix-it"
May 14th - Microsoft releases MS13-038 patch