Title : Stealth Hooking: another way to subvert the Windows kernel

Author : Mxatone and IvanLeFou

==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