mirror of
https://github.com/fdiskyou/Zines.git
synced 2025-03-09 00:00:00 +01:00
1828 lines
84 KiB
Text
1828 lines
84 KiB
Text
|
==Phrack Inc.==
|
||
|
|
|
||
|
|
Volume 0x0c, Issue 0x41, Phile #0x04 of 0x0f
|
||
|
|
|
||
|
|
|=-----------------------------------------------------------------------=|
|
||
|
|
|=---=[ Stealth hooking : Another way to subvert the Windows kernel ]=---=|
|
||
|
|
|=-----------------------------------------------------------------------=|
|
||
|
|
|=--------------------=[ by mxatone and ivanlef0u ]=---------------------=|
|
||
|
|
|=-----------------------------------------------------------------------=|
|
||
|
|
|
||
|
|
|
||
|
|
1 - Introduction on anti-rookits technologies and bypass
|
||
|
|
1.1 - Rookits and anti-rootkits techniques
|
||
|
|
1.2 - About kernel level protections
|
||
|
|
1.3 - Concept key: use kernel code against itself
|
||
|
|
|
||
|
|
2 - Introducing stealth hooking on IDT.
|
||
|
|
2.1 - How Windows manage hardware interrupts
|
||
|
|
2.1.1 - Hardware interrupts dispatching on Windows
|
||
|
|
2.1.2 - Hooking hardware IT like a ninja
|
||
|
|
2.1.3 - Application 1 : Kernel keylogger
|
||
|
|
2.1.4 - Application 2 : NDIS incoming packets sniffer
|
||
|
|
2.2 - Conclusion about stealth hooking on IDT
|
||
|
|
|
||
|
|
3 - Owning NonPaged pool using stealth hooking
|
||
|
|
3.1 - Kernel allocation layout review
|
||
|
|
3.1.1 - Difference between Paged and NonPaged pool
|
||
|
|
3.1.2 - NonPaged pool tables
|
||
|
|
3.1.3 - Allocation and free algorithms
|
||
|
|
3.2 - Getting code execution abusing allocation code
|
||
|
|
3.2.1 - Data corruption of MmNonPagedPoolFreeListHead
|
||
|
|
3.2.2 - Expend it for every size
|
||
|
|
3.3 - Exploit our position
|
||
|
|
3.3.1 - Generic stack redirection
|
||
|
|
3.3.2 - Userland process code injection
|
||
|
|
|
||
|
|
4 - Detection
|
||
|
|
5 - Conclusion
|
||
|
|
6 - References
|
||
|
|
|
||
|
|
|
||
|
|
---[ 1 - Introduction on anti-rookits technologies and bypass
|
||
|
|
|
||
|
|
Nowadays rootkits and anti-rootkits are becoming more and more important
|
||
|
|
into the IT security landscape. Loved by some, hated by others, rootkits
|
||
|
|
can be considered as the holy grail of backdoors : stealthy, little,
|
||
|
|
close to hardware, ingenious, vicious... Their control over a computer
|
||
|
|
locally or remotely make them the best choice for an attacker.
|
||
|
|
Anti-rootkits try to detect and eradicate those malicious programs.
|
||
|
|
Rk techniques and complexity are evolving fast and today developing a rk or
|
||
|
|
anti-rk is a very hard mission.
|
||
|
|
|
||
|
|
This paper deals about rootkits on Windows platform. More precisely about
|
||
|
|
new kind of hijacking techniques that can be applied to the Windows kernel.
|
||
|
|
Readers are assumed to be aware about rootkits techniques on Windows.
|
||
|
|
|
||
|
|
----[ 1.1 - Rootkits and anti-rootkits technics
|
||
|
|
|
||
|
|
A rootkit hijacks an operating system's behavior. In order to achieve this
|
||
|
|
task, it can simply modify the operating system's binaries but that's not
|
||
|
|
very stealthy. Most rk's use hooks on important functions and change theirs
|
||
|
|
results. A basic hook redirects execution flow by changing function start
|
||
|
|
or a function pointer but there is no single way to hook a routine. The
|
||
|
|
most common example is the SSDT (System Service Descriptor Table), this
|
||
|
|
table contains the syscall list which is a set of functions pointers. If
|
||
|
|
you can modify a pointer in this table, you are able to control the
|
||
|
|
behavior of one function. That's an example of how rootkits proceed,
|
||
|
|
obviously there is a lot of critical areas that can be controlled by an
|
||
|
|
attacker.
|
||
|
|
|
||
|
|
Anti-rootkits try to check those areas, but the task is very hard. Most of
|
||
|
|
the time, anti-rk software makes a comparison between the memory image of
|
||
|
|
the program and its binary on the disk or verify some function pointer
|
||
|
|
tables to see if something has changed.
|
||
|
|
|
||
|
|
That's how the war between rk-makers and anti-rk-junkies began, trying
|
||
|
|
to find the best way, the best area, for hooking critical operating
|
||
|
|
system features. On Windows those following areas are often used by
|
||
|
|
rootkits :
|
||
|
|
|
||
|
|
- SSDT (kernel syscalls table) and shadow SSDT (win32k syscall table) are
|
||
|
|
the simplest solution.
|
||
|
|
|
||
|
|
- MSR (Model Specific Registers) can be modified by a rootkit. On Windows
|
||
|
|
the MSR_SYSENTER_EIP is used by the assembly instructions 'sysenter' to
|
||
|
|
enter into ring0 mode. Hijacking this MSR allow an attacker to control
|
||
|
|
the system.
|
||
|
|
|
||
|
|
- MajorFunctions are functions used by drivers for I/O processing with
|
||
|
|
others devices, hooking those functions can be useful for a rootkit.
|
||
|
|
|
||
|
|
- IDT (Interrupt Descriptor Table) is table used by the system for
|
||
|
|
handling exceptions and interruptions.
|
||
|
|
|
||
|
|
Another kind of techniques has appeared. By accessing to the kernel
|
||
|
|
objects a rootkit can easily change information about processes, threads,
|
||
|
|
loaded modules and other stuff. Those techniques are called DKOM (Direct
|
||
|
|
Kernel Object Manipulation). For example, the Windows kernel maintains a
|
||
|
|
double linked list called PsActiveProcessList (EPROCESS structures)
|
||
|
|
containing information about running processes. Unlink one of them and
|
||
|
|
your process will disappear from process lists like task manager, whereas
|
||
|
|
the process is still running.
|
||
|
|
|
||
|
|
To block those kernel objects modifications, anti-rk checks other
|
||
|
|
sections. For processes, they used to read the PspCidTable which
|
||
|
|
has a table of PID (Process IDentifier) and TID (Thread IDentifier).
|
||
|
|
A comparison between this table and PsActiveProcessList shows hidden
|
||
|
|
processes. Against those attacks anti-rk tools have to find others
|
||
|
|
sections and tricks to detect altered objects.
|
||
|
|
|
||
|
|
One of the first paper about Windows stealth was written by Holy Father,
|
||
|
|
"Invisibility on NT boxes" [1]. With this paper came one of the first
|
||
|
|
public implementations of a rootkit with a ring0 driver, Hacker
|
||
|
|
Defender [2], coded by Holy Father and Ratter of the famous VXing mag 29A
|
||
|
|
[3]. This driver was able to elevate process rights using token
|
||
|
|
manipulation. The rest of the rootkit uses user-land hooks to perform files
|
||
|
|
and registry hiding, process infection with dll injection. A good example
|
||
|
|
of a full ring0 rootkit is NT Rootkit of Greg Hoglund [4], this driver uses
|
||
|
|
SSDT hooks to perform stealth operation. It registers a Filter Device
|
||
|
|
Object above the NTFS file system and above the keyboard device for
|
||
|
|
filtering IRP (I/O Request Packets). It also provides a NDIS protocol
|
||
|
|
driver to hide communication on the network. Even if this rk was written
|
||
|
|
for NT 4.0 and Win2K it's a perfect example for beginners.
|
||
|
|
|
||
|
|
After came more advanced ring0 rk like FU [5], written by Fuzen_op and its
|
||
|
|
improvement FUto published in the famous technical journal Uninformed [6].
|
||
|
|
Vista improvement on driver verification introduces new rootkits mostly
|
||
|
|
based on hardware features. Like BootRoot [7] and Pixie [8] by Eeye
|
||
|
|
loaded before any protection. Finally Joanna Rutkowska with her Blue
|
||
|
|
Pill [9] used virtualization technology to create layer between the
|
||
|
|
operating system and the hardware.
|
||
|
|
|
||
|
|
In the wild the rk are used most of the time for lame mail spamming or
|
||
|
|
botnets. They often use old techniques but some of them are interesting
|
||
|
|
like Rustock [10] series or StormWorm [11] and the MBR rootkit [12]. They
|
||
|
|
implement a lot of tricks as ADS (Alternate Data Stream), code obfuscation,
|
||
|
|
anti-debug, anti-VM or polymorphic code. The goal is not only subverting
|
||
|
|
the kernel but also slow down their analysis and make them harder to
|
||
|
|
defeat.
|
||
|
|
|
||
|
|
Even if the technology used by rootkits are more and more sophisticated,
|
||
|
|
the underground community is still developing POCs to improve current
|
||
|
|
techniques. Unreal [13] and AK992 [14] are both great examples. The first
|
||
|
|
uses an ADS and a NTFS MajorFunctions hooking to hide itself, the second
|
||
|
|
checks IRP completion when sended to disk's devices. You can find plenty
|
||
|
|
examples of rootkit techniques on rootkit.com.
|
||
|
|
|
||
|
|
Finally, this part would not be complete if we don't speak about anti-rk.
|
||
|
|
The most famous is Rk Unhooker by MP_ART & EP_X0FF and their team UG North.
|
||
|
|
Others anti-rk are DarkSpy [15] by CardMagic, IceSword [16] by pjf and
|
||
|
|
Gmer [17].
|
||
|
|
|
||
|
|
----[ 1.2 - About kernel level protections
|
||
|
|
|
||
|
|
When we talk about protection, we must notice where the protection takes
|
||
|
|
place into the system. A protection has an advantage on an attack only
|
||
|
|
if it operates from a higher level. Protections like PaX or Exec Shield
|
||
|
|
are efficient because they protecting userland from kernel.
|
||
|
|
|
||
|
|
Protections like PatchGuard and other HIPS also protect the system
|
||
|
|
integrity but as far as an attacker can find a way to attack those
|
||
|
|
protections at their own level they will be useless. A protection is
|
||
|
|
reliable only if it can't be corrupted by an attacker. Assuming an
|
||
|
|
attacker find a way to inject code into the protection and you can
|
||
|
|
consider that your b0x is dead.
|
||
|
|
|
||
|
|
That's why PatchGuard isn't so efficient [18]. But we know that disabling
|
||
|
|
or destroying a protection is very noisy. No, the best way is to fly under
|
||
|
|
the radar by working with special objects and events that cannot be
|
||
|
|
checked because of their volatility.
|
||
|
|
|
||
|
|
In June 2006, Greg Hoglund presented the concept of KOH (Kernel Object
|
||
|
|
Hooking) [19]. A new way of detouring code execution, you don't have to
|
||
|
|
modify static code section but rather you work on dynamic allocated
|
||
|
|
structures/codes like DPC (Deferred Procedure Calls). For protections,
|
||
|
|
it's hard to find and verify those areas due to their instabilities.
|
||
|
|
|
||
|
|
Others cool objects are IRP. They are the object used by the Windows
|
||
|
|
kernel I/O manager to communicate with devices. Each I/O operation on
|
||
|
|
hardware generates an IRP, sycalls send IRP to a driver through his
|
||
|
|
device. In general a driver owns several devices; one of them is used to
|
||
|
|
communique with the userland by using IOCTL and others devices are
|
||
|
|
managing IRP by filtering them or performing a requested task.
|
||
|
|
IRP are sent to a driver using its MajorFunctions table. This table
|
||
|
|
includes the different functionalities provided by the driver. You can
|
||
|
|
check the result returned by a MajorFunction by installing a completion
|
||
|
|
routine on an IRP. They are very volatile objects; controlling and
|
||
|
|
checking them is very hard.
|
||
|
|
|
||
|
|
In fact, if you want to check everything you would need to completely
|
||
|
|
redesign operating system architecture. So keep in mind that protection
|
||
|
|
cannot be everywhere at every time and we will demonstrate it in the
|
||
|
|
following parts.
|
||
|
|
|
||
|
|
----[ 1.3 - Concept key: use kernel code against itself
|
||
|
|
|
||
|
|
The idea behind this paper is exploiting kernel code. Exploitation is
|
||
|
|
possible because input defines code behavior. Submitting a crafted input
|
||
|
|
to a vulnerable software can leads into code execution. Dangerous input is
|
||
|
|
of course defined by your target. Kernel space contains more exploitation
|
||
|
|
scenarios because you can change its environment. A rootkit can not
|
||
|
|
change basic inputs as arguments. But it can change the environment around
|
||
|
|
a code. Heap exploitation techniques such as unlinking is a perfect
|
||
|
|
example. By changing a memory block structure, you are able to overwrite
|
||
|
|
4 bytes. Some techniques can even change next allocated block address [20].
|
||
|
|
It does work because a program trusts those information. In kernel, you
|
||
|
|
have a total control on the environment. Also completely checking the
|
||
|
|
kernel is bad for performance and totally impossible.
|
||
|
|
|
||
|
|
Changing code environment has been used successfully for the phide2
|
||
|
|
rootkit [21] technique. This rootkit can hide threads without hooking
|
||
|
|
Windows scheduler which is impressive. As it relies on code behavior, it
|
||
|
|
needs strong reverse knowledge. It extends this concept into unknown
|
||
|
|
operating system behaviors. Generic protections are based on generic
|
||
|
|
assumptions. Such as checking only driver images for code hooks. These
|
||
|
|
days operating systems design is against those protections and requires
|
||
|
|
advanced software rootkit techniques.
|
||
|
|
|
||
|
|
---[ 2 - Introducing stealth hooking on IDT
|
||
|
|
|
||
|
|
Let's introduce our concept about stealth hooking with an example based on
|
||
|
|
IDT. First we will see what is the IDT and its purpose. Then we will
|
||
|
|
discuss about hardware interrupts and how Windows deals with them.
|
||
|
|
|
||
|
|
IDT (Interrupt Descriptor Table) is a CPU specific linear table localized
|
||
|
|
in kernel-land. IDT can be read with ring3 privilege level but you must
|
||
|
|
have ring0 privilege if you want to write into it. IDT is composed of 256
|
||
|
|
entries of KIDTENTRY structures and you can use the Kernel Debugger (KD)
|
||
|
|
included into the Debugging Tools for Windows [22] to see the definition
|
||
|
|
of an IDT entry.
|
||
|
|
|
||
|
|
kd> dt nt!_KIDTENTRY
|
||
|
|
+0x000 Offset : Uint2B
|
||
|
|
+0x002 Selector : Uint2B
|
||
|
|
+0x004 Access : Uint2B
|
||
|
|
+0x006 ExtendedOffset : Uint2B
|
||
|
|
|
||
|
|
Here we don't want to (re)explain the architecture of the IDT so we advise
|
||
|
|
you to read Kad's paper published in Phrack 59 about IDT and about how it
|
||
|
|
works [23].
|
||
|
|
|
||
|
|
The first 32 entries of IDT are reserved by the CPU for exceptions. Others
|
||
|
|
are use to handle hardware interrupts and special system events.
|
||
|
|
|
||
|
|
Here is a dump of the first 64 entries of the Windows' IDT.
|
||
|
|
|
||
|
|
kd> !idt -a
|
||
|
|
Dumping IDT:
|
||
|
|
|
||
|
|
00: 804df350 nt!KiTrap00
|
||
|
|
01: 804df4cb nt!KiTrap01
|
||
|
|
02: Task Selector = 0x0058
|
||
|
|
03: 804df89d nt!KiTrap03
|
||
|
|
04: 804dfa20 nt!KiTrap04
|
||
|
|
05: 804dfb81 nt!KiTrap05
|
||
|
|
06: 804dfd02 nt!KiTrap06
|
||
|
|
07: 804e036a nt!KiTrap07
|
||
|
|
08: Task Selector = 0x0050
|
||
|
|
09: 804e078f nt!KiTrap09
|
||
|
|
0a: 804e08ac nt!KiTrap0A
|
||
|
|
0b: 804e09e9 nt!KiTrap0B
|
||
|
|
0c: 804e0c42 nt!KiTrap0C
|
||
|
|
0d: 804e0f38 nt!KiTrap0D
|
||
|
|
0e: 804e164f nt!KiTrap0E
|
||
|
|
0f: 804e197c nt!KiTrap0F
|
||
|
|
10: 804e1a99 nt!KiTrap10
|
||
|
|
11: 804e1bce nt!KiTrap11
|
||
|
|
12: 804e197c nt!KiTrap0F
|
||
|
|
13: 804e1d34 nt!KiTrap13
|
||
|
|
14: 804e197c nt!KiTrap0F
|
||
|
|
15: 804e197c nt!KiTrap0F
|
||
|
|
16: 804e197c nt!KiTrap0F
|
||
|
|
17: 804e197c nt!KiTrap0F
|
||
|
|
18: 804e197c nt!KiTrap0F
|
||
|
|
19: 804e197c nt!KiTrap0F
|
||
|
|
1a: 804e197c nt!KiTrap0F
|
||
|
|
1b: 804e197c nt!KiTrap0F
|
||
|
|
1c: 804e197c nt!KiTrap0F
|
||
|
|
1d: 804e197c nt!KiTrap0F
|
||
|
|
1e: 804e197c nt!KiTrap0F
|
||
|
|
1f: 804e197c nt!KiTrap0F
|
||
|
|
|
||
|
|
20: 00000000
|
||
|
|
21: 00000000
|
||
|
|
22: 00000000
|
||
|
|
23: 00000000
|
||
|
|
24: 00000000
|
||
|
|
25: 00000000
|
||
|
|
26: 00000000
|
||
|
|
27: 00000000
|
||
|
|
28: 00000000
|
||
|
|
29: 00000000
|
||
|
|
2a: 804deb92 nt!KiGetTickCount
|
||
|
|
2b: 804dec95 nt!KiCallbackReturn
|
||
|
|
2c: 804dee34 nt!KiSetLowWaitHighThread
|
||
|
|
2d: 804df77c nt!KiDebugService
|
||
|
|
2e: 804de631 nt!KiSystemService
|
||
|
|
2f: 804e197c nt!KiTrap0F
|
||
|
|
30: 806f3d48 hal!HalpClockInterrupt
|
||
|
|
31: 80dd816c i8042prt!I8042KeyboardInterruptService (KINTERRUPT 80dd8130)
|
||
|
|
32: 804ddd04 nt!KiUnexpectedInterrupt2
|
||
|
|
33: 80dd3224 serial!SerialCIsrSw (KINTERRUPT 80dd31e8)
|
||
|
|
34: 804ddd18 nt!KiUnexpectedInterrupt4
|
||
|
|
35: 804ddd22 nt!KiUnexpectedInterrupt5
|
||
|
|
36: 804ddd2c nt!KiUnexpectedInterrupt6
|
||
|
|
37: 804ddd36 nt!KiUnexpectedInterrupt7
|
||
|
|
38: 806edef0 hal!HalpProfileInterrupt
|
||
|
|
39: 80f0827c ACPI!ACPIInterruptServiceRoutine (KINTERRUPT 80f08240)
|
||
|
|
3a: 80dc67cc vmsrvc+0x1C16 (KINTERRUPT 80dc6790)
|
||
|
|
3b: 80df6414 NDIS!ndisMIsr (KINTERRUPT 80df63d8)
|
||
|
|
3c: 80de040c i8042prt!I8042MouseInterruptService (KINTERRUPT 80de03d0)
|
||
|
|
3d: 804ddd72 nt!KiUnexpectedInterrupt13
|
||
|
|
3e: 80ed78a4 atapi!IdePortInterrupt (KINTERRUPT 80ed7868)
|
||
|
|
3f: 80f01dd4 atapi!IdePortInterrupt (KINTERRUPT 80f01d98)
|
||
|
|
40: 804ddd90 nt!KiUnexpectedInterrupt16
|
||
|
|
[...]
|
||
|
|
|
||
|
|
This dump represents a typical Windows IDT, you can see the IDT entries
|
||
|
|
index followed by the address of the handler and this name. The first 32
|
||
|
|
entries are filled by KiTrap* functions that manage exceptions. The rest
|
||
|
|
of the table is left to the system, you can see specials system interrupts
|
||
|
|
like KiSystemService and KiCallbackReturn and handlers used by drivers
|
||
|
|
like I8042KeyboardInterruptService or I8042MouseInterruptService.
|
||
|
|
|
||
|
|
----[ 2.1 - How Windows manage hardware interrupts
|
||
|
|
|
||
|
|
When we talk about interrupts we must introduce the concept of IRQL
|
||
|
|
(Interrupt ReQuest Level). The kernel represents IRQLs internally as a
|
||
|
|
number from 0 through 31 on x86 with higher numbers representing higher
|
||
|
|
priority interrupts. Although the kernel defines the standard set of IRQLs
|
||
|
|
for software interrupts, the HAL (Hardware Abstraction Layer) maps
|
||
|
|
hardware interrupt numbers to the IRQLs.
|
||
|
|
|
||
|
|
+----------------+
|
||
|
|
31 | Highests | \
|
||
|
|
to | IRQLs | | Clock, system failure.
|
||
|
|
27 | | /
|
||
|
|
+----------------+
|
||
|
|
26 | | \
|
||
|
|
to | DEVICE_IRQL | | Hardware interrupts.
|
||
|
|
3 | | /
|
||
|
|
+----------------+
|
||
|
|
2 | DISPATCH_LEVEL | Scheduler, DPC.
|
||
|
|
+----------------+
|
||
|
|
1 | APC_LEVEL | Used when dispatching APC.
|
||
|
|
+----------------+
|
||
|
|
0 | PASSIVE_LEVEL | Threads run at this IRQL.
|
||
|
|
+----------------+
|
||
|
|
|
||
|
|
Each processor has its own IRQL. You can have a core running at an IRQL=
|
||
|
|
DISPATCH_LEVEL whereas another is running at PASSIVE_LEVEL. In fact IRQL
|
||
|
|
represents the "mask ability" of the current running code. Interrupts from
|
||
|
|
a source with an IRQL above the current level interrupt the processor,
|
||
|
|
whereas interrupts from sources with IRQLs equal to or below the current
|
||
|
|
level are masked until an executing thread decrease the IRQL.
|
||
|
|
|
||
|
|
Some system components are not accessible when code is running at
|
||
|
|
IRQL>=DISPATH_LEVEL. Accessing to paged memory (memory which can be
|
||
|
|
swapped on disk) is impossible and lots of kernel functions cannot be used.
|
||
|
|
|
||
|
|
Hardware interrupts are asynchronous and reached by external peripherals.
|
||
|
|
For example when you hit a key, your keyboard device sends an IRQ
|
||
|
|
(Interrupt ReQuest) routed by the Southbridge [24] on your interrupt
|
||
|
|
controller through the Northbridge [25]. The Southbridge is a chip that can
|
||
|
|
be described like a I/O controller hub. This chip receives all the I/O
|
||
|
|
externals interrupt and send them to the Northbridge. The Northbridge is
|
||
|
|
directly connected to your memory and high speed graphic bus also to your
|
||
|
|
CPU. This chip is also known as the memory controller hub.
|
||
|
|
|
||
|
|
On most x86 systems we find a chipset called i82489, Advanced Programmable
|
||
|
|
Interrupt Controller (APIC). The APIC is composed by 2 main components, a
|
||
|
|
I/O APIC, one per CPU, and a LAPIC (Local APIC) on each core. I/O APIC
|
||
|
|
uses a routing algorithm to dispatch an interrupt on the best adapted core.
|
||
|
|
According to the principle of locality, I/O APIC will deliver the device
|
||
|
|
interrupt on the core which handled it the previous time [26].
|
||
|
|
|
||
|
|
After this LAPIC translates the IRQ to an 8-bits value, an interrupt
|
||
|
|
vector. This interrupt vector represents IDT's entry index associated with
|
||
|
|
the handler. When the core is ready to handle the interrupt, its
|
||
|
|
instruction flow is redirected on the IDT entry.
|
||
|
|
|
||
|
|
IDT IDT IDT IDT
|
||
|
|
1 2 3 4
|
||
|
|
+---+ +---+ +---+ +---+
|
||
|
|
| | | | | | | |
|
||
|
|
|---| |---| |---| |---|
|
||
|
|
| | | | | | | |
|
||
|
|
|---| |---| |---| |---|
|
||
|
|
| | | | | | | |
|
||
|
|
+---+ +---+ +---+ +---+
|
||
|
|
| | | |
|
||
|
|
+--------+ +--------+ +--------+ +--------+
|
||
|
|
| | | | | | | |
|
||
|
|
| core 1 | | core 2 | | core 3 | | core 4 |
|
||
|
|
| | | | | | | |
|
||
|
|
+--------+ +--------+ +--------+ +--------+
|
||
|
|
| LAPIC | | LAPIC | | LAPIC | | LAPIC |
|
||
|
|
+---+----+ +---+----+ +---+----+ +---+----+
|
||
|
|
| | | |
|
||
|
|
| | | |
|
||
|
|
<---+--------------+------+-------+-------------+----->
|
||
|
|
Interrupt | Processor system bus
|
||
|
|
Messages |
|
||
|
|
|
|
||
|
|
|
|
||
|
|
External +------+------+
|
||
|
|
Interrupts | |
|
||
|
|
---------------> I/O APIC |
|
||
|
|
| |
|
||
|
|
+-------------+
|
||
|
|
|
||
|
|
-----[ 2.3.1 Hardware interrupts dispatching on Windows
|
||
|
|
|
||
|
|
On Windows, the interrupt handler isn't executed immediately, there is a
|
||
|
|
code template first. This template is implemented in the function
|
||
|
|
KiInterruptTemplate and does two things. First, it saves the current
|
||
|
|
core state in the stack and dispatches code flow to the right "interrupt
|
||
|
|
dispatcher".
|
||
|
|
|
||
|
|
When a interrupt is raised, after the core status core is saved, code flow
|
||
|
|
is transferred to the interrupt handler as defined in the IDT. In fact
|
||
|
|
each interrupt handler in the IDT points to a KiInterruptTemplate
|
||
|
|
routine [27]. KiInterruptTemplate will call KiInterruptDispatch which
|
||
|
|
performs the following operations :
|
||
|
|
|
||
|
|
- Acquire the service routine spinlock.
|
||
|
|
|
||
|
|
- Raise IRQL to DEVICE_IRQL, the IRQL of a given interrupt vector is
|
||
|
|
calculated by subtracting the interrupt vector from 27d.
|
||
|
|
|
||
|
|
- Call the interrupt handler, an ISR (Interrupt Service Routine).
|
||
|
|
|
||
|
|
- Lower IRQL.
|
||
|
|
|
||
|
|
- Release the service routine spinlock.
|
||
|
|
|
||
|
|
For example, the keyboard device ISR is I8042KeyboardInterruptService.
|
||
|
|
ISR are routines for handling interrupts like top-halves in the linux
|
||
|
|
kernel. According to the WDK (Windows Driver Kit), the ISR must do
|
||
|
|
whatever is appropriate to the device to dismiss the interrupt. Then, it
|
||
|
|
should do only what is necessary to save stage and queue a DPC. It means it
|
||
|
|
interruption management will take place on a lower IRQL than during ISR
|
||
|
|
execution. The I/O processing is done into the DPC.
|
||
|
|
|
||
|
|
DPC (Deferred Procedure Call) are equivalent of bottom-halves in linux.
|
||
|
|
DPC works at IRQL DISPATCH_LEVEL, lower than the ISR's IRQL. In fact the
|
||
|
|
ISR will queue a DPC to process the entire interrupt at a lower IRQL in
|
||
|
|
order to avoid the core preemption taking too much time. For the keyboard
|
||
|
|
the DPC is I8042KeyboardIsrDpc. Here a figure to sum up the interrupt
|
||
|
|
processing :
|
||
|
|
|
||
|
|
+-------------------------+
|
||
|
|
Hardware Interrupt /----> Here we are at |
|
||
|
|
| | | IRQL=DEVICE_LEVEL |
|
||
|
|
| | | The KiInterruptDispatch |
|
||
|
|
/---> IDT ---\ | | routine calls the ISR. |
|
||
|
|
| | | |
|
||
|
|
| | | ISR handles interrupt |
|
||
|
|
+-----------------------+ | | and queue a DPC for |
|
||
|
|
| KiInterruptTemplate ------/ | later processing |
|
||
|
|
+-----------------------+ | |
|
||
|
|
+-------------------------+
|
||
|
|
|
||
|
|
KiInterruptDispatch receives one main argument from KiInterruptTemplate,
|
||
|
|
a pointer to an interrupt object stored in the EDI register. Interrupt
|
||
|
|
objects are defined by a KINTERRUPT structure :
|
||
|
|
|
||
|
|
kd> dt nt!_KINTERRUPT
|
||
|
|
+0x000 Type : Int2B
|
||
|
|
+0x002 Size : Int2B
|
||
|
|
+0x004 InterruptListEntry : _LIST_ENTRY
|
||
|
|
+0x00c ServiceRoutine : Ptr32 unsigned char
|
||
|
|
+0x010 ServiceContext : Ptr32 Void
|
||
|
|
+0x014 SpinLock : Uint4B
|
||
|
|
+0x018 TickCount : Uint4B
|
||
|
|
+0x01c ActualLock : Ptr32 Uint4B
|
||
|
|
+0x020 DispatchAddress : Ptr32 void
|
||
|
|
+0x024 Vector : Uint4B
|
||
|
|
+0x028 Irql : UChar
|
||
|
|
+0x029 SynchronizeIrql : UChar
|
||
|
|
+0x02a FloatingSave : UChar
|
||
|
|
+0x02b Connected : UChar
|
||
|
|
+0x02c Number : Char
|
||
|
|
+0x02d ShareVector : UChar
|
||
|
|
+0x030 Mode : _KINTERRUPT_MODE
|
||
|
|
+0x034 ServiceCount : Uint4B
|
||
|
|
+0x038 DispatchCount : Uint4B
|
||
|
|
+0x03c DispatchCode : [106] Uint4B
|
||
|
|
|
||
|
|
We retrieve in this structure, the SpinLock and the ServiceRoutine. Notice
|
||
|
|
that SynchronizeIrql contains the IRQL when the ISR will be executed.
|
||
|
|
|
||
|
|
For each entry in the IDT which handles a hardware interrupt, the
|
||
|
|
KiInterruptTemplate is contained in the DispatchCode table of the
|
||
|
|
KINTERRUPT structure.
|
||
|
|
|
||
|
|
For the keyboard device we have this KINTERRUPT :
|
||
|
|
|
||
|
|
kd> dt nt!_KINTERRUPT 80dd8130
|
||
|
|
+0x000 Type : 22
|
||
|
|
+0x002 Size : 484
|
||
|
|
+0x004 InterruptListEntry : _LIST_ENTRY [ 0x80dd8134 - 0x80dd8134 ]
|
||
|
|
+0x00c ServiceRoutine : 0xfa815495 unsigned char
|
||
|
|
->i8042prt!I8042KeyboardInterruptService+0
|
||
|
|
+0x010 ServiceContext : 0x80e2ec88
|
||
|
|
+0x014 SpinLock : 0
|
||
|
|
+0x018 TickCount : 0xffffffff
|
||
|
|
+0x01c ActualLock : 0x80e2ed48 -> 0
|
||
|
|
+0x020 DispatchAddress : 0x804da8d8 void nt!KiInterruptDispatch+0
|
||
|
|
+0x024 Vector : 0x31
|
||
|
|
+0x028 Irql : 0x1a ''
|
||
|
|
+0x029 SynchronizeIrql : 0x1a ''
|
||
|
|
+0x02a FloatingSave : 0 ''
|
||
|
|
+0x02b Connected : 0x1 ''
|
||
|
|
+0x02c Number : 0 ''
|
||
|
|
+0x02d ShareVector : 0 ''
|
||
|
|
+0x030 Mode : 1 ( Latched )
|
||
|
|
+0x034 ServiceCount : 0
|
||
|
|
+0x038 DispatchCount : 0xffffffff
|
||
|
|
+0x03c DispatchCode : [106] 0x56535554
|
||
|
|
|
||
|
|
Let's have a look at the beginning of KiInterruptTemplate :
|
||
|
|
|
||
|
|
nt!KiInterruptTemplate:
|
||
|
|
804da972 54 push esp
|
||
|
|
804da973 55 push ebp
|
||
|
|
804da974 53 push ebx
|
||
|
|
804da975 56 push esi
|
||
|
|
804da976 57 push edi
|
||
|
|
804da977 83ec54 sub esp,54h
|
||
|
|
804da97a 8bec mov ebp,esp
|
||
|
|
804da97c 89442444 mov dword ptr [esp+44h],eax
|
||
|
|
804da980 894c2440 mov dword ptr [esp+40h],ecx
|
||
|
|
804da984 8954243c mov dword ptr [esp+3Ch],edx
|
||
|
|
804da988 f744247000000200 test dword ptr [esp+70h],20000h
|
||
|
|
804da990 0f852a010000 jne nt!V86_kit_a (804daac0)
|
||
|
|
804da996 66837c246c08 cmp word ptr [esp+6Ch],8
|
||
|
|
804da99c 7423 je nt!KiInterruptTemplate+0x4f (804da9c1)
|
||
|
|
804da99e 8c642450 mov word ptr [esp+50h],fs
|
||
|
|
804da9a2 8c5c2438 mov word ptr [esp+38h],ds
|
||
|
|
804da9a6 8c442434 mov word ptr [esp+34h],es
|
||
|
|
804da9aa 8c6c2430 mov word ptr [esp+30h],gs
|
||
|
|
804da9ae bb30000000 mov ebx,30h
|
||
|
|
804da9b3 b823000000 mov eax,23h
|
||
|
|
804da9b8 668ee3 mov fs,bx
|
||
|
|
804da9bb 668ed8 mov ds,ax
|
||
|
|
804da9be 668ec0 mov es,ax
|
||
|
|
804da9c1 648b1d00000000 mov ebx,dword ptr fs:[0]
|
||
|
|
804da9c8 64c70500000000ffffffff mov dword ptr fs:[0],0FFFFFFFFh
|
||
|
|
804da9d3 895c244c mov dword ptr [esp+4Ch],ebx
|
||
|
|
804da9d7 81fc00000100 cmp esp,10000h
|
||
|
|
804da9dd 0f82b5000000 jb nt!Abios_kit_a (804daa98)
|
||
|
|
804da9e3 c744246400000000 mov dword ptr [esp+64h],0
|
||
|
|
804da9eb fc cld
|
||
|
|
804da9ec 8b5d60 mov ebx,dword ptr [ebp+60h]
|
||
|
|
804da9ef 8b7d68 mov edi,dword ptr [ebp+68h]
|
||
|
|
804da9f2 89550c mov dword ptr [ebp+0Ch],edx
|
||
|
|
804da9f5 c74508000ddbba mov dword ptr [ebp+8],0BADB0D00h
|
||
|
|
804da9fc 895d00 mov dword ptr [ebp],ebx
|
||
|
|
804da9ff 897d04 mov dword ptr [ebp+4],edi
|
||
|
|
804daa02 f60550f0dfffff test byte ptr ds:[0FFDFF050h],0FFh
|
||
|
|
804daa09 750d jne nt!Dr_kit_a (804daa18)
|
||
|
|
|
||
|
|
nt!KiInterruptTemplate2ndDispatch:
|
||
|
|
804daa0b bf00000000 mov edi,0
|
||
|
|
nt!KiInterruptTemplateObject:
|
||
|
|
804daa10 e9c3fcffff jmp nt!KeSynchronizeExecution+0x2 (804da6d8)
|
||
|
|
[...]
|
||
|
|
|
||
|
|
Remember, this code is unique for each KINTERRUPT. We said before that
|
||
|
|
KiInterruptDispatch receives its arguments from the EDI register (a
|
||
|
|
pointer to the KINTERRUPT of the interrupt). In the KiInterruptTemplate
|
||
|
|
we can see this little code :
|
||
|
|
|
||
|
|
[...]
|
||
|
|
nt!KiInterruptTemplate2ndDispatch:
|
||
|
|
804daa0b bf00000000 mov edi,0
|
||
|
|
nt!KiInterruptTemplateObject:
|
||
|
|
804daa10 e9c3fcffff jmp nt!KeSynchronizeExecution+0x2 (804da6d8)
|
||
|
|
[...]
|
||
|
|
|
||
|
|
Here we have a mov "edi, 0" and a jmp, but if we look at the
|
||
|
|
KiInterruptTemplate code contained in the keyboard's KINTERRUPT we have :
|
||
|
|
|
||
|
|
ffb72525 bf5024b7ff mov edi,0FFB72450h ; Keyboard KINTERRUPT
|
||
|
|
ffb7252a e9a9839680 jmp nt!KiInterruptDispatch (804da8d8)
|
||
|
|
|
||
|
|
Wow, instructions are modified! The kernel will dynamically changes those
|
||
|
|
2 instructions in the KiInterruptTemplate code. In EDI we find the
|
||
|
|
KINTERRUPT object and the jmp branch on KiInterruptDispatch.
|
||
|
|
|
||
|
|
Why this implementation ? Because we can easily change the dispatch
|
||
|
|
handler. Even if we often have the KiInterruptDispatch we can find
|
||
|
|
KiFloatingDispatch or KiChainDispatch. KiChainedDispatch is for vectors
|
||
|
|
shared among multiple interrupt objects and KiFloatingDispatch is like
|
||
|
|
KiInterruptDispatch, but it saves the floating core state too.
|
||
|
|
|
||
|
|
Windows provides APIs for connecting interrupts on IDT. IoConnectInterrupt
|
||
|
|
and IoConnectInterruptEx, according to the WDK :
|
||
|
|
|
||
|
|
NTSTATUS
|
||
|
|
IoConnectInterrupt(
|
||
|
|
OUT PKINTERRUPT *InterruptObject,
|
||
|
|
IN PKSERVICE_ROUTINE ServiceRoutine,
|
||
|
|
IN PVOID ServiceContext,
|
||
|
|
IN PKSPIN_LOCK SpinLock OPTIONAL,
|
||
|
|
IN ULONG Vector,
|
||
|
|
IN KIRQL Irql,
|
||
|
|
IN KIRQL SynchronizeIrql,
|
||
|
|
IN KINTERRUPT_MODE InterruptMode,
|
||
|
|
IN BOOLEAN ShareVector,
|
||
|
|
IN KAFFINITY ProcessorEnableMask,
|
||
|
|
IN BOOLEAN FloatingSave
|
||
|
|
);
|
||
|
|
|
||
|
|
As you can see IoConnectInterrupt returns in the InterruptObject parameter
|
||
|
|
a KINTERRUPT structure, the same that we retrieve in the IDT. Previously
|
||
|
|
you have seen in the KiInterruptTemplate two labels,
|
||
|
|
KiInterruptTemplateObject and KiInterruptTemplate2ndDispatch. Those two
|
||
|
|
labels are used by kernel function to find the two instructions in the
|
||
|
|
KiInterruptTemplateRoutine. KeInitializeInterrupt uses the
|
||
|
|
KiInterruptTemplateObject label to update the "jmp Ki*Dispatch" and the
|
||
|
|
KiConnectVectorAndInterruptObject function uses
|
||
|
|
KiInterruptTemplate2ndDispatch to modify the "mov edi, <&Kinterrupt>".
|
||
|
|
|
||
|
|
-----[ 2.3.2 Hooking hardware IDT like a ninja
|
||
|
|
|
||
|
|
Now, think about this. We want to hook the IDT in a stealth way, we know
|
||
|
|
that replacing an entry directly is not the best solution. Anti-rooktits
|
||
|
|
don't check the dynamically allocated KiInterruptTemplate routine. So we
|
||
|
|
can modify this routine as we wish. There are three possible ways :
|
||
|
|
|
||
|
|
- Redirect the "jmp Ki*Dispatch" on our dispatch routine, we have to code
|
||
|
|
our dispatch routine, not so hard.
|
||
|
|
|
||
|
|
- Change the kinterrupt address passed in EDI by the instruction
|
||
|
|
"mov edi, <&Kinterrupt>". The new KINTERRUPT will be the same than the
|
||
|
|
previous one, only the ServiceRoutine will be modified by us.
|
||
|
|
|
||
|
|
- Create our own KiInterruptTemplate, hard ...
|
||
|
|
|
||
|
|
In this paper, we choosed the simplest way. We change the
|
||
|
|
"mov edi, <&kinterrupt>" by a "mov edi, <&OurKinterrupt>" and we implement
|
||
|
|
our ServiceRoutine. We know that this instruction is followed by a jmp, so
|
||
|
|
with a disassembly engine we can retrieve the instruction before the jmp
|
||
|
|
nt!KiInterruptDispatch and modify it. We must keep in mind, when the
|
||
|
|
ServiceRoutine is running, the interrupt is not handled yet and we are
|
||
|
|
running at DEVICE_IRQL IRQL. This is not a fair situation, because a
|
||
|
|
lot of Windows kernel functions are not accessible. We know, that most
|
||
|
|
ISR queued a DPC, so after the ISR has been executed, the last entry in
|
||
|
|
the current core DPC queue should contain the DPC routine of our interrupt.
|
||
|
|
|
||
|
|
If we want to access data generated by the interrupt we must proceed like
|
||
|
|
the ISR. Replacing the original ISR by our own ISR handler is very hard,
|
||
|
|
because it depends too much on the hardware device. But we know that the
|
||
|
|
real I/O is done by the DPC, so when KiInterruptTemplate will call our
|
||
|
|
ServiceRoutine, first we call the original ServiceRoutine and we modify
|
||
|
|
the last DPC entry by our.
|
||
|
|
|
||
|
|
DPC are represented by KDPC structures :
|
||
|
|
|
||
|
|
kd> dt nt!_KDPC
|
||
|
|
+0x000 Type : Int2B
|
||
|
|
+0x002 Number : UChar
|
||
|
|
+0x003 Importance : UChar
|
||
|
|
+0x004 DpcListEntry : _LIST_ENTRY
|
||
|
|
+0x00c DeferredRoutine : Ptr32 void
|
||
|
|
+0x010 DeferredContext : Ptr32 Void
|
||
|
|
+0x014 SystemArgument1 : Ptr32 Void
|
||
|
|
+0x018 SystemArgument2 : Ptr32 Void
|
||
|
|
+0x01c Lock : Ptr32 Uint4B
|
||
|
|
|
||
|
|
DPC list can be found in the KPRCB (Kernel Processor Control Region Block)
|
||
|
|
structure of the current processor. KPRCB is preceded by a KPCR (Kernel
|
||
|
|
Processor Control Block) structure which is located at FS:[0x1C] on the
|
||
|
|
current processor. KPRCB is a 0x120 bytes from the beginning of the KPCR
|
||
|
|
structure.
|
||
|
|
|
||
|
|
dt nt!_KPRCB
|
||
|
|
[...]
|
||
|
|
+0x860 DpcListHead : _LIST_ENTRY
|
||
|
|
+0x868 DpcStack : Ptr32 Void ; DPC arguments
|
||
|
|
+0x86c DpcCount : Uint4B ; DPC core counter
|
||
|
|
+0x870 DpcQueueDepth : Uint4B ; Numbers of DPC in the list
|
||
|
|
+0x874 DpcRoutineActive : Uint4B
|
||
|
|
+0x878 DpcInterruptRequested : Uint4B
|
||
|
|
+0x87c DpcLastCount : Uint4B
|
||
|
|
+0x880 DpcRequestRate : Uint4B
|
||
|
|
+0x884 MaximumDpcQueueDepth : Uint4B
|
||
|
|
+0x888 MinimumDpcRate : Uint4B
|
||
|
|
|
||
|
|
Now we know how to retrieve the DPC of our interrupt, we can easily
|
||
|
|
change it to our own and handle the data.
|
||
|
|
|
||
|
|
For the keyboard the DPC is queued by KeInsertQueueDpc in the
|
||
|
|
I8xQueueCurrentKeyboardInput routine called by the keyboard's ISR.
|
||
|
|
|
||
|
|
kd> dt nt!_KDPC 80e3461c
|
||
|
|
+0x000 Type : 19 ; 19=DpcObject
|
||
|
|
+0x002 Number : 0 ''
|
||
|
|
+0x003 Importance : 0x1 ''
|
||
|
|
+0x004 DpcListEntry : _LIST_ENTRY [ 0xffdff980 - 0x80559684 ]
|
||
|
|
+0x00c DeferredRoutine : 0xfa815650 void i8042prt!I8042KeyboardIsrDpc
|
||
|
|
+0x010 DeferredContext : 0x80e343b8
|
||
|
|
+0x014 SystemArgument1 : (null)
|
||
|
|
+0x018 SystemArgument2 : (null)
|
||
|
|
+0x01c Lock : 0xffdff9c0 -> 0
|
||
|
|
|
||
|
|
Here is the figure of the attack :
|
||
|
|
|
||
|
|
MyKinterrupt structure
|
||
|
|
+---------------------+
|
||
|
|
Hardware Interrupt /----> MyServiceRoutine |
|
||
|
|
| | | Calls the original |
|
||
|
|
| | | ISR ------\
|
||
|
|
\---> IDT ---\ | | And modify the DPC | |
|
||
|
|
| | | queue. | |
|
||
|
|
| | +---------------------+ |
|
||
|
|
+---------------------+ | |
|
||
|
|
| KiInterruptTemplate -----/ Original Kinterrupt |
|
||
|
|
+---------------------+ +---------------------+ |
|
||
|
|
Core | | |
|
||
|
|
+------------+ | ServiceRoutine <-----/
|
||
|
|
| | | Queues the ISR's DPC|
|
||
|
|
|DpcListHead |--\ +---------------------+
|
||
|
|
| | |
|
||
|
|
+------------+ |
|
||
|
|
| +-----+ +-----+ +-----+ +-----+
|
||
|
|
\-> DPC |---->| DPC |---->| DPC |---->| DPC |-->DpcListHead
|
||
|
|
DpcListHead<---| |<----| |<----| |<----| |
|
||
|
|
+-----+ +-----+ +-----+ +-----+
|
||
|
|
/\
|
||
|
|
||
|
||
|
|
Last DPC entry
|
||
|
|
Modified after the call
|
||
|
|
to the ServiceRoutine.
|
||
|
|
|
||
|
|
-----[ 2.3.3 - Application 1 : Kernel keylogger
|
||
|
|
|
||
|
|
It's time to design a POC. In this sample we will see how to sniff
|
||
|
|
keyboard keystrokes. As you see previously, we are now able to control the
|
||
|
|
DPC generated by an interrupt. For the keyboard we will hijack the
|
||
|
|
I8042KeyboardIsrDpc routine which is set into the DPC's keyboard
|
||
|
|
interruption. With our own DPC handler we will reproduce the behavior of
|
||
|
|
the original routine, unfortunately this kind of routine is hard to write
|
||
|
|
so we ripped some pieces of codes and used reversing techniques (notice the
|
||
|
|
lazy hacker style).
|
||
|
|
|
||
|
|
In our DPC handler we must call the KeyboardClassServiceCallback [28]
|
||
|
|
routine, this routine is provided by the Kbdclass driver. This callback
|
||
|
|
transfers input data buffer of a device to the class data queue. A function
|
||
|
|
keyboard driver must calls this class service callback in its DPC routine.
|
||
|
|
Here is the KeyboardClassServiceCallback's prototype :
|
||
|
|
|
||
|
|
VOID
|
||
|
|
KeyboardClassServiceCallback (
|
||
|
|
IN PDEVICE_OBJECT DeviceObject,
|
||
|
|
IN PKEYBOARD_INPUT_DATA InputDataStart,
|
||
|
|
IN PKEYBOARD_INPUT_DATA InputDataEnd,
|
||
|
|
IN OUT PULONG InputDataConsumed
|
||
|
|
);
|
||
|
|
|
||
|
|
Parameters :
|
||
|
|
DeviceObject : Pointer to the class device object.
|
||
|
|
|
||
|
|
InputDataStart : Pointer to the first keyboard input data packet in
|
||
|
|
the input data buffer of the port device.
|
||
|
|
|
||
|
|
InputDataEnd : Pointer to the keyboard input data packet that
|
||
|
|
immediately follows the last data packet in the input data buffer of
|
||
|
|
the port device.
|
||
|
|
|
||
|
|
InputDataConsumed : Pointer to the number of keyboard input data
|
||
|
|
packets that are transferred by the routine.
|
||
|
|
|
||
|
|
KEYBOARD_INPUT_DATA is defined by :
|
||
|
|
|
||
|
|
typedef struct _KEYBOARD_INPUT_DATA {
|
||
|
|
USHORT UnitId;
|
||
|
|
USHORT MakeCode;
|
||
|
|
USHORT Flags;
|
||
|
|
USHORT Reserved;
|
||
|
|
ULONG ExtraInformation;
|
||
|
|
} KEYBOARD_INPUT_DATA, *PKEYBOARD_INPUT_DATA;
|
||
|
|
|
||
|
|
So in our DPC handler we just have to check the MakeCode member of the set
|
||
|
|
of KEYBOARD_INPUT_DATA structures. The MakeCode (or scancode) represents
|
||
|
|
the data sent by the keyboard to the system when you hit or release a
|
||
|
|
key, each key has it's own scancode and the system usually translates the
|
||
|
|
scancode into a character depending on you code page. For example the
|
||
|
|
scancode 19d on classical US keyboard is translated into the keycode 'e'.
|
||
|
|
|
||
|
|
In order to know if CAPSLOCK is activated we send an IOCTL to the
|
||
|
|
functional keyboard device but we can only send IOCTL at a PASSIVE_LEVEL
|
||
|
|
IRQL. For that we use a system thread which will sent IOCTL with the
|
||
|
|
kernel API IoBuildDeviceIoControlRequest. In fact the scancodes are queued
|
||
|
|
in a list locked by a spinlock and thread synchronized with a semaphore.
|
||
|
|
The thread is listening to incoming keystrokes then converts scancodes into
|
||
|
|
keycodes. Like the kernel keylogger Klog does [29].
|
||
|
|
|
||
|
|
-----[ 2.3.4 - Application 2 : NDIS packet sniffer
|
||
|
|
|
||
|
|
In the same way, an interrupt is raised when your network card receives
|
||
|
|
a packet. When this kind of interrupt is raised NDIS ISR handler
|
||
|
|
(ndisMIsr) routine launches the miniport ISR interrupt handler. The
|
||
|
|
ndisMIsr routine is used as a wrapper for miniport ISR and DPC. You can
|
||
|
|
see in the IDT the following entry :
|
||
|
|
|
||
|
|
3b: 80df6414 NDIS!ndisMIsr (KINTERRUPT 80df63d8)
|
||
|
|
|
||
|
|
It means, your ISR handler is not called directly when an interrupt
|
||
|
|
occurs, it is the ndisMIsr routine. Miniport's ISR is called by ndisMIsr
|
||
|
|
and the miniport DPC is also queued in this routine. The DPC queued is
|
||
|
|
the ndisMDpc routine which wraps your own DPC miniport handler. Finally
|
||
|
|
NDIS wraps all the interrupt process with ndisMIsr and ndisMDpc routines on
|
||
|
|
Windows XP with NDIS 5.1. We don't know if this implementation is still
|
||
|
|
present on Windows Vista with NDIS 6.0.
|
||
|
|
|
||
|
|
We know we can hijack the ndisMDpc handler by our own handler. With NDIS
|
||
|
|
we will proceed in the same way but we will not hook the MiniportDpc
|
||
|
|
routine but directly hook the ndisMDpc routine. Why? Because we know that
|
||
|
|
ndisMDpc wraps the MiniportDpc routine and in fact MiniportDpc depends too
|
||
|
|
much on the hardware of the miniport device. Each miniport device is
|
||
|
|
represented by an NDIS_MINIPORT_BLOCK [30] structure, in this structure
|
||
|
|
we find a reference to a NDIS_MINIPORT_INTERRUP structure, which looks
|
||
|
|
like :
|
||
|
|
|
||
|
|
kd> dt ndis!_NDIS_MINIPORT_INTERRUPT
|
||
|
|
+0x000 InterruptObject : Ptr32 _KINTERRUPT
|
||
|
|
+0x004 DpcCountLock : Uint4B
|
||
|
|
+0x008 Reserved : Ptr32 Void
|
||
|
|
+0x00c MiniportIsr : Ptr32 Void
|
||
|
|
+0x010 MiniportDpc : Ptr32 Void
|
||
|
|
+0x014 InterruptDpc : _KDPC
|
||
|
|
+0x034 Miniport : Ptr32 _NDIS_MINIPORT_BLOCK
|
||
|
|
+0x038 DpcCount : UChar
|
||
|
|
+0x039 Filler1 : UChar
|
||
|
|
+0x03c DpcsCompletedEvent : _KEVENT
|
||
|
|
+0x04c SharedInterrupt : UChar
|
||
|
|
+0x04d IsrRequested : UChar
|
||
|
|
|
||
|
|
If we look at the ndisMDpc routine we notice that only the first parameter
|
||
|
|
is used and this parameter refers to a NDIS_MINIPORT_INTERRUPT structure.
|
||
|
|
The ndisMDpc function will call the MiniportDpc field of this structure.
|
||
|
|
We just have to hijack this pointer by our routine in order to control the
|
||
|
|
incoming packets on the system.
|
||
|
|
|
||
|
|
The NDIS documentation specifies that a miniport DPC routine must
|
||
|
|
notify the bound protocol driver that an that an array of received
|
||
|
|
packets is available by calling the NdisMIndicateReceivePacket function
|
||
|
|
[31].
|
||
|
|
|
||
|
|
VOID
|
||
|
|
NdisMIndicateReceivePacket(
|
||
|
|
IN NDIS_HANDLE MiniportAdapterHandle,
|
||
|
|
IN PPNDIS_PACKET ReceivePackets,
|
||
|
|
IN UINT NumberOfPackets
|
||
|
|
);
|
||
|
|
|
||
|
|
In the ndis.h header we have :
|
||
|
|
#define NdisMIndicateReceivePacket(_H, _P, _N) \
|
||
|
|
{ \
|
||
|
|
(*((PNDIS_MINIPORT_BLOCK)(_H))->PacketIndicateHandler)( \
|
||
|
|
_H, \
|
||
|
|
_P, \
|
||
|
|
_N); \
|
||
|
|
}
|
||
|
|
|
||
|
|
So in our MiniportDpc routine we will hihjack the PacketIndicateHandler,
|
||
|
|
which is often the ethFilterDprIndicateReceivePacket routine in the
|
||
|
|
NDIS_MINIPORT_BLOCK structure, in order to filter the incoming packets on
|
||
|
|
the miniport. After we have hijacked this pointer we call the original
|
||
|
|
MiniportDpc routine that will process everything. After that, we restore
|
||
|
|
the PacketIndicateHandler handler in the NDIS_MINIPORT_BLOCK for stealth
|
||
|
|
reasons. To sum up we must :
|
||
|
|
|
||
|
|
- Hijack the routine into the DPC queued by the ndisMIsr routine.
|
||
|
|
|
||
|
|
- Now that we have hijacked the ndisMDpc we modify the
|
||
|
|
PacketIndicateHandler into the NDIS_MINIPORT_BLOCK of the miniport.
|
||
|
|
|
||
|
|
- We call the ndisMDpc routine. It will call the original MiniportDpc
|
||
|
|
handler
|
||
|
|
|
||
|
|
- The MiniportDpc routine calls the NdisMIndicateReceivePacket macro. Our
|
||
|
|
filter function is called and we do our job.
|
||
|
|
|
||
|
|
- When the ndisMDpc returns we restore the original PacketIndicateHandler
|
||
|
|
into the NDIS_MINIPORT_BLOCK of the miniport.
|
||
|
|
|
||
|
|
With this filter, we can monitor or modify the incoming packets. For
|
||
|
|
example, our PacketIndicateHandler hook can search in the incoming packets
|
||
|
|
for a tag, when this tag his found the rootkit triggers a function.
|
||
|
|
|
||
|
|
---[ 2.2 - Conclusion about stealth hooking on IDT
|
||
|
|
|
||
|
|
In this part we have seen how Windows manages his hardware interrupts by
|
||
|
|
using a global template function dedicated to all interrupts. The fact
|
||
|
|
that this template routine his forged for each interrupts is the main
|
||
|
|
point of this attack, with that we can create a fake template routine that
|
||
|
|
cannot be detected directly. The stealth of our attack remains on two
|
||
|
|
points :
|
||
|
|
|
||
|
|
- We modify only dynamic allocated and forged code
|
||
|
|
|
||
|
|
- We hijack highly temporal dynamic allocated structures which when
|
||
|
|
running, are always preempting the core.
|
||
|
|
|
||
|
|
So, even if the scope of our attack is restricted, controlling the hardware
|
||
|
|
is the best way for a rk to reach critical components. Finally, we have
|
||
|
|
just cheated the system with its own features and that's the purpose of a
|
||
|
|
stealth rootkit.
|
||
|
|
|
||
|
|
--[ 3 - Owning NonPaged pool using stealth hooking
|
||
|
|
|
||
|
|
Rootkit sophistication depends on how it subverts the kernel. More
|
||
|
|
complex techniques come out as kernel and hardware understanding evolve.
|
||
|
|
Nowadays there is so many ways to subvert the kernel, in consequence
|
||
|
|
protections become harder to defeat. We're going to present a different
|
||
|
|
means to gain control. Next techniques apply this approach to the kernel
|
||
|
|
memory allocator.
|
||
|
|
|
||
|
|
Our goal is getting execution on every NonPaged allocation without using
|
||
|
|
any hook. It must bypass any hooking verification even those based on code
|
||
|
|
page comparison or hashing. It will be done by modifying data used by the
|
||
|
|
allocator. We just apply the concept of using code against itself. We do
|
||
|
|
believe that this concept can be used on others components and in
|
||
|
|
different ways successfully.
|
||
|
|
|
||
|
|
We won't try to convince you that this technique is perfect. It evades
|
||
|
|
current protections and detection systems. The more important is that they
|
||
|
|
would need more than a simple modification to prevent and block an attack
|
||
|
|
based on kernel code behavior.
|
||
|
|
|
||
|
|
---[ 3.1 - Kernel allocation layout review
|
||
|
|
|
||
|
|
As every operating system, Windows kernel puts forward some functions in
|
||
|
|
order to allocate or free memory. Virtual memory is organized as block of
|
||
|
|
memory called pages. In Intel x86 architecture, a page size is 4096 bytes
|
||
|
|
and most allocations requests are smaller. Thus, kernel functions like
|
||
|
|
ExAllocatePoolWithTag and ExFreePoolWithTag kept unused memory blocks for
|
||
|
|
next allocations. Internal functions directly interact with hardware each
|
||
|
|
time a page is needed. All those procedures are complex and delicate that's
|
||
|
|
why drivers trust kernel implementation.
|
||
|
|
|
||
|
|
-----[ 3.1.1 - Difference between Paged and NonPaged pool
|
||
|
|
|
||
|
|
Kernel system memory is divided in two different kind of pool. It has been
|
||
|
|
separated to distinguish most used memory blocks. The system must know
|
||
|
|
which pages should be resident and which can be temporarily discarded. The
|
||
|
|
page fault handler restores pageable memory only when IRQL is inferior of
|
||
|
|
DPC or DISPATCH level. Paged pool can be paged in or out of the system. A
|
||
|
|
memory block paged out will be saved on the file system and so unused part
|
||
|
|
of paged memory will not be resident in memory. NonPaged pool is present
|
||
|
|
in every IRQL level and then is put-upon for important tasks.
|
||
|
|
|
||
|
|
The file pagefile.sys contains paged out memory. It was attacked to inject
|
||
|
|
unsigned code into Vista kernel [32]. Some solutions was discussed as
|
||
|
|
disabling kernel memory paging. Joanna Rutkowska defended this solution as
|
||
|
|
more secure than others but with a small physical memory loss. Microsoft
|
||
|
|
just denied raw disk access, which may prove that Paged and NonPaged
|
||
|
|
layout is an important feature of Windows kernel [33].
|
||
|
|
|
||
|
|
This article focuses on NonPaged pool layout as PagedPool handling is
|
||
|
|
totally different. NonPaged pool can be more or less considered as
|
||
|
|
following a typical heap implementation. Global information about system
|
||
|
|
pool can be found in Microsoft Windows Internals [34].
|
||
|
|
|
||
|
|
-----[ 3.1.2 - NonPaged pool tables
|
||
|
|
|
||
|
|
The allocation algorithm must be fast allocating on the most used sizes.
|
||
|
|
That why three different tables exist and each one is devoted to a size
|
||
|
|
range. We found this organization in most memory management algorithms.
|
||
|
|
Retrieving memory blocks from hardware takes time. Windows balances between
|
||
|
|
response faster and avoid memory wasting. Response time becomes faster if
|
||
|
|
memory blocks are stored for next allocations. In the other hand, if you
|
||
|
|
keep too much memory, it can penalize memory demands.
|
||
|
|
|
||
|
|
Each table implements a different way to store memory blocks. We will
|
||
|
|
present each table and where you can find them.
|
||
|
|
|
||
|
|
The NonPaged lookaside is a per-processor table covering size inferior or
|
||
|
|
equal to 256 bytes. Each processor has a processor control register (PCR)
|
||
|
|
storing data concerning only a single processor like IRQL level, GDT, IDT.
|
||
|
|
Its extension called processor control region (PCRB) contains lookasides
|
||
|
|
tables. Next windbg dump presents NonPaged lookaside table and its
|
||
|
|
structure.
|
||
|
|
|
||
|
|
kd> !pcr
|
||
|
|
KPCR for Processor 0 at ffdff000:
|
||
|
|
Major 1 Minor 1
|
||
|
|
NtTib.ExceptionList: 805486b0
|
||
|
|
NtTib.StackBase: 80548ef0
|
||
|
|
NtTib.StackLimit: 80546100
|
||
|
|
NtTib.SubSystemTib: 00000000
|
||
|
|
NtTib.Version: 00000000
|
||
|
|
NtTib.UserPointer: 00000000
|
||
|
|
NtTib.SelfTib: 00000000
|
||
|
|
|
||
|
|
SelfPcr: ffdff000
|
||
|
|
Prcb: ffdff120
|
||
|
|
Irql: 00000000
|
||
|
|
IRR: 00000000
|
||
|
|
IDR: ffffffff
|
||
|
|
InterruptMode: 00000000
|
||
|
|
IDT: 8003f400
|
||
|
|
GDT: 8003f000
|
||
|
|
TSS: 80042000
|
||
|
|
|
||
|
|
CurrentThread: 80551920
|
||
|
|
NextThread: 00000000
|
||
|
|
IdleThread: 80551920
|
||
|
|
|
||
|
|
DpcQueue: 0x80551f80 0x804ff29c
|
||
|
|
kd> dt nt!_KPRCB ffdff120
|
||
|
|
[...]
|
||
|
|
+0x5a0 PPNPagedLookasideList : [32]
|
||
|
|
+0x000 P : 0x819c6000 _GENERAL_LOOKASIDE
|
||
|
|
+0x004 L : 0x8054dd00 _GENERAL_LOOKASIDE
|
||
|
|
[...]
|
||
|
|
kd> dt nt!_GENERAL_LOOKASIDE
|
||
|
|
+0x000 ListHead : _SLIST_HEADER
|
||
|
|
+0x008 Depth : Uint2B
|
||
|
|
+0x00a MaximumDepth : Uint2B
|
||
|
|
+0x00c TotalAllocates : Uint4B
|
||
|
|
+0x010 AllocateMisses : Uint4B
|
||
|
|
+0x010 AllocateHits : Uint4B
|
||
|
|
+0x014 TotalFrees : Uint4B
|
||
|
|
+0x018 FreeMisses : Uint4B
|
||
|
|
+0x018 FreeHits : Uint4B
|
||
|
|
+0x01c Type : _POOL_TYPE
|
||
|
|
+0x020 Tag : Uint4B
|
||
|
|
+0x024 Size : Uint4B
|
||
|
|
+0x028 Allocate : Ptr32 void*
|
||
|
|
+0x02c Free : Ptr32 void
|
||
|
|
+0x030 ListEntry : _LIST_ENTRY
|
||
|
|
+0x038 LastTotalAllocates : Uint4B
|
||
|
|
+0x03c LastAllocateMisses : Uint4B
|
||
|
|
+0x03c LastAllocateHits : Uint4B
|
||
|
|
+0x040 Future : [2] Uint4B
|
||
|
|
|
||
|
|
Lookaside tables permit faster block retrieving than typical double linked
|
||
|
|
list. For this optimization lock time is really important and a single
|
||
|
|
linked list is a faster mechanism than software locking.
|
||
|
|
ExInterlockedPopEntrySList function is used to pop an entry from a single
|
||
|
|
linked list using hardware locking instruction "lock".
|
||
|
|
|
||
|
|
PPNPagedLookasideList is the lookaside table we were talking about. It
|
||
|
|
contains two lookaside lists P and L. Depth field of the GENERAL_LOOKASIDE
|
||
|
|
structure defines how many entries can be in ListHead single list. The
|
||
|
|
system updates regularly the depth using different counters. The update
|
||
|
|
algorithm is based on processor number and is different for P and L. Depth
|
||
|
|
of the P list is updated more frequently than L list as it optimizes
|
||
|
|
performances on very small blocks.
|
||
|
|
|
||
|
|
The second table depends how many processors are used and how system
|
||
|
|
managed them. Allocation system walk it if size is inferior or equal to
|
||
|
|
4080 bytes or if lookaside research failed. Even if target table can
|
||
|
|
change, it always has the same POOL_DESCRIPTOR structure. On single
|
||
|
|
processor, a variable called PoolVector is used to retrieve
|
||
|
|
NonPagedPoolDescriptor pointer. On multi processor, the
|
||
|
|
ExpNonPagedPoolDescriptor table has 16 slots containing pool descriptors.
|
||
|
|
Each processor PRCB points on a KNODE structure. A node can be linked on
|
||
|
|
more than one processor and contains a color field used as an index in
|
||
|
|
ExpNonPagedPoolDescriptor. Next figures illustrate this algorithm.
|
||
|
|
|
||
|
|
PoolVector
|
||
|
|
+------------+
|
||
|
|
| NonPaged | --------------> NonPagedPoolDescriptor
|
||
|
|
|------------+
|
||
|
|
| Paged |
|
||
|
|
+------------+
|
||
|
|
|
||
|
|
[ Figure 1 - Single processor pool descriptor ]
|
||
|
|
|
||
|
|
Processor #1
|
||
|
|
+------------+
|
||
|
|
| | ExpNonPagedPoolDescriptor
|
||
|
|
| PRCB ------\ +-------------------+
|
||
|
|
| | | /---------> SLOT #01 |
|
||
|
|
+------------+ | | | SLOT #02 |
|
||
|
|
/---------/ | | SLOT #03 |
|
||
|
|
| KNODE | | SLOT #04 |
|
||
|
|
|---> +------------+ | | SLOT #05 |
|
||
|
|
| | Proc mask | | | SLOT #06 |
|
||
|
|
| | color (01) --/ | SLOT #07 |
|
||
|
|
| | ... | | SLOT #08 |
|
||
|
|
| +------------+ | SLOT #09 |
|
||
|
|
| | SLOT #10 |
|
||
|
|
\---------\ | SLOT #11 |
|
||
|
|
Processor #2 | | SLOT #12 |
|
||
|
|
+------------+ | | SLOT #13 |
|
||
|
|
| | | | SLOT #14 |
|
||
|
|
| PRCB ------/ | SLOT #15 |
|
||
|
|
| | | SLOT #16 |
|
||
|
|
+------------+ +-------------------+
|
||
|
|
|
||
|
|
[ Figure 2 - Multiple processor pool descriptor ]
|
||
|
|
|
||
|
|
A global variable ExpNumberOfNonPagedPools defines if multi processor case
|
||
|
|
is used. It should reflect processor number but it can change between
|
||
|
|
operating system versions.
|
||
|
|
|
||
|
|
The next dump shows POOL_DESCRIPTOR structure from windbg.
|
||
|
|
|
||
|
|
kd> dt nt!_POOL_DESCRIPTOR
|
||
|
|
+0x000 PoolType : _POOL_TYPE
|
||
|
|
+0x004 PoolIndex : Uint4B
|
||
|
|
+0x008 RunningAllocs : Uint4B
|
||
|
|
+0x00c RunningDeAllocs : Uint4B
|
||
|
|
+0x010 TotalPages : Uint4B
|
||
|
|
+0x014 TotalBigPages : Uint4B
|
||
|
|
+0x018 Threshold : Uint4B
|
||
|
|
+0x01c LockAddress : Ptr32 Void
|
||
|
|
+0x020 PendingFrees : Ptr32 Void
|
||
|
|
+0x024 PendingFreeDepth : Int4B
|
||
|
|
+0x028 ListHeads : [512] _LIST_ENTRY
|
||
|
|
|
||
|
|
Queued spinlock synchronization, part of HAL library, is used to restrict
|
||
|
|
concurrency on a pool descriptor. It assures that only one thread and one
|
||
|
|
processor will access and unlink an entry from a pool descriptor. HAL
|
||
|
|
library changes on different architectures and what is a simple IRQL
|
||
|
|
raising on single processor becomes a more complex queued system on
|
||
|
|
multi-processor. For default pool descriptor, general NonPaged queued
|
||
|
|
spinlock is locked (LockQueueNonPagedPoolLock). Else, a custom queued
|
||
|
|
spinlock is created.
|
||
|
|
|
||
|
|
The third and last table is shared by processors for size superior of 4080
|
||
|
|
bytes. MmNonPagedPoolFreeListHead is also used when others tables lack
|
||
|
|
memory. It composed by 4 LIST_ENTRY each one representing a page number,
|
||
|
|
except for the last one which holds all superiors pages kept by the system.
|
||
|
|
Access to this table is guarded by general non paged queued spinlock
|
||
|
|
also called LockQueueNonPagedPoolLock. During the free procedure of a
|
||
|
|
smaller block, ExFreePoolWithTag merges it with previous and next free
|
||
|
|
blocks. It can create a block superior or equal to 1 page. In this case,
|
||
|
|
the new block is added in the MmNonPagedPoolFreeListHead table.
|
||
|
|
|
||
|
|
-----[ 3.1.3 - Allocation and free algorithms
|
||
|
|
|
||
|
|
Kernel allocation does not change that much between OS versions but its
|
||
|
|
algorithm is as hard as the userland heap one. In this part, we want to
|
||
|
|
illustrate basic behavior between tables during allocation or free
|
||
|
|
procedures. A lot of details have been thrown away such as synchronization
|
||
|
|
mechanisms. Those algorithms will help you for the technique explanation
|
||
|
|
but also understanding the basic elements of kernel allocation. Despite
|
||
|
|
kernel exploitation is not part of this paper, pool overflow is an
|
||
|
|
interesting topic that needs understanding of some part of this algorithm.
|
||
|
|
|
||
|
|
NonPaged pool allocation algorithm (ExAllocatePoolWithTag):
|
||
|
|
|
||
|
|
IF [ Size > 4080 bytes ]
|
||
|
|
[
|
||
|
|
- Call the MiAllocatePoolPages function
|
||
|
|
- Walk MmNonPagedPoolFreeListHead LIST_ENTRY table.
|
||
|
|
- Retrieve memory from hardware if necessary.
|
||
|
|
- Return memory page aligned (without header).
|
||
|
|
]
|
||
|
|
|
||
|
|
IF [ Size <= 256 bytes ]
|
||
|
|
[
|
||
|
|
- Pop entry from PPNPagedLookasideList table.
|
||
|
|
- If something is found return memory block.
|
||
|
|
]
|
||
|
|
|
||
|
|
IF [ ExpNumberOfNonPagedPools > 1 ]
|
||
|
|
- PoolDescriptor from ExpNumberOfNonPagedPools and used index
|
||
|
|
comes from PRCB KNODE color.
|
||
|
|
ELSE
|
||
|
|
- PoolDescriptor is PoolVector first entry, designed by symbol
|
||
|
|
as NonPagedPoolDescriptor.
|
||
|
|
|
||
|
|
FOREACH [ >= Size entry of PoolDescriptor.ListHeads ]
|
||
|
|
[
|
||
|
|
IF [ Entry is not empty ]
|
||
|
|
[
|
||
|
|
- Unlink entry and split it if needed
|
||
|
|
- Return memory block
|
||
|
|
]
|
||
|
|
]
|
||
|
|
|
||
|
|
- Call the MiAllocatePoolPages function
|
||
|
|
- Walk MmNonPagedPoolFreeListHead LIST_ENTRY table..
|
||
|
|
- Split it correctly to the right size
|
||
|
|
- Return new memory block
|
||
|
|
|
||
|
|
NonPaged pool free algorithm (ExFreePoolWithTag) :
|
||
|
|
|
||
|
|
IF [ MemoryBlock is page aligned ]
|
||
|
|
[
|
||
|
|
- Call the MiFreePoolPages function
|
||
|
|
- Determine block type (Paged or NonPaged)
|
||
|
|
- Depending on how many blocks are kept in
|
||
|
|
MmNonPagedPoolFreeListHead, we release it to the hardware.
|
||
|
|
]
|
||
|
|
ELSE
|
||
|
|
[
|
||
|
|
- Merge previous and next block if possible
|
||
|
|
|
||
|
|
IF [ NewMemoryBlock size <= 256 bytes ]
|
||
|
|
[
|
||
|
|
- Look at PPNPagedLookasideList entry depth and see if we
|
||
|
|
should keep it.
|
||
|
|
- We return if memory block is pushed into lookaside list
|
||
|
|
]
|
||
|
|
|
||
|
|
IF [ NewMemoryBlock size <= 4080 bytes ]
|
||
|
|
[
|
||
|
|
- Use POOL_HEADER PoolIndex variable to determine which
|
||
|
|
PoolDescriptor must be used.
|
||
|
|
- Insert it in the proper LIST_ENTRY array entry
|
||
|
|
- If anything goes well, return
|
||
|
|
]
|
||
|
|
|
||
|
|
- Depending on how many blocks are kept in
|
||
|
|
MmNonPagedPoolFreeListHead, we release it to the hardware.
|
||
|
|
]
|
||
|
|
|
||
|
|
Paged pool algorithm is very different especially for page aligned blocks.
|
||
|
|
Smaller size management should be not that far from NonPaged but in
|
||
|
|
assembly code we definitely saw that NonPaged and Paged pool are totally
|
||
|
|
separated. Once you know a little more about how NonPaged allocation works,
|
||
|
|
we can now talk about exploitation part.
|
||
|
|
|
||
|
|
---[ 3.2 - Getting code execution abusing allocation code
|
||
|
|
|
||
|
|
Our main goal is getting code execution on every allocation attempts for
|
||
|
|
NonPaged pool only. This result must be done only by changing data used by
|
||
|
|
targeted code. Our purpose is proving that kernel code can serve our
|
||
|
|
interest only by changing typical data environment. Our work is based
|
||
|
|
on a new rootkit developed to gain control over NonPaged allocation.
|
||
|
|
|
||
|
|
We start with getting code execution for allocation superior or equal
|
||
|
|
to 1 page. As we saw on previous part, it concerns the third and last
|
||
|
|
table.
|
||
|
|
|
||
|
|
-----[ 3.2.1 - Data corruption of MmNonPagedPoolFreeListHead
|
||
|
|
|
||
|
|
MmNonPagedPoolFreeListHead conserves page aligned memory blocks to speed up
|
||
|
|
memory allocation. It links held memory block using a LIST_ENTRY structure.
|
||
|
|
This structure is common and use in Windows heap library for example.
|
||
|
|
|
||
|
|
kd> dt nt!_LIST_ENTRY
|
||
|
|
+0x000 Flink : Ptr32 _LIST_ENTRY
|
||
|
|
+0x004 Blink : Ptr32 _LIST_ENTRY
|
||
|
|
|
||
|
|
MmNonPagedPoolFreeListHead access is protected by general NonPaged queued
|
||
|
|
spinlock LockQueueNonPagedPoolLock. It assures that only one thread and
|
||
|
|
processor can look and modify this structure.
|
||
|
|
|
||
|
|
So we need a way to get control over allocation and unlinking procedure
|
||
|
|
seems perfect. We can poison this linked list with a fake entry, with the
|
||
|
|
highest size possible, which unlinking will modify current executed code.
|
||
|
|
At kernel level, you can modify code as data without any protection issues.
|
||
|
|
Unlinking was used when heap exploitation started [20] but modifying code
|
||
|
|
was not possible from userland. As spinlock assures us exclusivity, there
|
||
|
|
is no risk on some race condition. The created "hook" would be dynamic and
|
||
|
|
code restored directly. Page guard protection reverse [18] shows that code
|
||
|
|
is only checked every 5 minutes. Whether a modification is found, real code
|
||
|
|
is just replaced.
|
||
|
|
|
||
|
|
This method has plenty assets but also a lot of obstacles. Let start by
|
||
|
|
enumerating all those obstacles :
|
||
|
|
|
||
|
|
- On a basic implementation of unlinking, list become unwalkable.
|
||
|
|
It breaks most utilization of the table.
|
||
|
|
- Pass through page cleaning methods and always be the first block on the
|
||
|
|
list otherwise we could miss some call.
|
||
|
|
- We break code path and sooner or later we must return as if our
|
||
|
|
hijacking has never been there and everything goes fine.
|
||
|
|
- Processor prefetch make self code modification dangerous.
|
||
|
|
|
||
|
|
Unlinking gives us 4 bytes overwriting to build an opcode and create a
|
||
|
|
redirection. In our case, we influenced current context and a register
|
||
|
|
should point to the unlinked entry. We said should point without choosing a
|
||
|
|
single register because kernel changes between versions or service packs.
|
||
|
|
As soon as we discuss context, we will stay talking about general
|
||
|
|
situations. We choose to make a jmp [reg+XX] which is FF60XX in hex.
|
||
|
|
|
||
|
|
This technique effectiveness lies on keeping the MmNonPagedPoolFreeListHead
|
||
|
|
walkable. A double linked list, as LIST_ENTRY, is walkable if Flink is
|
||
|
|
correct. Therefore we can choose an address for Flink as 0xXXXX60FF and
|
||
|
|
Blink will point to the code address. The Intel x86 architecture using
|
||
|
|
little endian our address is quite easy to found, we must check opcode
|
||
|
|
offset and discard too close possibilities. Next figure illustrates a
|
||
|
|
poisoned entry.
|
||
|
|
|
||
|
|
MmNonPagedPoolFreeListHead[i]
|
||
|
|
/------> +--------------------+
|
||
|
|
| | Flink | ---\
|
||
|
|
| |--------------------| |
|
||
|
|
| <---- | Blink | |
|
||
|
|
| +--------------------+ |
|
||
|
|
| | ... | |
|
||
|
|
| +--------------------+ |
|
||
|
|
| /-------------------------------/
|
||
|
|
| |
|
||
|
|
| | Poisoned entry
|
||
|
|
| | +--------------------+
|
||
|
|
| | | PreviousSize : - |
|
||
|
|
| | +--------------------+
|
||
|
|
| | | PoolIndex : - |
|
||
|
|
| | +--------------------+
|
||
|
|
| | | PoolType: NonPaged |
|
||
|
|
| | +--------------------+
|
||
|
|
| | | BlockSize : i |
|
||
|
|
| | +--------------------+
|
||
|
|
| | | PoolTag : - |
|
||
|
|
| \---> +--------------------+
|
||
|
|
| | Flink : 0xYYXX60FF | <--\
|
||
|
|
| |--------------------| |
|
||
|
|
| X--- | Blink : 0x80YYYYYY | |
|
||
|
|
| +--------------------+ |
|
||
|
|
| |
|
||
|
|
| /-------------------------------/
|
||
|
|
| | Fake entry (0xYYXX60FF)
|
||
|
|
| | +--------------------+
|
||
|
|
| | | PreviousSize : - |
|
||
|
|
| | +--------------------+
|
||
|
|
| | | PoolIndex : - |
|
||
|
|
| | +--------------------+
|
||
|
|
| | | PoolType: NonPaged |
|
||
|
|
| | +--------------------+
|
||
|
|
| | | BlockSize : < i |
|
||
|
|
| | +--------------------+
|
||
|
|
| | | PoolTag : - |
|
||
|
|
| |---> +--------------------+
|
||
|
|
| | | Flink : 0x80..... | ---\
|
||
|
|
| | |--------------------| |
|
||
|
|
| \---- | Blink : Poisoned | |
|
||
|
|
| +--------------------+ |
|
||
|
|
\--------------- [...] ------------/
|
||
|
|
|
||
|
|
Unlinking instruction : mov [0x80YYYYYY], 0xYYXX60FF
|
||
|
|
New Opcode after unlinking : jmp [reg+XX] (FF 60 XX)
|
||
|
|
|
||
|
|
[ Figure 3 - Poisoned double linked list ]
|
||
|
|
|
||
|
|
This figure shows a MmNonPagedPoolFreeListHead entry layout that assures
|
||
|
|
predicted unlinking and then code execution. We must maintain this layout
|
||
|
|
or we will lose our position. NonPaged blocks come from two different
|
||
|
|
virtual memory ranges. The second memory region start is stored in
|
||
|
|
MmNonPagedPoolExpansionStart. A cleaning function is called sometime to
|
||
|
|
free blocks from the expansion NonPaged pool. To avoid this cleaning, we
|
||
|
|
can use a Paged pool block locked. You can lock a memory block with the
|
||
|
|
MmProbeAndLockPages function. This lock makes described memory region as
|
||
|
|
resident. Another more discreet way is to remap a NonPaged block with the
|
||
|
|
function MmMapLockedPagesSpecifyCache. It is more discrete because this
|
||
|
|
mapping would be just before expansion NonPaged pool memory range. Using
|
||
|
|
a locked Paged pool block creates an address totally differently. A quick
|
||
|
|
look at those addresses between NonPaged ones show a clear difference.
|
||
|
|
As virtual memory is very large, it does not take too much time to find
|
||
|
|
an address like 0xYYXX60FF. We will not unlock those pages until our
|
||
|
|
technique is running.
|
||
|
|
|
||
|
|
To defeat code path issues we differentiate two different states. The first
|
||
|
|
state is when our block is selected. The second state is when our block is
|
||
|
|
unlinked. If we were able to return to the first step with our next fake
|
||
|
|
entry selected, we could continue walking code as normal. We achieve that
|
||
|
|
by using a generic approach. At IRQL equal to DISPATCH_LEVEL, we corrupt a
|
||
|
|
MmNonPagedPoolFreeListHead entry with some invalid pointers. With a hook on
|
||
|
|
the page fault handler we are capable to see first and second stages,
|
||
|
|
restore the right context each time and save context difference between
|
||
|
|
those states.
|
||
|
|
|
||
|
|
Assembly dump from MiAllocatePoolPages :
|
||
|
|
|
||
|
|
lea eax, [esi+8] ; Stage #1 esi is selected block and esi+8 its size
|
||
|
|
cmp [eax], ebx ; Check with needed size
|
||
|
|
mov ecx, esi
|
||
|
|
jnb loc_47014B
|
||
|
|
[...]
|
||
|
|
|
||
|
|
loc_47014B:
|
||
|
|
sub [esi+8], ebx
|
||
|
|
mov eax, [esi+8]
|
||
|
|
shl eax, 0Ch
|
||
|
|
add eax, esi
|
||
|
|
cmp _MmProtectFreedNonPagedPool, 0 ; Protected mode, don't care
|
||
|
|
mov [ebp+arg_4], eax
|
||
|
|
jnz short loc_47016E
|
||
|
|
mov eax, [esi] ; \ Stage #2
|
||
|
|
mov ecx, [esi+4] ; | Unlinking
|
||
|
|
mov [ecx], eax ; | procedure
|
||
|
|
mov [eax+4], ecx ; /
|
||
|
|
jmp short loc_470174
|
||
|
|
|
||
|
|
Now let's see how it works during our test technique with interrupt fault
|
||
|
|
handler (int 0xE) hooked :
|
||
|
|
|
||
|
|
lea eax, [esi+8]
|
||
|
|
; Stage #1 - Check with needed size
|
||
|
|
cmp [eax], ebx ; ----> PAGE FAULT esi = 0xAAAAAAAA | eax = esi + 8
|
||
|
|
; - We keep EIP and all registers
|
||
|
|
; - Scan all registers for 0xAAAAAAAA +/- 8
|
||
|
|
; and correct the current context. Continue.
|
||
|
|
mov ecx, esi
|
||
|
|
jnb loc_47014B
|
||
|
|
[...]
|
||
|
|
|
||
|
|
loc_47014B:
|
||
|
|
sub [esi+8], ebx
|
||
|
|
mov eax, [esi+8]
|
||
|
|
shl eax, 0Ch
|
||
|
|
add eax, esi
|
||
|
|
cmp _MmProtectFreedNonPagedPool, 0 ; Protected mode, don't care
|
||
|
|
mov [ebp+arg_4], eax
|
||
|
|
jnz short loc_47016E
|
||
|
|
mov eax, [esi] ; \ Stage #2 - Unlinking procedure
|
||
|
|
mov ecx, [esi+4] ; |
|
||
|
|
mov [ecx], eax ; | ------> PAGE FAULT ecx = 0xBBBBBBBB
|
||
|
|
; | eax = 0xCCCCCCCC
|
||
|
|
; | - Keep EIP and sub this context from
|
||
|
|
; | Stage #1 saved context
|
||
|
|
; | - Change fault registers and
|
||
|
|
; | structure pointers. Continue.
|
||
|
|
mov [eax+4], ecx ; /
|
||
|
|
jmp short loc_470174
|
||
|
|
|
||
|
|
Fault addresses 0xAAAAAAA, 0xBBBBBBBB and 0xCCCCCCCC must point on invalid
|
||
|
|
addresses to force a caught page fault. This test is made only once and
|
||
|
|
when we still have exclusivity on all processors. The int 0xE (page fault)
|
||
|
|
handler is restored just after.
|
||
|
|
|
||
|
|
This generic technique permits us to restore a valid context just before
|
||
|
|
selected block size is checked. Once we get code execution, we apply
|
||
|
|
context difference, change the current block register and then return at
|
||
|
|
first stage address. It works well because our two stages are very close,
|
||
|
|
once a selected block size is checked, unlinking is directly made.
|
||
|
|
|
||
|
|
Given examples were based on a single LIST_ENTRY of the
|
||
|
|
MmNonPagedPoolFreeListHead table but you must poison all entries. If a
|
||
|
|
given entry is empty (except for our fake blocks), the algorithm tries
|
||
|
|
next the entry. It means we will be called more than one time per
|
||
|
|
allocation. We created a mechanism to manage multiple call on a single
|
||
|
|
allocation. If the first entry is empty, the second entry is used and so
|
||
|
|
on. Then we will be called twice or more. By checking current table, we
|
||
|
|
can predict a future code execution on the same allocation and avoid
|
||
|
|
executing payload more than one time per allocation request.
|
||
|
|
|
||
|
|
Prefetch is a processor feature that retrieves more than a single
|
||
|
|
instruction from memory before it executes them. Some processor use a
|
||
|
|
complex branch prediction algorithm to fetch as much instruction as
|
||
|
|
possible. After some tests, we saw that processors invalidate code cache
|
||
|
|
when a modification occurs in cached memory addresses. Our driver supports
|
||
|
|
a case where code modification could be right after current instruction.
|
||
|
|
To achieve that we created a routine which calculates prefetch cache size
|
||
|
|
and consider it in next parts of our technique. We could also search
|
||
|
|
specifics instructions which clean prefetch cache like a far jump but it
|
||
|
|
can only be used as an option.
|
||
|
|
|
||
|
|
This technique gives us code execution for NonPaged allocation superior or
|
||
|
|
equal to 1 page. It achieves that with a stealth hook, created by kernel
|
||
|
|
code and cleaned by our routine directly after. It's far from being
|
||
|
|
perfect as those allocations are not used that much. Next part describes
|
||
|
|
how this technique can be extended to gain control over all NonPaged pool
|
||
|
|
allocations.
|
||
|
|
|
||
|
|
-----[ 3.2.2 - Expend it for every size
|
||
|
|
|
||
|
|
Others lists can not be hijacked the same way because synchronization
|
||
|
|
mechanisms are not exclusive. Changing some assembly code becomes tricky if
|
||
|
|
it can be executed by more than one thread at a time. Our method is
|
||
|
|
assuring our previous technique execution on any allocation. Once we have
|
||
|
|
control, we can find a way to retore ExAllocatePoolWithTag context with a
|
||
|
|
correct return value. We must do that without recoding a single line of
|
||
|
|
memory allocator. It is possible to create our own allocator but Windows
|
||
|
|
one is great and it will perfectly do the job for us.
|
||
|
|
|
||
|
|
During allocation, the lookaside list is checked first. It will pop an
|
||
|
|
entry and if this entry is not NULL, use it. This entry comes from
|
||
|
|
GENERAL_LOOKASIDE ListHeader field. This field structure is SLIST_HEADER.
|
||
|
|
|
||
|
|
kd> dt nt!_SLIST_HEADER .
|
||
|
|
+0x000 Alignment : Uint8B
|
||
|
|
+0x000 Next :
|
||
|
|
+0x000 Next : Ptr32 _SINGLE_LIST_ENTRY
|
||
|
|
+0x004 Depth : Uint2B
|
||
|
|
+0x006 Sequence : Uint2B
|
||
|
|
|
||
|
|
The ExInterlockedPopEntrySList function pops an entry from a SLIST_HEADER
|
||
|
|
structure. The Next field is a pointer to the next SLIST node (single
|
||
|
|
linked list). The Depth field represents how many entries are kept in the
|
||
|
|
list. ExFreePoolWithTag compare GENERAL_LOOKASIDE optimal depth with
|
||
|
|
current SLIST_HEADER depth. ExAllocatePoolWithTag does not check this
|
||
|
|
field and just looks if some entry can be popped out Next field. To stunt
|
||
|
|
allocation and free procedure on NonPaged lookaside table, we set Next
|
||
|
|
field to NULL and Depth field to 0xFFFF. This state will be preserved and
|
||
|
|
this table will not be used anymore.
|
||
|
|
|
||
|
|
Our technique expansion relies entirely on subverting how the
|
||
|
|
ExpNonPagedPoolDescriptor table is used. In the previous part, we explained
|
||
|
|
global variable ExpNumberOfNonPagedPools involvement in this process. It
|
||
|
|
is possible to expand number of NonPaged pools and then play with current
|
||
|
|
KNODE color. During allocation, the KNODE color defines which pool
|
||
|
|
descriptor is used. Then during free procedure, PoolIndex field of
|
||
|
|
POOL_HEADER keep pool descriptor color.
|
||
|
|
|
||
|
|
So we can use this nice feature to our advantage. Default KNODE color on
|
||
|
|
every processors would point on an empty pool descriptors. It will lead to
|
||
|
|
code execution using our base technique. If the function
|
||
|
|
MiAllocatePoolPages return address is not the one use for classical page
|
||
|
|
rounded allocation, we know that a smaller allocation occur. All we have
|
||
|
|
to do is switch PRCB KNODE pointer to a copy with custom color and recall
|
||
|
|
ExAllocatePoolWithTag. Everything related to allocation and block
|
||
|
|
management will be implemented as it needs to be even if it differs
|
||
|
|
between operating system versions. Returned blocks PoolIndex will point to
|
||
|
|
our own pool descriptor and free procedure, which will perfectly work. Lets
|
||
|
|
see how it will look on a single processor.
|
||
|
|
|
||
|
|
ExpNonPagedPoolDescriptor
|
||
|
|
+-------------------+
|
||
|
|
| PREVIOUS POOLDESC | <--- Kept for compatibility (0)
|
||
|
|
| EMPTY POOLDESC | <--- Default KNODE->color (1)
|
||
|
|
| -- |
|
||
|
|
| -- |
|
||
|
|
| -- |
|
||
|
|
| -- |
|
||
|
|
| -- |
|
||
|
|
| -- |
|
||
|
|
| -- |
|
||
|
|
| -- |
|
||
|
|
| -- |
|
||
|
|
| -- |
|
||
|
|
| -- |
|
||
|
|
| -- |
|
||
|
|
| -- |
|
||
|
|
| CUSTOM POOLDESC | <--- Used for our allocations (16)
|
||
|
|
+-------------------+
|
||
|
|
|
||
|
|
[ Figure 4 - Corrupted ExpNonPagedPoolDescriptor ]
|
||
|
|
[ on single processor ]
|
||
|
|
|
||
|
|
This setup is just an example and you can manage the arrangement as you
|
||
|
|
want. We could transfer previous blocks from older pool descriptors in our
|
||
|
|
own and then receive free blocks. It is also possible to use multiple pool
|
||
|
|
descriptors and so on. Beware of system pool descriptor recycling as it can
|
||
|
|
leads to strange behavior specially on multi-processor architecture.
|
||
|
|
|
||
|
|
Once we have our fresh allocated block, we must return at
|
||
|
|
ExAllocatePoolWithTag return address. MiAllocatePoolPages has been called
|
||
|
|
to retrieve a new page and fill the current pool descriptor with it. It's
|
||
|
|
obvious that we can't return normally and let page allocation occurs. On
|
||
|
|
Intel x86 architecture the stack is used to store local variables,
|
||
|
|
arguments and saved registers. The Windows compiler starts by reserving
|
||
|
|
local variable and then pushes each register before its modification.
|
||
|
|
The next figure shows our stack configuration once we have code execution.
|
||
|
|
|
||
|
|
top
|
||
|
|
+--------------------+
|
||
|
|
| Our stack elements | Restore assembly example
|
||
|
|
+--------------------+ <------ /---------------\
|
||
|
|
| | | pop ecx |
|
||
|
|
| Saved registers | | pop ebx |
|
||
|
|
| | | pop esi |
|
||
|
|
+--------------------+ | leave |
|
||
|
|
| | | retn 0Ch |
|
||
|
|
| | \---------------/
|
||
|
|
| | |
|
||
|
|
| | |
|
||
|
|
| Stack variables | |
|
||
|
|
| | |
|
||
|
|
| | |
|
||
|
|
| | |
|
||
|
|
+--------------------+ [new stack level]
|
||
|
|
| Saved EBP | |
|
||
|
|
+--------------------+ |
|
||
|
|
| Return Address | |
|
||
|
|
+--------------------+ |
|
||
|
|
| | |
|
||
|
|
| Function arguments | |
|
||
|
|
| | |
|
||
|
|
+--------------------+ <--------------/
|
||
|
|
bottom
|
||
|
|
|
||
|
|
[ Figure 5 - Stack context after code execution ]
|
||
|
|
[ ~ small blocks case ~ ]
|
||
|
|
|
||
|
|
The restore assembly part shows correct assembly in current function which
|
||
|
|
perfectly restores the context. It does not correspond of the first series
|
||
|
|
of pop instruction before return. There is an important risk that some
|
||
|
|
register has not been pushed yet. It is possible to deduce the pushed
|
||
|
|
register number by looking at function prologue when stack variables are
|
||
|
|
reserved. In the Windows compiler, it's quite simple and we can easily
|
||
|
|
calculate the pushed register number. A simple disassembly analysis on
|
||
|
|
needed pop register number does the job. It must be done for
|
||
|
|
MiAllocatePoolPages and ExAllocatePoolWithTag. We change the return
|
||
|
|
address stored in the stack and go to the deduced MiAllocatePoolPages
|
||
|
|
address. Last step is setting eax register for the return value. Both
|
||
|
|
functions return a value and preserve eax value. Our analyzer is dynamic
|
||
|
|
and registers each pop and its register. That why we can restore the
|
||
|
|
proper context even if it changes between versions.
|
||
|
|
|
||
|
|
The Windows compiler is really easy to predict and does not create too
|
||
|
|
strange assembly organization. This technique is theoretically possible
|
||
|
|
on every assembly code that follow stdcall specification. The approach
|
||
|
|
could differ on others compilers.
|
||
|
|
|
||
|
|
---[ 3.3 Exploit our position
|
||
|
|
|
||
|
|
This article present a way of subverting the Windows kernel by modifying
|
||
|
|
only data. No function pointers, no static hooking or others classical
|
||
|
|
technique. It could exempt us of any other explanation. But it would not
|
||
|
|
be complete without some concrete examples. I personally believe that the
|
||
|
|
only limitation here is imagination.
|
||
|
|
|
||
|
|
-----[ 3.3.1 Generic stack redirection
|
||
|
|
|
||
|
|
Allocation occurs in so many places that you must rely on known context
|
||
|
|
and functions. Once everything is setup and before releasing exclusivity,
|
||
|
|
some stack redirection database can be created.
|
||
|
|
|
||
|
|
The first way to do this is calling a handler if stack backtracing
|
||
|
|
reveals a specific function. Stack backtracing shows only return addresses
|
||
|
|
and not which function call it. Debuggers resolve those functions by deep
|
||
|
|
analysis or symbol checking. Implementing those features would take too
|
||
|
|
much time. So it's better to target a specific return address on
|
||
|
|
ExAllocatePoolWithTag stack frame. It will definitely improve check speed.
|
||
|
|
To do that, we indicates to our stack redirection API that we target a
|
||
|
|
specific function. Then launch a normal call or procedure that will lead to
|
||
|
|
our function. Every allocation during this time will show important
|
||
|
|
backtrace stacks.
|
||
|
|
|
||
|
|
Let say, we target an IRP and we know which function handles it by looking
|
||
|
|
at IRP dispatch table. We also know by reversing that it will allocate a
|
||
|
|
NonPaged block. Launching an I/O request, our API could register some
|
||
|
|
NonPaged call and recognize later.
|
||
|
|
|
||
|
|
In the wild, it will call the appropriate handler with sub context
|
||
|
|
information. Sometimes getting a context is not enough. The second way
|
||
|
|
stays on same principles but modifies the stack to assure our handler is
|
||
|
|
called once the function end. Efficiency depends on what is your target
|
||
|
|
and how you modifying it.
|
||
|
|
|
||
|
|
-----[ 3.3.2 Userland process code injection
|
||
|
|
|
||
|
|
This technique can be also used to inject code in userland to subvert
|
||
|
|
trusted applications. NonPaged allocation occurs a lot in kernel mode and
|
||
|
|
it happens in every process. Some kernel drivers like win32k.sys call
|
||
|
|
userland many times. This call is achieve by the function
|
||
|
|
KeUserModeCallback [35]. It modifies userland stack to switch temporarily
|
||
|
|
for a call in userland. Available functions are limited by a table.
|
||
|
|
|
||
|
|
Userland injection from kernel should not be resident and only concern
|
||
|
|
known trusted application as browsers. Injection can be done on
|
||
|
|
explorer.exe as well to launch an hidden instance of a trusted program.
|
||
|
|
KeUserModeCallback algorithm can be easily remade or copied then
|
||
|
|
relocated.Redirection table could be subverted to redirect the call. We
|
||
|
|
can also think about exploiting userland calls. It does not make any sense
|
||
|
|
to add checks on those available functions.
|
||
|
|
|
||
|
|
--[ 4 - Detection
|
||
|
|
|
||
|
|
This article does not try to convince you that subverting IDT or
|
||
|
|
allocation mechanism using advanced technique is the future. Most detection
|
||
|
|
tools only indicate if a rookit may or may not be in this computer. It has
|
||
|
|
pains identifying which module is responsible. It detects antivirus or
|
||
|
|
firewall as rootkits. A protection layout could detect itself as a rootkit
|
||
|
|
because it does everything a rootkit does and so does not ask it to block
|
||
|
|
or uninstall a rootkit. Rootkit papers demonstrate so many great ways to
|
||
|
|
easily bypass those protections. But we don't see much those techniques in
|
||
|
|
the wild, simply because rootkits don't need them for the moment.
|
||
|
|
|
||
|
|
Detect software behavior modification could be part of a Verifiable
|
||
|
|
Operating System [36]. It will involve basic checks on known memory
|
||
|
|
structures. Checks integrity of LIST_ENTRY structures and correct them if
|
||
|
|
needed. We can blame rootkit protections as much as we want but detecting
|
||
|
|
rootkits on a closed operating system is almost impossible. Gives more
|
||
|
|
information for kernel components will certainly leads to more
|
||
|
|
sofisticates attacks. In the other hand, it could reduce attack surface.
|
||
|
|
It is specially true on a defence oriented operating system. Next
|
||
|
|
protection improvements should come from the operating system itself.
|
||
|
|
|
||
|
|
Now that there are hardware improvements for virtualisation, such as
|
||
|
|
hypervisors, there will be extensions to hardware to detect and protect
|
||
|
|
against rootkits. It offers a real control on operating system behavior
|
||
|
|
without advanced research on kernel layout. Some protections techniques
|
||
|
|
that were impossible to implement in Windows environment like PAX, could
|
||
|
|
rely on those hardware features. Our techniques could be detected by
|
||
|
|
registering and monitoring some specific events on the processor. It is
|
||
|
|
possible today to do that but performance issues are important.
|
||
|
|
|
||
|
|
Our attacks could be blocked using targeted protection such as signatures.
|
||
|
|
An attack is defined as how many times it takes to create a generic
|
||
|
|
protection. In this area, Patchguard is an important improvement.
|
||
|
|
|
||
|
|
--[ 5 - Conclusion
|
||
|
|
|
||
|
|
This papers techniques were made to show that elegant software hijacking
|
||
|
|
can still evades most protections and avoid any performance issues or
|
||
|
|
unstable behaviors. Even though, these techniques are hardly reliable and
|
||
|
|
should be considered only as a technical proof of concept. New protections
|
||
|
|
are not efficient enough or present. They do not represent a threat for
|
||
|
|
a rootkit which targets millions of computers. Reversing is an important
|
||
|
|
tool in improving software rootkits techniques. Detecting that a rootkit
|
||
|
|
is present should not be enough. A protection which cannot uninstall a
|
||
|
|
rootkit or prevent infection is useless. Drivers signatures was a good
|
||
|
|
idea as it was designed to stop current infections entries. But infection
|
||
|
|
prevention includes local kernel exploitation. Generic detection of those
|
||
|
|
attacks would need an important improvement in anti-rootkits protections
|
||
|
|
and operating system design.
|
||
|
|
|
||
|
|
--[ 6 - References
|
||
|
|
|
||
|
|
[1] Holy Father, Invisibility on NT boxes, How to become unseen on Windows
|
||
|
|
NT (Version: 1.2)
|
||
|
|
http://vx.netlux.org/lib/vhf00.html
|
||
|
|
|
||
|
|
[2] Holy Father, Hacker Defender
|
||
|
|
https://www.rootkit.com/vault/hf/hxdef100r.zip
|
||
|
|
|
||
|
|
[3] 29A
|
||
|
|
http://vx.netlux.org/29a
|
||
|
|
|
||
|
|
[4] Greg Hoglund, NT Rootkit
|
||
|
|
https://www.rootkit.com/vault/hoglund/rk_044.zip
|
||
|
|
|
||
|
|
[5] fuzen_op, FU
|
||
|
|
http://www.rootkit.com/project.php?id=12
|
||
|
|
|
||
|
|
[6] Peter Silberman, C.H.A.O.S, FUto
|
||
|
|
http://uninformed.org/?v=3&a=7
|
||
|
|
|
||
|
|
[7] Eeye, Bootroot
|
||
|
|
http://research.eeye.com/html/tools/RT20060801-7.html
|
||
|
|
|
||
|
|
[8] Eeye, Pixie
|
||
|
|
http://research.eeye.com/html/papers/download/
|
||
|
|
eEyeDigitalSecurity_Pixie%20Presentation.pdf
|
||
|
|
|
||
|
|
[9] Joanna Rutkowska and Alexander Tereshkin, Blue Pill project
|
||
|
|
http://bluepillproject.org/
|
||
|
|
|
||
|
|
[10] Frank Boldewin, A Journey to the Center of the Rustock.B Rootkit
|
||
|
|
http://www.reconstructer.org/papers/
|
||
|
|
A%20Journey%20to%20the%20Center%20of%20the%20Rustock.B%20Rootkit.zip
|
||
|
|
|
||
|
|
[11] Frank Boldewin, Peacomm.C - Cracking the nutshell
|
||
|
|
http://www.reconstructer.org/papers/
|
||
|
|
Peacomm.C%20-%20Cracking%20the%20nutshell.zip
|
||
|
|
|
||
|
|
[12] Stealth MBR rootkit
|
||
|
|
http://www2.gmer.net/mbr/
|
||
|
|
|
||
|
|
[13] EP_X0FF and MP_ART, Unreal.A, bypassing modern Antirootkits
|
||
|
|
http://www.rootkit.com/newsread.php?newsid=647
|
||
|
|
|
||
|
|
[14] AK922 : Bypassing Disk Low Level Scanning to Hide File
|
||
|
|
http://rootkit.com/newsread.php?newsid=783
|
||
|
|
|
||
|
|
[15] CardMagic and wowocock, DarkSpy
|
||
|
|
http://www.fyyre.net/~cardmagic/index_en.html
|
||
|
|
|
||
|
|
[16] pjf, IceSword
|
||
|
|
http://pjf.blogone.net
|
||
|
|
|
||
|
|
[17] Gmer
|
||
|
|
http://www.gmer.net/index.php
|
||
|
|
|
||
|
|
[18] Pageguard papers (Uniformed) :
|
||
|
|
|
||
|
|
- Bypassing PatchGuard on Windows x64 by skape & Skywing
|
||
|
|
http://www.uninformed.org/?v=all&a=14&t=sumry
|
||
|
|
|
||
|
|
- Subverting PatchGuard Version 2 by Skywing
|
||
|
|
http://www.uninformed.org/?v=all&a=28&t=sumry
|
||
|
|
|
||
|
|
- PatchGuard Reloaded: A Brief Analysis of PatchGuard Version 3 by Skywing
|
||
|
|
http://www.uninformed.org/?v=all&a=38&t=sumry
|
||
|
|
|
||
|
|
[19] Greg Hoglund, Kernel Object Hooking Rootkits (KOH Rootkits)
|
||
|
|
http://www.rootkit.com/newsread.php?newsid=501
|
||
|
|
|
||
|
|
[20] Windows Heap Overflows - David Litchfield
|
||
|
|
http://www.blackhat.com/presentations/win-usa-04/bh-win-04-litchfield/
|
||
|
|
bh-win-04-litchfield.ppt
|
||
|
|
|
||
|
|
[21] Bypassing Klister 0.4 With No Hooks or Running a Controlled
|
||
|
|
Thread Scheduler by 90210 - 29A
|
||
|
|
http://vx.netlux.org/29a/magazines/29a-8.rar
|
||
|
|
|
||
|
|
[22] Microsoft, Debugging Tools for Windows
|
||
|
|
http://www.microsoft.com/whdc/devtools/debugging/default.mspx
|
||
|
|
|
||
|
|
[23] Kad, Phrack 59, Handling Interrupt Descriptor Table for fun and profit
|
||
|
|
http://phrack.org/issues.html?issue=59&id=4#article
|
||
|
|
|
||
|
|
[24] Wikipedia, Southbridge
|
||
|
|
http://en.wikipedia.org/wiki/Southbridge_(computing)
|
||
|
|
|
||
|
|
[25] Wikipedia, Northbridge
|
||
|
|
http://en.wikipedia.org/wiki/Northbridge_%28computing%29
|
||
|
|
|
||
|
|
[26] The NT Insider, Stop Interrupting Me -- Of PICs and APICs
|
||
|
|
http://www.osronline.com/article.cfm?article=211 (login required)
|
||
|
|
|
||
|
|
[27] Russinovich, Solomon, Microsoft Windows Internals, Fourth Edition
|
||
|
|
Chapter 3. System Mechanisms -> Trap Dispatching
|
||
|
|
|
||
|
|
[28] MSDN, KeyboardClassServiceCallback
|
||
|
|
http://msdn2.microsoft.com/en-us/library/ms793303.aspx
|
||
|
|
|
||
|
|
[29] Clandestiny, Klog
|
||
|
|
http://www.rootkit.com/vault/Clandestiny/Klog%201.0.zip
|
||
|
|
|
||
|
|
[30] Alexander Tereshkin, Rootkits: Attacking Personal Firewalls
|
||
|
|
www.blackhat.com/presentations/bh-usa-06/BH-US-06-Tereshkin.pdf
|
||
|
|
|
||
|
|
[31] MSDN, NdisMIndicateReceivePacket
|
||
|
|
http://msdn2.microsoft.com/en-us/library/aa448038.aspx
|
||
|
|
|
||
|
|
[32] Subverting VistaTM Kernel For Fun And Profit by Joanna Rutkowska
|
||
|
|
http://invisiblethings.org/papers/
|
||
|
|
joanna%20rutkowska%20-%20subverting%20vista%20kernel.ppt
|
||
|
|
|
||
|
|
[33] Vista RC2 vs. pagefile attack by Joanna Rutkowska
|
||
|
|
http://theinvisiblethings.blogspot.com/2006/10/
|
||
|
|
vista-rc2-vs-pagefile-attack-and-some.html
|
||
|
|
|
||
|
|
[34] Russinovich, Solomon, Microsoft Windows Internals, Fourth Edition
|
||
|
|
Chapter 7. Memory Management -> System Memory Pools
|
||
|
|
|
||
|
|
[35] KeUserModCallback ref - "Ring0 under WinNT/2k/XP" by Ratter - 29A
|
||
|
|
http://www.illmob.org/files/text/29a7/Articles/29A-7.003
|
||
|
|
|
||
|
|
[36] Joanna Rutkowska - Towards Verifiable Operating Systems
|
||
|
|
http://theinvisiblethings.blogspot.com/2007/01/
|
||
|
|
towards-verifiable-operating-systems.htm
|