Execution Path Analysis: Finding Kernel Rootkits

Full Version: Execution Path Analysis: Finding Kernel Rootkits

GovernmentSecurity.org > System Security > Linux & Unix Systems

Rigpa

Dec 24 2004, 01:15 AM

searched the forum on here but didn't get a hit so i dare put this here now :
==Phrack Inc.==

Volume 0x0b, Issue 0x3b, Phile #0x0a of 0x12

|=------=[ Execution path analysis: finding kernel based rootkits ]=-----=|
|=-----------------------------------------------------------------------=|
|=----------=[ Jan K. Rutkowski <jkrutkowski@elka.pw.edu.pl> ]=----------=|

--[ Introduction

Over the years mankind has developed many techniques for masking presence
of the attacker in the hacked system. In order to stay invisible modern
backdoors modify kernel structures and code, causing that nobody can trust
the kernel. Nobody, including IDS tools...

In the article I will present a technique based on counting executed
instructions in some system calls, which can be used to detect various
kernel rootkits. This includes programs like SucKIT or prrf (see [SUKT01]
and [PALM01]) which do not modify syscall table. I will focus on Linux
kernel 2.4, running on Intel 32-bit Family processor (ia32).

Also at the end of the article the PatchFinder source code is included - a
proof of concept for described technique.

I am not going to explain how to write a kernel rootkit. For details I send
reader to the references. However I briefly characterize known techniques
so their resistance to presented detection method can be described.

--[ Background

Lets take a quick look at typical kernel rootkits. Such programs must solve
two problems: find a way to get into the kernel and modify the kernel in a
smart way. On Linux the first task can be achieved by using Loadable Kernel
Modules (LKM) or /dev/kmem device.

----[ getting into the kernel

Using LKM is the easiest and most elegant way to modify the running kernel.
It was probably first discussed by halflife in [HALF97]. There are many
popular backdoors which use LKM (see [KNAR01], [ADOR01], [PALM01]). However
this technique has a weak point - LKM can be disabled on some systems.

When we do not have LKM support we can use technique, developed by Silvio
Cesare, which uses /dev/kmem to access directly kernel memory (see
[SILV98]). There is no easy work-around for this method, since patching
do_write_mem() function is not sufficient, as it was recently showed by
Guillaume Pelat (see [MMAP02]).

read the whole shebang here

This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.


Help - Search - Member List - Calendar Full Version: Execution Path Analysis: Finding Kernel Rootkits GovernmentSecurity.org > System Security > Linux & Unix Systems Rigpa Dec 24 2004, 01:15 AM searched the forum on here but didn't get a hit so i dare put this here now : ==Phrack Inc.== Volume 0x0b, Issue 0x3b, Phile #0x0a of 0x12 \|=------=[ Execution path analysis: finding kernel based rootkits ]=-----=\| \|=-----------------------------------------------------------------------=\| \|=----------=[ Jan K. Rutkowski <jkrutkowski@elka.pw.edu.pl> ]=----------=\| --[ Introduction Over the years mankind has developed many techniques for masking presence of the attacker in the hacked system. In order to stay invisible modern backdoors modify kernel structures and code, causing that nobody can trust the kernel. Nobody, including IDS tools... In the article I will present a technique based on counting executed instructions in some system calls, which can be used to detect various kernel rootkits. This includes programs like SucKIT or prrf (see [SUKT01] and [PALM01]) which do not modify syscall table. I will focus on Linux kernel 2.4, running on Intel 32-bit Family processor (ia32). Also at the end of the article the PatchFinder source code is included - a proof of concept for described technique. I am not going to explain how to write a kernel rootkit. For details I send reader to the references. However I briefly characterize known techniques so their resistance to presented detection method can be described. --[ Background Lets take a quick look at typical kernel rootkits. Such programs must solve two problems: find a way to get into the kernel and modify the kernel in a smart way. On Linux the first task can be achieved by using Loadable Kernel Modules (LKM) or /dev/kmem device. ----[ getting into the kernel Using LKM is the easiest and most elegant way to modify the running kernel. It was probably first discussed by halflife in [HALF97]. There are many popular backdoors which use LKM (see [KNAR01], [ADOR01], [PALM01]). However this technique has a weak point - LKM can be disabled on some systems. When we do not have LKM support we can use technique, developed by Silvio Cesare, which uses /dev/kmem to access directly kernel memory (see [SILV98]). There is no easy work-around for this method, since patching do_write_mem() function is not sufficient, as it was recently showed by Guillaume Pelat (see [MMAP02]). read the whole shebang here This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.