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 ) 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 Often are default configuration or header files Filter out helper processes (/etc/bashrc) 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