Backdoors, Trojans and
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
Back Doors

An alternative entryway


No fancy authentication needed
Maintains access on a system


Usually access is needed initially
Still works when front door is closed
Back Doors



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
Back Doors Melded into
Trojan Horses



Application-level Trojan Horse
Backdoors
Traditional RootKits
Kernel-level RootKits
Application-Level Trojan
Horse Backdoor Tools
Adds a separate application to the
system
 Made up of a server and client part



server is installed on victims machine
client is installed on attackers machine
Victim must install the server portion
 Once installed the attacker “owns” the
victims machine

Application-Level Trojan
Horse Backdoor Tools







Log Keystrokes
Gather system information
Get passwords from the SAM database
Control the file system
Edit the registry
Control applications and services
Redirect Packets
Application-Level Trojan
Horse Backdoor Tools

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
Application-Level Trojan
Horse Backdoor Tools

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
Defenses against ApplicationLevel Trojan Backdoors




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
SQL Server Hack!
Hidden Backdoors

Attacker takes over your system and
installs a backdoor to ensure future
access



Backdoor
listens
on port
ABC
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
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


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


http://www.phenoelit.de/stuff/cd00r.c
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 –
Sniffer
analyzes traffic
Cd00r in Action
destined just
Server
SYN to port X
SYN to port Y
for this
machine,
looking for
ports X, Y, Z
SYN to port Z
Connection to root shell on port 5002

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
After Z is
received,
activate
temporary
listener 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 inSniffer listens
for traffic
Action
destined for
DNS
WWW server
WWW
Internet
Firewall



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
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

Traditional RootKits




Replaces key system components
Less detectable than application-level
Trojan Horse Backdoors
Traditionally focus on UNIX systems
Root access is required initially
Traditional 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
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 wtmp or utmp
files for the backdoor user
Traditional RootKits

Some other programs replaced:

du - shows free disk space


find - finds files


Hides attacker’s files
ifconfig - shows status of interfaces


RootKits hides space used by attacking tools
masks promiscuous mode
ls - shows contents of directories

Hides attacker’s files
Traditional RootKits

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
Defending against Traditional
RootKits



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
Defending against Traditional
RootKits



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
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



Advantages


Need to protect the DB
Need to protect the vulnerable executables
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
Kernel-Level RootKits




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
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
Kernel-Level RootKits

Some Kernel-level RootKits are:




Knark (Linux)
Adore (Linux)
Plasmoid’s Solaris Loadable Kernel
Module (Solaris)
The Windows NT kernel-level RootKit
(Windows)
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
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 Backdoors
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
Evil Program
good
good
good
good
program program program program
Kernel
Trojan
login
Trojan Trojan
ps
ifconfig
Kernel
good
tripwire
Kernel-level RootKit
good
login
good
ps
Kernel
good
good
ifconfig tripwire
Trojan
Kernel Module
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


Multi-platform




Many buffer overflows, etc.
Zero-Day exploits


Win, Linux, Solaris, BSD, AIX, HP-UX…
Multi-exploit


Spread, steal, erase, etc.
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