Friday, 29 April 2016
Exploiting kaspersky klim5.sys driver + Happy pack #2 PDF Print
Written by Rubén   
Wednesday, 21 January 2009

Interested in happy pack #2? this time is focused on the Microsoft Office suite.
  • Fingerprinting remote machines

  • Dynamic content generation in documents for using in targeted attacks

  • 0day

Do not hesitate to contact me if you are interested. For legal companies and institutions ONLY. Please, no vuln-info see-u-ckers. No gangs.

Let's talk about an interesting flaw I found months ago in Kaspersky's NDIS engine. This driver is in charge of intercepting when a packet arrives or is sent. (Un)fortunately a simple user-mode program can modify some callbacks in klim5.sys to point to a user-mode controlled address, just by sending a specially crafted IOCTL request.So... we face a local privilege escalation.Again.

.text:00011774 cmp ecx, 80052110h ; IOCTL
.text:0001177A jnz short loc_117E9
.text:0001177C cmp ebp, 10h
.text:0001177F jnb short loc_1178E ; FLAW
.text:00011781 push 10h
.text:00011783 mov [esp+14h+Irp], 0C0000023h
.text:0001178B pop ebx
.text:0001178C jmp short loc_117E9
.text:0001178E ;
.text:0001178E loc_1178E: ; CODE XREF: sub_11730+4Fj
.text:0001178E push offset SpinLock ; SpinLock
.text:00011793 push offset dword_140A8 ; int
.text:00011798 push edi ; int
.text:00011799 call sub_11604 ; Flaw
.text:0001179E add edi, 8
.text:000117A1 push offset dword_140B8 ; SpinLock
.text:000117A6 or eax, 0FFFFFFFFh
.text:000117A9 sub eax, [edi]
.text:000117AB push offset dword_140B0 ; int
.text:000117B0 push edi ; int
.text:000117B1 mov [edi], eax
.text:000117B3 call sub_11604

and finally

.text:000115CB push [ebp+arg_0]
.text:000115CE call dword ptr [edi+8] ; Controlled

What it is interesting in this flaw is the way of exploiting it. NDIS calls are "context-free" by definition, so when a packet arrives or is sent, the NDIS call can be invoked in an arbitrary thread context. Therefore, the callback we are modifying could be invoked in any other thread than ours. There is an intrinsic race condition in the exploit.

Let's imagine a scenario where the exploit modifies the callback to point to the address of its shellcode at 0x401000. However,before the callback reachs our code in the exploit's context, another thread triggers the callback and therefore, that address can contain anything, note that also the memory referenced must be paged in since the callback is dispatched at DISPATCH_LEVEL. To solve this scenario we must follow the steps below:
  • Boost the priority of our exploit process/thread
  • Search common bytes in ring3 which are being shared by all the processes,the modify them(in the exploit's context) to point to our shellcode whilst in other processes that same address should point to a "ret 4" instruction. (NtDeleteKey+n).
  • The shellcode must modify the callbacks to point to a "ret 4" address that can be accessed in Ring0(ExGetSharedWaitersCount+n).

In this way the system keeps stable.
Let's see

While running the exploit

After running the exploit

I notified kaspersky about this flaw several months ago. This flaw is fixed in the latest KIS 2009 and according to them it was fixed in KAV for WorkStation yesterday, I cannot confirm it.

You can download the k-plugin for Kartoffel here

Last Updated ( Monday, 26 January 2009 )
< Prev   Next >