BoundHook – Exception Based Kernel-Controlled UserMode Hooking

In
this article, we’ll present a new hooking technique that we have found during
our research work.

Hooking
techniques give you control over the way an operating system or a piece of
software behaves. Some of the software that utilizes hooks include: application
security solutions, system utilities, tools for programming (e.g. interception,
debugging, extending software, etc.), malicious software (e.g. rootkits) and
many others.

Please
note, this is neither an elevation nor an exploitation technique. This
technique can be used in a post-exploitation scenario in which the attacker has
control over the asset. Since malicious kernel code (rootkits) often seeks to
establish persistence in unfriendly territory, stealth technology plays a
fundamental role.

The
idea behind this BoundHook technique is to cause an exception in a very
specific location in a user-mode context and catch the exception to gain
control over the thread execution.

To
do this, we can use the BOUND instruction, which is part of Intel MPX (Memory
Protection Extensions). This instruction is designed to (along with the compiler,
runtime libraries and OS support) increase software security by checking
pointer references whose normal compile-time intentions are maliciously
exploited at runtime due to memory corruption vulnerabilities.

In
a nutshell, the BOUND instruction checks an array index against bounds and raises
software interrupt 5 if the test fails (32-bit: nt!KiTrap05, 64-bit: nt!KiBoundFault).

Why
not just do a comparison, you ask? Because Intel designed this new instruction
to generate a fault that will enable the OS to examine the bound check failure.

 

The
instruction’s syntax is as follows –

BOUND r16, m16&16 – Checks if r16 (array index) is within bounds
specified by m16&16

BOUND r32, m32&32 – Checks if r32 (array index) is within bounds
specified by m32&32

When
a bound fault occurs, the trap handler calls nt!KiHandleBound and then executes registered
bounds-exception callback routines.

A
kernel-mode driver or a shellcode payload running in kernel-mode can register a
callback routine for bound faults using nt!KeRegisterBoundCallback. This function is
not “exported” by the WDK headers, and a pointer to the function has to be
obtained dynamically.

The
callback routine has no parameters and should return a BOUND_CALLBACK_STATUS, which is
basically:

After
completion of the bound fault registration, the kernel-mode code should get a
pointer to the user-mode DLL (or any other PE) base address and calculate the
address of the function that it’s about to hook.

Obtaining
a function address is a simple task and can be accomplished in various ways,
for example by parsing the PE header. Please note, parsing an image that is
loaded into a specific process should be done in the process’s context or using
the appropriate APIs.

Once
our code is done calculating the function address, it would be nice to simply
start writing to that address. However, because this code resides in
read/execute only memory, we are unable to do this.

Windows
memory protection relies on the following factors:

Now,
we have a few options. We can either write to that address in a way that would
trigger the COW (copy-on-write) protection or, to achieve maximum stealth, we
can write directly to the function address in one of two ways. We can either manipulate
the CR0 register using __readcr0()
and __writecr0(),
or we can allocate our own memory descriptor list (MDL) to describe the memory
pages and adjust permissions on the MDL using a bitwise OR and the MDL_MAPPED_TO_SYSTEM_VA.
The MDL approach will be much more “stealthy”, since it’s completely
invisible to the current PatchGuard implementation.

First,
here’s how we can use the CR0 approach. The CR0 register description, taken from
the Intel 64 and IA-32 Architectures Software Developer’s Manual reads:

“WP
Write Protect (bit 16 of CR0) — When set, inhibits supervisor-level procedures
from writing into readonly pages; when clear, allows supervisor-level
procedures to write into read-only pages (regardless of the U/S bit setting;
see Section 4.1.3 and Section 4.6).”

Here
is an example of cr0 register manipulation:

Writing
directly to the DLL’s COW page will allow us to hook every process on the system
that is using this DLL since it will affect the cow-origin page.

Triggering
a bound fault is easy. For example, this code will trigger a fault:

Thus,
our kernel-mode code that performs the hooking should write a similar assembly
code to the place where it wants to get control over the execution of the
thread.

For
example, if we want to hook KERNELBASE!CreateFileW, we can inject these opcodes to the
function’s prologue:

UCHAR
opcodes[5]= {0x36, 0x66, 0x62, 0x0C, 0x24};

This
is basically: BOUND
CX, DWORD PTR SS : [ESP]. In this specific case, we assume that CX will
be zero (when used in real code this should be tested for every function) and
the top of stack will be greater than zero (as this is a proof of concept and
not a released tool).

Now,
after writing this to the KERNELBASE!CreateFileW  prologue, when a user-mode thread calls this
function our kernel-mode callback function will take control of the thread.

Doing
this, gives us a lot of advantages, for example –

Proof-of-concept,
a call stack of a hooked thread:

We
know that BoundHook does not meet Microsoft’s bar to be considered a
vulnerability, as machine administrator rights are already compromised.
Microsoft’s response on receiving responsible notification of a similar issue
from CyberArk (GhostHook) was as follows:

“We
have completed our investigation of this issue and have found that it is not a
vulnerability but a technique to avoid detection once the machine is already
compromised. Because it’s a post-exploitation technique it doesn’t meet the bar
for servicing in a security update but we will consider fixing it in a future
version of Windows.”

In
conclusion, this method will bring new capabilities to both software security
vendors and malware writers.