CS 443 Advanced OS Fabián E. Bustamante, Spring 2005 Backtracking Intrusions Sam King & Peter Chen CoVirt Project, University of Michigan Presented by: Fabian Bustamante

2 Motivation Increasing frequency of computer intrusions What should a Sys Admin do after discovering an intrusion? –Understand how the system was broken-in –Identify the damage inflicted to the system –Fix the vulnerability and undo the damage But first need to know there’s has been an intrusion –Using TripWire detect a modified file system –Network or host firewall notice a port scan –Sandboxing tool notice program misbehaving (e.g. unusual sys call patterns) Detection point – state on the local computer system that alerts admin of the intrusion (e.g. a deleted, modified file)

3 Current forensic methods Manual inspection of existing logs Some helpful tools: –Snort can log network traffic –Ethereal can present app-level views of net traffic –Coroner’s toolkit can recover deleted files Problems/limitations –System, application logs - not enough information Partial, app-specific and little info on what happen after the compromise –Network log - may be encrypted –Disk image - only shows final state –Low-level logs – complete but hard to decipher –No way to separate out legitimate actions Identifying the sequence of events from the initial compromise to the point of detection is still largely a manual process

4 BackTracker To help understand what took place during the attack Back tracking from a detection point, identifying a possible chain of events BackTracker (BT) works by observing OS-level objects & events –Unlike app-level logging, cannot separate objects within an application –Unlike network-level logging, can be interpreted even if attacker encrypts network communication Two components –On-line piece that logs sys calls that induce most directly dependency between OS objects (e.g. creating a process, reading/writing a file) –Off-line component that graphs events related to the attach Goal: reconstruct the time-line of events that occurred in an attach

5 Process File Socket Detection point Fork event Read/write event Example (filtered dependency graph) Made web server to create a command shell Download and unpack an executable Run the executable wit a different group id ptrace attach

6 BackTracker objects Process –Identified uniquely by pid & version number –Tracked from creation (fork/clone) to exit File object –Identified uniquely by a device/inode #/version # –Including data & metadata specific to file –Affected by system calls such as write Filename –Identified uniquely by a canonical name –Directory data that maps a name to a file object –Affected by system calls such as rename, create … Finer granularity than processes, file objects & filenames? –Reduce false dependencies (like false-sharing in DS) –Harder & w/ potentially higher overhead

7 Dependency-causing events BT logs events at runtime that induce dependency relationships bet/ objects Dependency relationship source → sink & time interval (in terms of an event counter) Time intervals to reduce false dependencies Process / Process –fork, clone (bidirectional from shared AS), shared memory (grouped) Process / File –read, write, mmap (grouped; direction depends on access permissions) Process / Filename –open, creat, link, unlink, mkdir, rmdir, stat, chmod, …

8 Dependency graphs No the complete dep. graph, just enough to understand attack From the detection point, GraphGen –Reads the log backward –For each event, evaluate if affect any object in graph by the object’s time threshold –If so, add event to graph, add edge High- & low-control event –Affecting != controlling an object, and then there’s a range –BT focuses on “high-control” events Those that make it easier for the attacker to accomplish a task e.g. write a file, create a process Low-control events – e.g. changing a file access time, creating a filename That could be enough – it’s hard for an intruder to perform a task solely relying on low-control events

9 Dependency graphs Process A File 0 File 1 File 2 File X Process B Process D Process C Process A File 0 File 1 File X Process B Process C Event log Complete graph GraphGen’s graph Time 0: process A creates process B Time 1: process B writes file 1 Time 2: process B writes file 2 Time 3: process A reads file 0 Time 4: process A creates process C Time 5: process C reads file 1 Time 6: process C writes file X Time 7: process C read file 2 Time 8: process A creates process D At time 10 admin knows X has the wrong content 8 & 7 are ignored; 6 is relevant … At 5, C reads file 1 At 3, A reads file 0 At 4, A creates C At 0, A creates B At 1, B writes file 1

10 Prioritizing dependency graphs Dependency graphs may be too large Not all objects & events are equally important –Filter them risk of hiding important sequence Filtering –Ignore certain objects e.g. /etc/mtab,.bash_history –Ignore certain events e.g. low-control events –Hide files read but not written (such as config files) –Filter out helper processes that take input form one process, do a simple thing & return to the main process (e.g. /etc/bashrc uses bash to find user and group name of user) –Look at the intersection of several dependency graphs These may filter out a vital link, disconnecting the detection point from the source of the intrusion

11 ~Unfiltered graph for bind attach

12 Filtered dependency graph Noticed a modified system binary Log for analysis period - 155,344 o & 1,204,166 e Without filtering - 5,281 o & 9,825 e With filtering of read-only files o & 1,014 e (prev slide) With filtering of + read only files + /root/.bash_history, /var/run/lastlog, /var/run/utmp, /etc/mtab + helper processes - 24 o & 28 e Access gained through httpd Download a rootkit using wget When run, rootkit (/tmp/ /bind) install /bin/login, etc

13 Filtered dependency graph for self

14 Implementation Prototype built on Linux Both stand-alone (storing log on a remote computer or protected file) & virtual machine (using UMLinux) Hook system call handler; notify when app invokes/returns from sys call or process exits Inspect state of OS directly (EventLogger is compiled with headers from guest OS) EventLogger ~ 1,300 LOC + 40 LOC to VMM Guest OS Host OS VMMEventLogger Guest Apps Host OS EventLogger Host Apps Virtual Machine Implementation Stand-Alone Implementation

15 Evaluation Determine effectiveness of Backtracker Set up honeypot virtual machine (RH7) Intrusion detection using standard tools (homegrown Tripwire, Ethereal, Snort) Three real attacks & a simulated one –Attacks evaluated with six default filtering rules Showing –Advantages of/need for filtering –Space and time overhead of EventLogger (using ReVirt to replay the run w/ & w/o EventLogger)

16 BackTracker’s analysis of attacks bindptraceopenssl-tooself Time period analyzed24hr…61hr24hr #objects (o) & events (e) in log 155,344 o 1,204,166 e …77,334 o e 717 o 3,387 e # o & e in unfiltered dependency graph 5,281 o 9,825 e 552 o 2,635 e 495 o 2,414 e 717o 3,387 e # o & e in filtered dependency graph 24 o 28 e 20 o 25 e 28 o 41 e 56 (36) o 81 (49) e Growth rate of EventLogger’s log GB/day…0.002 GB/day1.2GB/day Time overhead of EventLogger 0%… 9% 24hr 155,344o 1,204,166 e GB/day 0%

17 Attacks against BackTracker Layer-below attack –Guest OS - if intruder can hide change it, it can hide from BT –VMM – a little harder to do Break the chain of events by using “low control” events or filtered objects to carry out attack Hidden channels (get password, sent to himself, log in later) Create large dependency graph –Perform a large number of steps –Implicate innocent processes –Try to hide under a long sequence of events (bad idea)

18 Conclusions & future work BT - tracking causality through system calls can backtrack intrusions Dependency tracking –Reduce events and objects by 100x –Still effective even when same application exploited many times –Filtering further reduce events and objects Future work –Track more dependency-causing events –Eliminate false dependencies on new forward track dependency tool