Post on 16-Dec-2015
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?
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!