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() (parentchild) Sharing memory with it via clone()

(parentchild) Signaling it

Process/File Dependencies

Processfile Write-like system calls (chown, chmod, utime) Mapping a file write-only

Fileprocess Read-like system calls (fstat, open, chdir,

unlink, execve) Mapping a file read-only

Processfile 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 Filenameprocess

System calls that include a filename argument open, creat, link, unlink, mkdir, rename, rmdir,

stat, chmod Readdir

Process/Filename Dependencies

Processfilename 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

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

httpdbashwget/tmp/bindbind/bin/login

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