Objectives About Us Sponsors News Past Events Contact Us
Login G-TEC CC Mirror Forums Links

 

 

SIG^2 Vulnerability Research Advisory

Disabling Sebek Win32 Client by Direct Service Table Restoration

by Tan Chew Keong
Release Date: 17 July 2004

Summary

Sebek is a data capture tool designed to capture the attacker's activities on a honeypot, without the attacker (hopefully) knowing it. It has two components. The first is a client that runs on the honeypots, its purpose is to capture all of the attackers activities (keystrokes, file uploads, passwords) then covertly send the data to the server. The second component is the server which collects the data from the honeypots. The server normally runs on the Honeywall gateway.

Sebek works by hooking several native APIs in kernel-space to log all console outputs and to hide itself. However, an implementation flaw allows a malicious program to disable Sebek's console logging and hiding ability. A malicious program can achieve this by restoring the running kernel's SDT ServiceTable with direct writes to \device\physicalmemory.

 
Tested System

Win32 Sebek 2.1.5 on Win2K SP4.

 
Details

Sebek prevents itself from being detected by hooking several native APIs in kernel-space. Hooking is performed in the module SEBEK.sys by replacing entries within the SDT ServiceTable. Sebek logs all console events by hooking ZwReadFile and ZwWriteFile. Hooking these two native APIs allows Sebek to trap any read/write request to the console and to send them to the logging server.

Using our KProcCheck rootkit-detection tool, we were able to determine that Sebek hooks the following native APIs.

C:\>kproccheck -t
KProcCheck Version 0.1 Proof-of-Concept by SIG^2 (www.security.org.sg)

Checks SDT for Hooked Native APIs

ZwClose                    18 SEBEK.sys [F729A092]
ZwCreateFile               20 SEBEK.sys [F729A98C]
ZwCreateKey                23 SEBEK.sys [F729AD10]
ZwEnumerateKey             3C SEBEK.sys [F729AE02]
ZwEnumerateValueKey        3D SEBEK.sys [F729AA50]
ZwOpenFile                 64 SEBEK.sys [F729A8E6]
ZwOpenKey                  67 SEBEK.sys [F729AD88]
ZwQueryDirectoryFile       7D SEBEK.sys [F729A4CC]
ZwQuerySystemInformation   97 SEBEK.sys [F729A5F0]
ZwReadFile                 A1 SEBEK.sys [F7299CF0]
ZwRequestWaitReplyPort     B0 SEBEK.sys [F7299F14]
ZwSecureConnectPort        B8 SEBEK.sys [F7299FE6]
ZwWriteFile                ED SEBEK.sys [F7299D48]

Number of Service Table entries hooked = 13

 
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 Sebek. The console logging ability of Sebek is effectively disabled after we restored the SDT to its original state. In other words, Sebek can no longer log any console outputs and its driver file is no longer hidden from directory listings.

SDTrestore restores the SDT ServiceTable by writting directly to \device\physicalmemory. Hence, it works entirely in user-space and do not need to load a kernel driver. The following screen dump shows SDTrestore in action.

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

ZwClose                    18 --[hooked by unknown at F729A092]--
ZwCreateFile               20 --[hooked by unknown at F729A98C]--
ZwCreateKey                23 --[hooked by unknown at F729AD10]--
ZwEnumerateKey             3C --[hooked by unknown at F729AE02]--
ZwEnumerateValueKey        3D --[hooked by unknown at F729AA50]--
ZwOpenFile                 64 --[hooked by unknown at F729A8E6]--
ZwOpenKey                  67 --[hooked by unknown at F729AD88]--
ZwQueryDirectoryFile       7D --[hooked by unknown at F729A4CC]--
ZwQuerySystemInformation   97 --[hooked by unknown at F729A5F0]--
ZwReadFile                 A1 --[hooked by unknown at F7299CF0]--
ZwRequestWaitReplyPort     B0 --[hooked by unknown at F7299F14]--
ZwSecureConnectPort        B8 --[hooked by unknown at F7299FE6]--
ZwWriteFile                ED --[hooked by unknown at F7299D48]--

Number of Service Table entries hooked = 13

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 18 to 8044F9A8
[+] Patched SDT entry 20 to 80497EF9
[+] Patched SDT entry 23 to 804B2483
[+] Patched SDT entry 3C to 804B292D
[+] Patched SDT entry 3D to 804B2A70
[+] Patched SDT entry 64 to 80498755
[+] Patched SDT entry 67 to 804B2E28
[+] Patched SDT entry 7D to 80498541
[+] Patched SDT entry 97 to 80493B5B
[+] Patched SDT entry A1 to 804993B7
[+] Patched SDT entry B0 to 8049D577
[+] Patched SDT entry B8 to 80433F0A
[+] Patched SDT entry ED to 80499755

 
Workarounds

  1. Hook ZwOpenSection to prevent access to \device\physicalmemory
  2. Relocate SDT.ServiceTable to another location.
  3. Hook ZwLoadDriver and ZwSetSystemInformation (with SystemLoadAndCallImage) to prevent loading of kernel modules.

 
Disclosure Timeline

23 Jun 04 - Vulnerability Discovered
24 Jun 04 - Initial Author Notification (no reply)
10 Jul 04 - Second Author Notification (no reply)
17 Jul 04 - Public Release

 

Contacts

For further questions and enquries, email them to the following.

Overall-in-charge: Tan Chew Keong


Updated: 17/7/2004
webmaster@security.org.sg