Backdoors, Trojans and 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

An alternative entryway No fancy authentication needed

Maintains access on a system Usually access is needed initially Still works when front door is closed

BBackack D Doorsoors

An attacker with back door access “owns” the system

Attackers might make the system more secure to keep ownership

The attacker does the work of the administrator

BBackack D Doorsoors

Application-level Trojan Horse Backdoors

Traditional RootKits Kernel-level RootKits

BBackack D Doors oors MMelded into elded into

TTrojanrojan H Horsesorses

Adds a separate application to the systemMade up of a server and client part

server is installed on victims machine client is installed on attackers machine

Victim must install the server portionOnce installed the attacker “owns” the

victims machine

AApplication-pplication-LLevel evel TTrojanrojan HHorse orse BBackdoor ackdoor TTools ools

Log Keystrokes Gather system information Get passwords from the SAM database Control the file system Edit the registry Control applications and services Redirect Packets

AApplication-pplication-LLevel evel TTrojanrojan HHorse orse BBackdoor ackdoor TTools ools

Application redirection Any DOS application can be spawned useful for setting up command-line backdoors

Multimedia control View files in a browser Hidden mode Encryption between client and server

AApplication-pplication-LLevel evel TTrojanrojan HHorse orse BBackdoor ackdoor TTools ools

Plug-ins: Streaming video from server machine More encryption methods

Blowfish, CAST-256, IDEA, Serpent, RC6 Stronger security than a lot of commercial

products! Stealthier methods for transport

AApplication-pplication-LLevel evel TTrojanrojan HHorse orse BBackdoor ackdoor TTools ools

Most Anti-virus programs will notice and remove the tools mentioned

Update virus definitions regularly Don’t run programs downloaded from

untrusted sources Don’t auto-run ActiveX controls

DDefenses against efenses against AApplication-pplication-

LLevel evel TTrojan rojan BBackdoors ackdoors

Hidden Backdoors Attacker takes over your system

and installs a backdoor to ensure future access

Backdoor listens, giving shell access How do you find a backdoor

listener? Sometimes, they are discovered by

noticing a listening port Nmap port scan across the network Running "netstat –na" locally Running lsof (UNIX) or Inzider

(Windows)

Network

Backdoorlistenson portABC

SQL Server Hack!

Sniffing Backdoors Who says a backdoor has to wait listening

on a port? Attackers don't want to get caught

They are increasingly using stealthy backdoors A sniffer can gather the traffic, rather than

listening on an open port Non-promiscuous sniffing backdoors

Grab traffic just for one host Promiscuous sniffing backdoors

Grab all traffic on the LAN

Non-Promiscuous Backdoor – Cd00r

Written by FX http://www.phenoelit.de/stuff/cd00r.c

Includes a non-promiscuous sniffer Gathers only packets destined for the single target

machine Several packets directed to specific ports

(where there is no listener) will trigger the backdoor

Sniffer grabs packets, not a listener on the ports Backdoor root shell starts to listen on TCP port

5002 only when packets arrive to the trigger ports

Non-Promiscuous Backdoor – Cd00r in Action

The idea has been extended to eliminate even port 5002

Netcat can push back a command shell from server, so no listener ever required

Connection goes from server back to client

ServerSYN to port X

Sniffer analyzes traffic destined just for this machine, looking for ports X, Y, ZSYN to port Y

SYN to port Z

After Z is received, activate temporary listener on port 5002

Connection to root shell on port 5002

Promiscuous Backdoor

Can be used to help throw off an investigation

Attacker sends data for destination on same network

But the backdoor isn't located at the destination of the backdoor traffic

Huh? How does that work?

Promiscuous Backdoor in Action

Backdoor is located on DNS server All packets sent to WWW server DNS server backdoor sniffs promiscuously

In switched environment, attacker may use ARP cache poisoning

Confusing for investigators

FirewallFirewall

DNSDNS

WWWWWW

Internet

Sniffer listens for traffic destined forWWW server

Sniffing Backdoor Defenses

Prevent attacker from getting on system in the first place (of course)

Know which processes are supposed to be running on the system

Especially if they have root privileges! Not easy, but very important Beware of stealthy names (like "UPS" or

"SCSI") Look for anomalous traffic Look for sniffers

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

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

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 wtmp or utmp files for the backdoor user

TTraditionalraditional R RootootKKitsits

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

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

Try harder to stop attackers from getting root access

Remember root-level access is needed to install a RootKit

Use “echo *” command to look for changes

DDefending against efending against TTraditional raditional

RRootootKKitsits

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

Tripwire

Available from www.tripwire.org First of the file integrity checkers Unix and NT versions available

Network capable versions available Academic version is free.

Commercial versions are not. Useful in finding trojan programs

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. Latest threat involves dynamic exec

redirection. This is part of the newer Kernel Module Rootkits.

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 Security Issues

Need to protect the DB Need to protect the vulnerable executables

Advantages Simple interface, good choice of crypto hash

functions, good all-around tool Disadvantages

Kernel mod attacks, initial tw.config takes some time to customize, NT version is good but costs $$$, no network security

Makes the Kernel the Trojan Horse 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

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

Some 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

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

KNARK Background

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

kernels Very popular in ‘script kiddie’

community

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

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.

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.

What does KNARK change?

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.

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

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)

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

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)

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?

Trojan Horse BackdoorsType 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

Here Come the Worms! Compromising systems one-by-one can be

such a chore Worms are attack tools that spread across a

network, moving from host to host exploiting weaknesses

Worms automate the process Take over systems Scan for new vulnerable systems Self-replicate by moving across the network to

another vulnerable system Each instance of a worm is a “segment”

2001: Year of the Worm? In 2001, we saw:

Ramen L10n Cheese Sadmind/IIS Code Red and Code Red II Nimda

To date, worms haven’t been nearly as nasty as they could be

Most damage is a result of worm resource consumption

New generations of worms arrive every 2 to 6 months

Coming Soon - Super Worms

Be on the lookout for very nasty new worms Multi-functional

Spread, steal, erase, etc. Multi-platform

Win, Linux, Solaris, BSD, AIX, HP-UX… Multi-exploit

Many buffer overflows, etc. Zero-Day exploits

Just discovered; no patch available Polymorphic Metamorphic

We’ve seen many of these pieces, but no one has rolled them all together… yet!

Worm Defenses

Buffer overflow defenses help a lot here Rapidly deploy patches Anti-virus solutions

At the desktop… …AND at the mail server …AND at the file server

Incident response capabilities, linked with network management