Hi,

Some time ago Johan Walles  asked in this list about replacing Unhide
with Unhide.rb claiming Unhide.rb is 'the same but more fast and with
better diagnostics '. Finally, Rkhunter added support to use both
Unhide.rb and Unhide.

Now, is time for the facts.

Probably you would know Jynx, one rootkit that has been published
recently 
http://packetstormsecurity.org/files/105893/Jynx-Kit-Userland-Rootkit.html
this type of rootkits are the most usual because kernel rootkits are
so complicated to develop and maintain (the kernel is changing so
fast...)

First of all, its not true that Unhide.rb implements same technics as
Unhide, Unhide.rb only performs syscalls and proc tests, and Unhide
performs also brute and reverse techniques. Let's compare both pieces
of software, playing with Jynx in a real scenario:

I have used this version of Unhide.rb
http://bazaar.launchpad.net/~walles/unhide.rb/trunk/download/head:/unhide.rb-20090408053406-2fmzq8pjbq04avdc-1/unhide.rb
which appears to be the latest one:

[ 1 ] Design

This kind of rootkits depends on injecting a shared lib in every
process, if you check the Unhide's README, we suggest to compile
Unhide in static mode:


// Compiling
// ---------

gcc --static unhide.c -o unhide

gcc --static unhide-tcp.c -o unhide-tcp

gcc -Wall -O2 --static -pthread unhide-linux26.c -o unhide-linux26

So, by default, Unhide its inmune to these types of rootkits.

Unhide.rb cannot be compiled in static because it depends of ruby
interpreter and ruby binary is shipped compiled in non static mode.

For these tests we will compile Unhide deliberately insecurely in
non-static mode just to test both Unhides in similar conditions.

[ 2 ] Syscall tests

I have infected a Fedora 11 with Jynx and launch a hidden nc in a hidden bash:

[campus@localhost ~]$ ./nc -l 9000

As you can see we cannot see this process if we execute a ps as root

[root@localhost ~]# ps aux | grep -i nc
[root@localhost ~]#

We are going to use Unhide.rb to search hidden processes:

[root@localhost unhide.rb]# ./unhide.rb
Scanning for hidden processes...
ps and sysinfo() process count mismatch:
 ps: 141 processes
 sysinfo(): 143 processes
Suspicious PID 1616:
 Not seen by ps
 Seen by getsid()
 Seen by getpgid()
 Seen by getpriority()
 Seen by sched_getparam()
 Seen by sched_getaffinity()
 Seen by sched_getscheduler()
 Seen by sched_rr_get_interval()
Suspicious PID 1654:
 Not seen by ps
 Seen by getsid()
 Seen by getpgid()
 Seen by getpriority()
 Seen by sched_getparam()
 Seen by sched_getaffinity()
 Seen by sched_getscheduler()
 Seen by sched_rr_get_interval()

And now, we will check it with Unhide:

[root@localhost unhide-20110113]# ./unhide-linux26 sys
Unhide 20110113
http://www.unhide-forensics.info
[*]Searching for Hidden processes through getpriority() scanning

Found HIDDEN PID: 1616  Exe: "/bin/bash"

Found HIDDEN PID: 1654  Exe: "/home/campus/nc"

[*]Searching for Hidden processes through getpgid() scanning

Found HIDDEN PID: 1616  Exe: "/bin/bash"

Found HIDDEN PID: 1654  Exe: "/home/campus/nc"

[*]Searching for Hidden processes through getsid() scanning

Found HIDDEN PID: 1616  Exe: "/bin/bash"

Found HIDDEN PID: 1654  Exe: "/home/campus/nc"

[*]Searching for Hidden processes through sched_getaffinity() scanning

Found HIDDEN PID: 1616  Exe: "/bin/bash"

Found HIDDEN PID: 1654  Exe: "/home/campus/nc"

[*]Searching for Hidden processes through sched_getparam() scanning

Found HIDDEN PID: 1616  Exe: "/bin/bash"

Found HIDDEN PID: 1654  Exe: "/home/campus/nc"

[*]Searching for Hidden processes through sched_getscheduler() scanning

Found HIDDEN PID: 1616  Exe: "/bin/bash"

Found HIDDEN PID: 1654  Exe: "/home/campus/nc"

[*]Searching for Hidden processes through sched_rr_get_interval() scanning

Found HIDDEN PID: 1616  Exe: "/bin/bash"

Found HIDDEN PID: 1654  Exe: "/home/campus/nc"

[*]Searching for Hidden processes through kill(..,0) scanning

Found HIDDEN PID: 1616  Exe: "/bin/bash"

Found HIDDEN PID: 1654  Exe: "/home/campus/nc"

[*]Searching for Hidden processes through  comparison of results of system calls

[*]Searching for Hidden processes through sysinfo() scanning

HIDDEN Processes Found: 2       sysinfo.procs = 143   ps_count = 142

As you can see, both tools catch the two hidden processes (bash and
nc) but Unhide uses one more syscall (in following sections we will
discuss the reporting ...)

[ 3 ] Proc test

Unhide.rb has a /proc test but its unable to catch hidden processes
with this test, Unhide has more deeper tests using more options (stat,
chdir, readdir, opendir and readdir)

[root@localhost unhide-20110113]# ./unhide-linux26 procall
Unhide 20110113
http://www.unhide-forensics.info
[*]Searching for Hidden processes through /proc stat scanning

[*]Searching for Hidden processes through /proc chdir scanning

Found HIDDEN PID: 1616  Exe: "/bin/bash"

Found HIDDEN PID: 1654  Exe: "/home/campus/nc"

[*]Searching for Hidden processes through /proc opendir scanning

[*]Searching for Hidden thread through /proc/pid/task readdir scanning

As you can see in our /proc tests we can catch the hidden process using chdir

[ 4 ] Reporting

Unhide.rb is claiming to achieve better reports about hidden processes
but truth is its only prints the hidden PID, Unhide shows exactly
which command is asociated to this PID, given more critical
information about the compromise.

[ 5 ] Final words

I think the question is not about to replace Unhide with Unhide.rb,
the question is why leave the user the option to choose a less secure
by desing, less deeper, less efective and less informative option.

Cheers

------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________
Rkhunter-users mailing list
Rkhunter-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/rkhunter-users

Reply via email to