Jump to content


Photo
- - - - -

LKM Rookits


  • Please log in to reply
9 replies to this topic

#1 Venom

Venom

    SUPR3M3 31337 Mack Daddy P1MP

  • Members
  • 365 posts
  • Location:919

Posted 07 April 2006 - 10:28 AM

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.

Attached Files


Edited by Venom, 07 April 2006 - 11:06 AM.


#2 jedibebop

jedibebop

    Dangerous free thinker

  • Members
  • 1,935 posts

Posted 07 April 2006 - 01:16 PM

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

#3 Hiryu

Hiryu

    SUP3R 31337 P1MP

  • Members
  • 261 posts

Posted 07 April 2006 - 02:07 PM

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.

#4 Venom

Venom

    SUPR3M3 31337 Mack Daddy P1MP

  • Members
  • 365 posts
  • Location:919

Posted 07 April 2006 - 08:59 PM

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.

View Post


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.

#5 j4mes

j4mes

    SUPR3M3 31337 Mack Daddy P1MP

  • Members
  • 485 posts
  • Location:World Tour 2008

Posted 09 April 2006 - 11:20 AM

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

View Post


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.

#6 Venom

Venom

    SUPR3M3 31337 Mack Daddy P1MP

  • Members
  • 365 posts
  • Location:919

Posted 09 April 2006 - 01:26 PM

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.

#7 Elzair

Elzair

    SUPR3M3 31337 Mack Daddy P1MP

  • Members
  • 310 posts

Posted 10 April 2006 - 12:30 PM

What about writing a rootkit for an intermediate step between those two steps. What about a bootloader rootkit?

#8 Venom

Venom

    SUPR3M3 31337 Mack Daddy P1MP

  • Members
  • 365 posts
  • Location:919

Posted 10 April 2006 - 12:33 PM

Good idea, thanks. :)

#9 chillmaster

chillmaster

    SUP3R 31337

  • Members
  • 165 posts

Posted 10 November 2006 - 01:55 PM

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

GrSecurity.org

Posted Image

#10 notyourtim

notyourtim

    SUP3R 31337

  • Members
  • 176 posts

Posted 12 November 2006 - 02:33 AM

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.




BinRev is hosted by the great people at Lunarpages!