1. I have edited and added material.
Rootkits
CIS 413
This presentation is an amalgam of presentations by Mark Michael, Randy Marchany and Ed Skoudis.
I have edited and added material.
Dr. Stephen C. Hayne

2. Traditional RootKits Replaces key system components
Less detectable than application-level Trojan Horse Backdoors
Traditionally focus on UNIX systems
Root access is required initially

3. Traditional RootKits On Windows systems… On UNIX systems…
RootKits Replace Dynamic Link Libraries or alters the system
On UNIX systems…
RootKits replace /bin/login with a backdoor version of /bin/login

4. Traditional RootKits
When an attacker enters the backdoor password access is given to the system
Backdoor password still works if other passwords are changed
Login is not recorded in log files for the backdoor user

5. Traditional RootKits Some other programs replaced:
du - shows free disk space
RootKits hides space used by attacking tools
find - finds files
Hides attacker’s files
ifconfig - shows status of interfaces
masks promiscuous mode
ls - shows contents of directories

6. Traditional RootKits “Original” Linux RootKit 5 (lrk5)
written by Lord Somer
one of the most full-featured RootKits
includes Trojan versions of the following:
chfn, chsh, crontab, du, find, ifconfig, inetd, killall, login, ls, netstat, passwd, pidof, ps, rshd, syslogd, tcpd, top, sshd, and su

7. Defending against Traditional RootKits
Remember root-level access is needed to install a RootKit…
Use “echo *” command to look for changes
Get a program to scan /bin/login and see if it has been corrupted
Use a File Integrity Checker such as Tripwire
Save hashes on read-only media

8. Tripwire Available from www.tripwire.org
First of the file integrity checkers
Unix and Windows versions available
Network capable versions available
Useful in finding trojan programs
The integrity checker class of tools are most useful in finding rootkits on a system. Tripwire is the one of the first file integrity checkers. Basically, tripwire compares file signatures against previous tripwire runs in order to determine what files have changed. There are 2 important things to remember when using this tool. First, you must run tripwire just before your system goes into production. This establishes a baseline database and you must place this database in some protected area, usually another system or media. Second, you should make periodic tripwire runs to maintain a current database. If you run tripwire infrequently then your output file will be fairly large.
Commercial versions of tripwire now have a remote management facility that will allow you to run tripwire on multiple machines and collect the data from the runs to a central site.

9. Tripwire
Generates a “signature” for each file based on checksums and other characteristics.
These signatures are stored in a database file that should be kept offline.
This is the baseline.
If you use tripwire properly, you should be able to quickly find and isolate trojan programs that have been installed on your systems by hackers. Kernel module attacks are about the only threat to tripwire if you use it properly.

10. Tripwire List of files to check: tw.config
All files in a directory will be checked.
Can prune directories from the check step.
Can examine just the directory and nothing else.
Can check by access time but not recommended since you’ll get a report of everything that changed. Everything!
Tripwire lets you decide which files should be checked. Obviously, you don’t want to check EVERY file on the system since there are temporary files that change constantly. It is good practice to check the system binaries and directories.

11. Tripwire To initialize the DB: tripwire –initialize
Update DB interactively: tripwire -interactive
Non-interactive DB update: tripwire – update <FN>

12. This is an example of Tripwire output
This is an example of Tripwire output. The right arrow points to the column that says what it thought the file’s signature should be. The left arrow points to what it is on the target system. Just because a file shows up in this report doesn’t mean there is a problem. The /etc/.mnttab.lock file is a temporary file and you would expect it to change over time. /etc/inetd.conf, on the other hand, is a critical system file and any changes to it should be well documented in your changelog. If you can’t account for a change, assume the worst.

13. Security Configuration Management
Video – Open Source
Video – Proprietary
Choose “Before and After Views”

14. Tripwire Advantages Security Issues Disadvantages
Simple interface, good choice of crypto hash functions, good all-around tool
Security Issues
How to protect DBs…?
Need to protect tripwire executables?
Disadvantages
Kernel mod attacks, initial config takes quite some time to customize, no network security
Protecting the Tripwire database is the most important item on your checklist. This usually means storing a copy of the file offline either on tape or CD.

15. Kernel-Level RootKits
Trojan Horse becomes the Kernel
Most difficult to detect
Gives the attacker complete control of the underlying system
Nothing on the system can be trusted

