The Bool Party You Will Never Forget: A Binary Exploitation Technique For Arbitrary Function…

The Bool Party You Will Never Forget:

A Binary Exploitation Technique For Arbitrary Function Execution Using Windows Thread Pools To Drown Modern Exploitation Mitigations

When it comes to binary exploitation — glory days are gone, now that the castle walls are strong. The bricks that build the walls that thwart the craft are tough. Though with new tools new paths have been cracked through time and again and again. Here we present yet another attack on kernel land.

Hypervisor enforced Write Xor Execute protects the windows kernel. The response that's now quiet was ROP. Silenced now by shadows stacks. Data Only Attacks yet remain but the most tempting targets are proscribed by PatchGaurd.

ROP thus evolves to Function Oriented Programming or FOP. Exacting control over parameters becomes harder thanks to the lack of convenient ROP gadgets that could pop and write to registers. There are brilliant solutions to this though complete control is wanting .

Enter asynchronous execution-

It helps in asynchronous execution if both function and parameters are described in memory, this data often simply set in a queue which is consumed by a sink to run its course. Dropped there by a busy thread who simply couldn't wait to synchronously execute.

Already thread queues have been put to good use here. But there it was so close, function execution with a single write process memory but marred by the use of handle duplication and a frustrating syscall.

Here it is the work item

The Work Item

A worker thread that dequeues this structure calls Routine with Parameter as the only argument. No validation. No provenance check.

The Queue

The target is the KPRIQUEUE inside nt!ExWorkerQueue:

Linked List Manipulation

Our linked list is circular. An empty list head points to itself:

After injection, the code writes VA_WORK_ITEM into both Head.Flink and Head.Blink. The item's List.Flink and List.Blink already point back to VA_QUEUE_HEAD. Routine and Parameter point into a separate attacker-controlled segment:

The dequeuing thread follows Flink, unlinks the item using its own links, and calls Routine with Parameter.

Limitations

Race conditions. The queue must be idle between the emptiness check and the writes. Under load the window widens. A corrupted list produces a blue screen.

Write primitive. requires an arbitrary write primitive to make these modifications

Read primitive . KASLR and allocation randomness change all addresses on reboot. Constants must be re-derived each session. Stale values crash the system.

References

1. Connor McGarr, HVCI and ROP https://connormcgarr.github.io/hvci/
2. Phrack Issue 71, Bypassing CET and BTI with Functional Oriented Programming https://phrack.org/issues/71/bypassing-cet-and-bti-with-functional-oriented-programming_md
3. SafeBreach, Process Injection Using Windows Thread Pools https://www.safebreach.com/blog/process-injection-using-windows-thread-pools/
4. Geoff Chappell, DISPATCHER_HEADER https://www.geoffchappell.com/studies/windows/km/ntoskrnl/inc/ntos/ntosdef_x/dispatcher_header/index.htm

Acknowledgement

I thank the folks at Globals for enabling me to flourish and work on low level research, without whom this work would not be possbile. Further I thank Rahul (https://medium.com/@rahul.0xkr) for his diligent work in this matter