Backtracking Intrusions
Introduction
 Rapidly increasing frequency of computer
intrusions
 Common routines for system administrators
(1) Understand how an intruder gained access to
the system
(2) Identify the damage inflicted on the system
(3) Fix the vulnerability; undo the damage
 This paper presents BackTracker, a tool for
(1)
How to detect an intrusion
 TripWire

Detect a modified system file
 Firewall

Detect port scans, denial-of-service attacks
 Sandboxing tool

Notice unusual patterns of system calls
Find how the compromise took place
 System/network logs and disk states



Unexpected output
Deleted or forgotten attack toolkits on disk
File modification dates
 Limitations


Logs show only application-specific info
(HTTP, login)
Show little about what occurred after the initial
compromise
Find how the compromise took place
 More limitations


Network logs may contain encrypted data
Disk images may contain useful info about the
final state, not a complete history of what
transpired during the attack
BackTracker
 Identifies chains of events, leading to a
quicker identification of the vulnerability
 Logs system calls
 Induces dependencies between OS objects
(e.g., processes, files)
 Provides helpful info for most attacks
 Two components


Online: event logging
Offline: event visualization
Design of Backtracker
 Goal: reconstruct a timeline of events that
occur in an attack
 Example

Apache web server (httpd) creates a shell
(bash), downloads an executable, and runs
the executable using a different group identity
Process
File
Socket
Detection point
Fork event
Read/write event
Alternatives
 Application-level logs

Provide no information about attacker’s own
programs
 Network-level logs

Useless for encrypted data stream
 Low-level event logs

Useful information cannot be extracted quickly
BackTracker
 Monitors OS-level objects




Files
Filenames
Processes
Events (system calls)
Objects
 BackTracker analyzes processes, files, and
filenames
 Process


Identified by a PID and a version number
Tracked from fork() to exit()/execve()
 File object

Identified by a device, an inode number, and a
version number

Tracked across rename operations
Objects
 Filename object


Directory data
Identified uniquely by an absolute path
Potential Dependency-Causing Events
 A dependency relationship is specified by
three parts





Source object
Sink object
Time interval
Source  Sink
An event starts when the system call is
invoked and ends when the system call
returns
Process/Process Dependencies
 One process can affect another by



Creating it via fork() (parentchild)
Sharing memory with it via clone()
(parentchild)
Signaling it
Process/File Dependencies
 Processfile


Write-like system calls (chown, chmod, utime)
Mapping a file write-only
 Fileprocess


Read-like system calls (fstat, open, chdir,
unlink, execve)
Mapping a file read-only
 Processfile

Mapping a file read-write
Process/File Dependencies
 A child process inherits its parent’s
dependencies
Process/Filename Dependencies
 Examples


Delete a configuration file, so a system falls
back to the insecure default configuration
Swap names of current and backup password
files
 Filenameprocess

System calls that include a filename argument


open, creat, link, unlink, mkdir, rename, rmdir,
stat, chmod
Readdir
Process/Filename Dependencies
 Processfilename

System calls that modify a filename argument

creat, link, unlink, rename, mkdir, rmdir, mount
Dependency Graphs
 How to select the objects and events in the
graph that relate to the attack
 Assume that the administrator can identify at
least one detection point


Modified, extra, or deleted file
Suspicious or missing process
 GraphGen reads a log of events in reverse
time order

Uses a time threshold to determine whether
an event is relevant to an object
Dependencies Tracked by Current
Prototype
 Affecting an object vs. controlling an object
 BackTracker focuses on high-control events







Process creation through fork or clone
Load and store to shared memory
Read and write of files and pipes
Receiving data from a socket
Execve of files
Load and store to mmap’ed files
Opening a file
Dependencies Tracked by Current
Prototype
 Examples of low-control events





Changing a file’s access time
Creating a filename in a directory
Tend to generate lots of noise in the
dependency graph
An attacker may run a CPU-intensive program
to trigger a race condition
Fortunately, it is difficult to attack solely by
using low-control events
Implementation Structure for Logging
Events and Objects
 Run target OS (Linux 2.4.18) and application
inside a VM
 Have the VM monitor call a kernel procedure
at appropriate times
 Reasons to use a VM-based structure



Prevent intruders in the VM from interfering
with logging
Use ReVirt to replay attacks
14-35% overhead for kernel-intensive loads
Implementation Structure for Logging
Events and Objects
 The VM monitor notifies EventLogger
whenever a guest application invokes or
returns from a syscall, or when a guest
application exits
 EventLogger is compiled with headers from
the guest kernel and reads guest’s physical
memory to determine events
 EventLogger code is ~1,300 lines
Implementation Structure for Logging
Events and Objects
 An design alternative



Run EventLogger without VM
Store the log on a remote machine
Use a protected file on the local computer
Prioritizing Parts of a Dependency
Graph
 Dependency graphs for a busy system are
too large
 Ways to filter a dependency graph

Ignore certain objects



/var/run/utmp causes a new login session to
depend on all prior login sessions
/etc/mtab
.bash_history
Prioritizing Parts of a Dependency
Graph
 More ways to filter a dependency graph


Filter out low-control events
Hide read-only files


Filter out helper processes (/etc/bashrc)


Often are default configuration or header files
They tend to form cycles in the graph and take
input form read-only files
Choose several detection points, then take the
intersection of the dependency graphs
Evaluation
 Used a honeypot machine (Red Hat 7.0)
 Vulnerable to OpenSSL and sendmail exploits
 Without filtering
 EventLogger logged ~160K objects and ~1.2
million events

Dependency graph contained ~5,200 objects and
~10,000 events
 After filtering
 Reduced the graph to 24 objects and 28
events
Evaluation
 httpdbashwget/tmp/bindbind/bin/lo
gin
 BackTracker can also separate two
intermingled attacks from a single log
 BackTracker can still function well with
SPECweb99 running in the background
 EventLogger slows the system by 9%


Log grows at 1.2 GB/day
3 hours to process the log
Process
File
Socket
Detection point
Fork event
Read/write event
Process
File
Socket
Detection point
Fork event
Read/write event
Attacks Against Backtracker
 An intruder can attack lower layers with
events not monitored by BackTracker



Kernel modules
/dev/kmem
Disabled in VM
 Use low-control events to break the chain of
events
 Use hidden channels to steal passwords
 Use innocent processes to inflate the graph