Sign in to follow this  
Followers 0
Venom

LKM Rookits

10 posts in this topic

Linux Kernel Module Rootkits are virtually undetectable unless already released and recognised by rootcheck. Long story short, by loading a kernel module, you avoid any MD5 checksum failure, along with being able to hide yourself as you login as root.

You can also hide things from all users (including root) because the rootkit works on such a low level.

Of course, you already have to have root access to the system. This is for advanced, low-level track covering if you were to compromise a system and want to keep full root access.

For my example, I'm going to use Enye LKM Rootkit. This is from their website :

ENYELKM is a LKM Rootkit for Linux x86 with kernels v2.6.x.

It puts salts inside system_call and sysenter_entry handlers. So

it does not modify sys_call_table, or IDT content.

What the rootkit does:

- Copy enyelkm.ko file to '/etc/.enyelkmHIDE^IT.ko', so when LKM

is loaded that file will be hidden.

- Add the string 'insmod /etc/.enyelkmHIDE^IT.ko' between the marks

# and # to /etc/rc.d/rc.sysinit file. So

when LKM is loaded these lines will be hidden (it is explained after).

- Load LKM with 'insmod /etc/.enyelkmHIDE^IT.ko'.

- Try modify date of /etc/rc.d/rc.sysinit file with date from

/etc/rc.d/rc, and set +i attribute to /etc/.enyelkmHIDE^IT.ko

with touch and chattr commands.

* Hide files, directories and processes:

Every file, directory and process with substring 'HIDE^IT' on

his name is hidden. Processes with gid = 0x489196ab are hidden

too. Reverse shell (after is explained) run with gid = 0x489196ab, so

it and every process launched from it is hidden.

* Hide chunks inside a file:

Every byte between the marks is hidden:

(marks included)

#

text to hide

#

* Get local root:

Doing: # kill -s 58 12345

you get id 0.

* Hide module to 'lsmod':

LKM is auto hidden.

*This rootkit has no file to search. The detection is done at a low level

by system call comparison.

Because it is a kernel module, it can be reprogrammed. *nix pro's out there, go ahead and have a blast :)

Please do give feedback/suggestions.

enyelkm.en.v1.1.tar.tar

Edited by Venom
-1

Share this post


Link to post
Share on other sites

and the problem? you have to have root privledges to install it :) Also some of their methods wouldn't even work on all Linux systems

-1

Share this post


Link to post
Share on other sites

For 2.4.x kernels I found Adore to be quite usefull. And LKMs can be detected: StJude/StMichael

at least on 2.4.x kernels, haven't found anything for 2.6.x kernels yet.

0

Share this post


Link to post
Share on other sites
For 2.4.x kernels I found Adore to be quite usefull.  And LKMs can be detected: StJude/StMichael

at least on 2.4.x kernels, haven't found anything for 2.6.x kernels yet.

I know they can be detected. There's just not an "Anti-LKM" type program that I'm aware of, meaning the user has to go consciously look (on newer kernels).

And someone in IRC today brought up the topic of microcode rootkits, so I'm looking into that and thinking of starting a project...

And as for obtaining root first on the system... That's not that difficult (depending on the system of course, sometimes its hard, sometimes its easy), but I'm definately not in the interest of just handing some n00b a rootkit he could use without root... Sorry....

=\

I just thought some people might find this stuff useful.

0

Share this post


Link to post
Share on other sites
and the problem? you have to have root privledges to install it :)  Also some of their methods wouldn't even work on all Linux systems

Of course you have to have root privileges!

I've been batting around the idea of writing a custom rootkit for lab experimentation.Since I've never written one, it would be an interesting project. If anyone has any wicked ideas for that, I'd like to hear them.

0

Share this post


Link to post
Share on other sites

In IRC someone gave me the idea to write something like that in microcode. While this is processor-architecture specific (intel/amd/motorolla), it is more subtle and harder to notice. Its also at an even lower level than LKM's.

0

Share this post


Link to post
Share on other sites

You can easily mitigate MOST rootkit attempts (if your system has been hacked that far) just by using GrSecurity.

GrSecurity.org

grsec.jpg

0

Share this post


Link to post
Share on other sites

Thanks to Venom for the interesting post!

It's not hard to detect this particular rootkit from userland. The rootkit modifies the code of your kernel's system_call function (the function that handles system call interrupts). I grabbed a Debian GNU/Linux "virtual appliance" off the vmware site and ran this little experiment:

Grep the address and length of your system_call function out of your System.map file and convert the numbers to base-10. Use dd to read the system_call code out of /dev/kmem. Read it a couple of times and compare. This code should not change during kernel runtime.


Script started on Sun 12 Nov 2006 02:50:54 AM EST
debian:~# grep system_call /boot/System.map-2.6.8-2-386
c0105f64 T system_call
debian:~# dd if=/dev/kmem of=/tmp/dump-1.out bs=1 skip=3222298468 count=44
44+0 records in
44+0 records out
44 bytes transferred in 0.002690 seconds (16357 bytes/sec)
debian:~# dd if=/dev/kmem of=/tmp/dump-2.out bs=1 skip=3222298468 count=44
44+0 records in
44+0 records out
44 bytes transferred in 0.001938 seconds (22703 bytes/sec)
debian:~# diff /tmp/dump-1.out /tmp/dump-2.out
debian:~#

Next, load the rootkit and dump the code again. The code will not match your earlier dumps, indicating your kernel has been modified by the rootkit.


debian:~# /sbin/insmod enyelkm.en.v1.1/enyelkm.ko
debian:~# dd if=/dev/kmem of=/tmp/dump-3.out bs=1 skip=3222298468 count=44
44+0 records in
44+0 records out
44 bytes transferred in 0.004923 seconds (8938 bytes/sec)
debian:~# diff /tmp/dump-2.out /tmp/dump-3.out
Binary files /tmp/dump-2.out and /tmp/dump-3.out differ
debian:~#
Script done on Sun 12 Nov 2006 02:52:24 AM EST

Of course, dd uses the read system call, so if the rootkit's author wanted to, he could have made read lie about the state of the system_call code just like he made it lie about the contents of files. Then we'd have to try a different strategy probably involving our own LKM to do detection, and the arms race would proceed another step.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0