16. Kernel-Level RootKits
Most common feature is execution redirection
Instead of changing other programs to hide files, the kernel hides them
Kernel may also hide processes that are running
Port usage is often masked

17. Kernel-Level RootKits
Some early Kernel-level RootKits are:
Knark (Linux)
Adore (Linux)
Plasmoid’s Solaris Loadable Kernel Module (Solaris)
The Windows NT kernel-level RootKit (Windows)

18. Kernel-Level RootKits
Implemented with Loadable Kernel Modules (LKM)
LKM is used to extend the capabilities of the system only for some UNIX systems
LKM makes it easy!
To install the Knark RootKit type:
“insmod knark.o,”
no reboot necessary

19. KNARK Background Written by Creed Released in 1999
Versions exist for Linux 2.2 and 2.4 kernels
Very popular in ‘script kiddie’ community

20. KNARK Capabilities Hide/Unhide files or directories
Hide TCP/UDP connections
Execution Redirection
Unauthenticated privilege escalation via the rootme program within knark
Ability to change UID/GID of a running process
Unauthenticated, privileged remote execution daemon
Kill –31 to hide a running process

21. Installing KNARK KNARK IS installed as a Loadable Kernel Module (LKM)
System must have LKM enabled in order to be able to load KNARK
Can be defeated if LKM is disabled, HOWEVER, updating system becomes much more complicated
The KNARK rootkit has an additional LKM module to hide the presence of KNARK from the insmod (installed module) command.

22. What does KNARK Change?
KNARK modifies the system call table (sys_call_table) within kernel memory by redirecting some system calls (sys_read, sys_getdents) to malicous system calls written by CREED.
These new malicious system calls function as normal except in certain circumstances.

23. What does KNARK change?

24. What does KNARK Change?
Can no longer trust the output of the system calls?
Very difficult to detect rootkits such as KNARK using conventional methods
System utility files (ls, ps) are not modified
Kernel Output to system utility files IS modified.

25. Detecting KNARK
Cyptographic Checksums of system utilities will NOT change when KNARK is installed
May be possible to take cryptographic checksum of selected region of kernel in order to detect rootkit modification of kernel (StMichael)
Can detect presence of KNARK type rootkits by examining sys_call_table

26. Detecting KNARK
The file /boot/System.map is created when system is initially compiled
/boot/System.map contains correct address of kernel system calls
/boot/system map can be archived or retrieved from a known good system for comparison
Must have Superuser (ROOT) privilege in order to read /dev/kmem (kernel memory)

27. Detecting KNARK using the kern_check program
Developed by Samhain labs
GPL (‘free’) software
Compares /boot/System.map file against the system call table in kernel memory
Will not work against later versions of Red Hat Linux 2.4 or the Linux 2.6 kernel

28. KNARK Summary
KNARK is a very powerful tool that was very popular with ‘script kiddies’
Very difficult to detect with conventional methods
Can no longer trust system output once kernel is compromised
Other kernel rootkits can defeat kern_check program (SuckIT)

29. Rootkit Summary
Prevent hackers from gaining root access in order to prevent rootkits from being installed
Must check systems on a periodic basis for rootkit exploits
Current advice for a rootkitted system: Wipe out files and re-install operating system.
Is it possible to re-establish trust on a Rootkited System?

30. Trojan Horse / Rootkit Kernel Kernel Kernel
Type of Trojan horse backdoor
Characteristics
Analogy
Example tools in this category
Application-Level Trojan Horse Backdoor
A separate application runs on the system
An attacker adds poison to your soup.
Sub7, BO2K, Tini, etc.
Traditional RootKits
Critical Operating System components are replaced.
An attacker replaces your potatoes with poison ones
Lrk6, T0rnkit, etc.
Kernel-Level RootKits
Kernel is patched.
An attacker replaces your tongue with a poison one.
Knark, adore, Kernel Intrusion System, rootkit.com, etc.
Application-level
Traditional RootKit
Kernel-level RootKit
Evil Program
good
login
good ps
good
ifconfig
good
tripwire
Trojan
login
Trojan ps
Trojan
ifconfig
good
tripwire
good
program
good
program
good
program
good
program
Kernel
Trojan
Kernel Module
Kernel
Kernel