Detecting Application Level Rootkits

The best method for detecting application-based rootkits is ongoing use of Tripwire and other checksum utilities. On initial install, Tripwire creates a database of all sensitive files including their size, time, dates, and checksum. This database is periodically checked against the current system on a schedule that you determine. Tripwire will alert you when any anomalies occur between the database and your current system. Tripwire is able to detect changes in the binaries because it essentially contains its own copy of "trusted" systems administration tools. This will not work against kernel-based rootkits because Tripwire calls still pass through the system call table and kernel for processing.

If you did not implement Tripwire when you first installed your operating system (before it was placed online), then your best detection method is to place "trusted" copies of utilities such as "ps", "ls", and "netstat" on a floppy or CD and use them to check the integrity of your system.

Manual file inspections can also provide insight into the health of your system. A good method is to execute "strings" on any suspicious file and look for unusual characteristics. For instances, a strings of "ps" once t0rn is installed contains: /usr/src/.puta/.1proc (the well known "hidden" directory for this rootkit). A similar example is demonstrated in with a strings of netstat.

Clean copy of netstat:

/proc/net
No usable address families found.
%02X-
[NONE SET]
/proc/net/unix
unix
unspec
out of virtual memory
%d.%d.%d
Routing table for 'ddp' not yet supported.

T0rn trojaned copy of netstat:

/proc/net
No usable address families found.
%02X-
[NONE SET]
/proc/net/unix
unix
unspec
out of virtual memory
%d.%d.%d
Routing table for 'ddp' not yet supported.
/usr/src/.puta/.1addr

Strings of "nethide" distributed with Knark 2.4.3 contains "Have you really loaded knark.o?!" Even after being "stripped", the backdoor contains: dup2, socket, accept, bind, and listen (all indicators of a program used to establish network connections).

In general, the first place to start looking for rootkits is the "startup" scripts directory. This is where most rookits implant themselves to ensure a presence. On Linux, this is located in /etc/rc.d/init.d. Here you want to verify that only valid services are being started on boot. Attackers typically add additional lines in existing scripts or create new scripts all together. You should also examine /etc/rc.d/rc0.d - rc6.d. Every single file in these directories should be a link to a valid startup script in /etc/rc.d/init.d. If they are not, then you have trouble.

On Solaris, the startup scripts directory is /etc/rcS.d - /etc/rc6.d. Examine these directories just the same as you would on Linux.

Following inspection of startup scripts, it is proper to run checksums of most files on the system. There are numerous utilities to aid in the automation of checksum verification including: Tripwire, RPM, sfpDB.