3 (4) new code injection tricks

Update

After I published it I got a few updates; a couple of guys successfully implemented POCs for some of the techniques in this series, this post itself was updated a few times as well. Finally, Alex Ionescu also chipped in to say that he used this technique as early as 2008 (or 2011?) and presented it at Recon that year. Unfortunately link to/slides are not available online at the time of writing this update. Also, important to note that in my older post about WordWarper I included an update about that technique being known as early as 2003!

Old Post

I was planning to blog about various (Rich) Edit callback functions for a long time. Why? Because these callbacks allow us to remotely execute code inside processes that host these controls (sometimes these controls need to meet additional criteria).

I eventually started describing them yesterday.

At first I planned to have a few posts, each dedicated to one callback (with a new cheezy ‘code injection’ name included), but then Csaba discovered EM_SETAUTOCORRECTPROC and then I felt that it’s just easier to wrap it up with a short post, and introduce them all in one go 🙂

So… why does it work? (Rich) edit includes a number of CallBack functions that can be modified from a different program thanks to windows messaging mechanism. These callbacks are simple pointers to functions and are called by the control windows procedure in response to various events.

Below are the techniques I wanted to walk through – each one describes a message (or a pair of messages) that need(s) to be sent & a prototype for a callback procedure that will be executed by the (Rich) Edit windows procedure.

Due to its nature it should work across 32- and 64- boundary same as Propagate. Since the cat is out of the bag, I lost interest and have not tested it too much, but it should work.

WordWarping (if works)

EM_SETWORDBREAKPROC & EditWordBreakProc

Hyphentension (if works)

EM_SETHYPHENATEINFO & HyphenateProc

AutoCourgette (if works)

EM_SETAUTOCORRECTPROC & AutoCorrectProc

+ after I posted this Csaba discovered a super-cool ‘feature’ that allows to actually call the AutoCorrectProc in a remote process — via EM_CALLAUTOCORRECTPROC. This is a great find and simplifies execution (that otherwise requires GUI instrumentation).

Streamception (if works)

EM_STREAMIN or EM_STREAMOUT & EditStreamCallback

Update:

After I posted this, I found one more callback function. So the title should be probably ‘4 more code injection tricks’ 😉

Oleum (if works)

EM_SETOLECALLBACK and IRichEditOleCallback

Modexp shared a nice POC here.
Csaba shared a nice POC here.

WordWarper – (not a ) new code injection trick

Update

Internet is a cool place, because luckily there are some good souls who points us in a right direction. The technique I described below was presented as early as July 2003 by Oliver Lavery from iDefense! Thanks to modexp for pointing it out.

Old Post

This is a trivial case of yet another functionality available that can help to execute code in a remote process. Same as with PROPagate technique, it only affects selected windows, but it can of course be used as an evasion, especially in early stages of compromise.

Edit controls (including Rich Edit) are very common Windows controls present in most applications. They are either embedded directly, or as subclassed windows. When they display text in multiline mode they use so-called EditWordBreakProc callback function. Anytime the control needs to do something related to word wrapping the procedure will be called.

One can modify this function for any window by sending EM_SETWORDBREAKPROC message to it. If windows is an Edit control or its descendant, funny things may happen.

In order to see which windows are susceptible to such modification I created a simple demo program that basically sends this message to every window on my desktop.

After looking around and running some potential victim programs I quickly found a good candidate to demo the technique: The Sticky Notes (StikyNot).

I ran it under the debugger to catch the moment it crashes, and then ran my test program. It changed the procedure for every window to 0x12345678.

And this is what happens when you start typing in Sticky Notes after the procedure was changed:

I bet there are more programs that can be targeted this way, but as usual, I leave it as a home work to the reader :-

Modexp shared a nice POC here.
Csaba shared a nice POC here.