SIG^2 G-TEC - Kerio Personal Firewall's Application Launch Protection Can Be Disabled by Direct Service Table Restoration

Summary

Kerio Personal Firewall 4 (KPF4) is a state-of-the-art personal firewall that helps users restrict how their computers exchange data with other computers on the Internet or local network. KPF has an Application Security feature that allows the user to restrict the execution of programs on his system. KPF prevents malicious code from spawning processes on the user's system by prompting the user for action whenever an unknown/new or modified program is being executed.

KPF's Application Security feature is implemented by hooking several native APIs in kernel-space by modifying entries within the SDT ServiceTable. This means that a malicious program can disable this security feature by restoring the running kernel's SDT ServiceTable with direct writes to \device\physicalmemory. This vulnerability affects only the execution protection feature of KPF4, the firewall feature of KPF4 remains intact.

Details

Kerio Personal Firewall's Application Security (execution protection) feature is implemented by hooking several native APIs in kernel-space. Hooking is performed by the module fwdrv.sys by replacing entries within the SDT ServiceTable. KPF prevents malicious code from spawning processes on the user's system by prompting the user for action whenever an unknown/new or modified program is being executed.

Using our KProcCheck rootkit-detection tool, we were able to determine that KPF's Application Security feature is implemented by hooking the following native APIs.

KProcCheck Version 0.1 Proof-of-Concept by SIG^2 (www.security.org.sg)

Checks SDT for Hooked Native APIs

ZwCreateFile               20 \SystemRoot\system32\drivers\fwdrv.sys [BFBD3830]
ZwCreateProcess            29 \SystemRoot\system32\drivers\fwdrv.sys [BFBD3380]
ZwCreateThread             2E \SystemRoot\system32\drivers\fwdrv.sys [BFBD35E0]
ZwResumeThread             B5 \SystemRoot\system32\drivers\fwdrv.sys [BFBD3630]

Number of Service Table entries hooked = 4

On Win2k/XP, it is possible to restore the running kernel's SDT ServiceTable to its original state since a complete copy of the SDT ServiceTable exists within the kernel file ntoskrnl.exe. Our SDTrestore rootkit-defense tool demonstrates how this could be done. Using our SDTrestore tool, we were able to restore the SDT ServiceTable of a system running KPF4. The execution protection feature offered by KPF4 is effectively disabled after we restored the SDT to its original state. With the feature disabled, KPF4 will no longer prompt the user for actions when an unknown/new or modified program is being executed.

In order to exploit this vulnerability, an attacker must first convince the user to execute a malicious program as Administrator. This vulnerability affects only the execution protection feature of KPF4, the firewall feature of KPF4 remains intact.

C:\>sdtrestore
SDTrestore Version 0.1 Proof-of-Concept by SIG^2 G-TEC (www.security.org.sg)

KeServiceDescriptorTable                8046DFA0
KeServiceDecriptorTable.ServiceTable    804742B8
KeServiceDescriptorTable.ServiceLimit   248

ZwCreateFile               20 --[hooked by unknown at BFBD3830]--
ZwCreateProcess            29 --[hooked by unknown at BFBD3380]--
ZwCreateThread             2E --[hooked by unknown at BFBD35E0]--
ZwResumeThread             B5 --[hooked by unknown at BFBD3630]--

Number of Service Table entries hooked = 4

WARNING:  THIS IS EXPERIMENTAL CODE.  FIXING THE SDT MAY HAVE GRAVE
CONSEQUENCES, SUCH AS SYSTEM CRASH, DATA LOSS OR SYSTEM CORRUPTION.
PROCEED AT YOUR OWN RISK.  YOU HAVE BEEN WARNED.

Fix SDT Entries (Y/N)? : y

[+] Patched SDT entry 20 to 80497EF9
[+] Patched SDT entry 29 to 804A9212
[+] Patched SDT entry 2E to 804A89AD
[+] Patched SDT entry B5 to 804AA598

Vendor Response

The vulnerability requires Administrator privileges to exploit, that same person could merely disable or uninstall the firewall, making the vulnerability not that critical.

Disclosure Timeline

26 Jun 04 - Vulnerability Discovered
27 Jun 04 - Initial Vendor Notification (no reply)
15 Jul 04 - Second Vendor Notification
17 Jul 04 - Reply from Second Level Support (no definite date given for fix)
22 Jul 04 - Another reply from Second Level Support (no definite date given for fix)
30 Aug 04 - Posted another notification on support webpage (received reply that vulnerablity is not critical)
02 Sep 04 - Public Release