rootkits

27
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

Upload: elani

Post on 24-Jan-2016

30 views

Category:

Documents


0 download

DESCRIPTION

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. T raditional R oot K its. Replaces key system components Less detectable than application-level Trojan Horse Backdoors - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Rootkits

Rootkits

CIS 413This presentation is an amalgam of presentations by

Mark Michael, Randy Marchany and Ed Skoudis.I have edited and added material.

Dr. Stephen C. Hayne

Page 2: Rootkits

Replaces key system components Less detectable than application-level

Trojan Horse Backdoors Traditionally focus on UNIX systems Root access is required initially

TTraditionalraditional R RootootKKitsits

Page 3: Rootkits

On Windows systems… RootKits Replace Dynamic Link

Libraries or alters the system On UNIX systems…

RootKits replace /bin/login with a backdoor version of /bin/login

TTraditionalraditional R RootootKKitsits

Page 4: 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

TTraditionalraditional R RootootKKitsits

Page 5: 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

Hides attacker’s files

TTraditionalraditional R RootootKKitsits

Page 6: 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

TTraditionalraditional R RootootKKitsits

Page 7: 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

DDefending against efending against TTraditional raditional

RRootootKKitsits

Page 8: Rootkits

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

Page 9: Rootkits

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.

Page 10: Rootkits

Security Configuration Management

Video – Open Source

Video – Proprietary Choose “Before and After Views”

Page 11: Rootkits

Tripwire Advantages

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

Page 12: 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

KKernelernel-L-Levelevel R RootootKKitsits

Page 13: 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

KKernelernel-L-Levelevel R RootootKKitsits

Page 14: 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)

KKernelernel-L-Levelevel R RootootKKitsits

Page 15: 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

KKernelernel-L-Levelevel R RootootKKitsits

Page 16: Rootkits

KNARK Background

Written by Creed Released in 1999 Versions exist for Linux 2.2 and 2.4

kernels Very popular in ‘script kiddie’

community

Page 17: Rootkits

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

Page 18: Rootkits

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.

Page 19: Rootkits

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.

Page 20: Rootkits

What does KNARK change?

Page 21: Rootkits

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.

Page 22: Rootkits

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

Page 23: Rootkits

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)

Page 24: Rootkits

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

Page 25: Rootkits

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)

Page 26: Rootkits

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?

Page 27: Rootkits

Trojan Horse / RootkitType 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.Traditional RootKit

Kernel

Trojan

login

Trojan

ps

Trojan

ifconfig

good

tripwire

Kernel-level RootKit

Kernel

good

login

good

ps

good

ifconfig

good

tripwire

Trojan

Kernel Module

Application-level

Kernel

Evil Program

good

program

good

program

good

program

good

program