Backtracking Intrusions

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

10. These may filter out a vital link, disconnecting the detection point from the source of the intrusion Prioritizing dependency graphs • Dependency graphs may be too large • Not all objects & events are equally important • Filter them out @ 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

11. ~Unfiltered graph for bind attach

12. Filtered dependency graph Access gained through httpd Log for analysis period - 155,344 o & 1,204,166 e Without filtering - 5,281 o & 9,825 e With filteringof read-only files - 575 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 Download a rootkit using wget Noticed a modified system binary When run, rootkit (/tmp/ /bind) install /bin/login, etc

13. Filtered dependency graph for self

14. Guest Apps Guest OS Host Apps VMM EventLogger Host OS Host OS EventLogger Implementation • Prototype built on Linux 2.4.18 • 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 Stand-Alone Implementation Virtual Machine 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. 24hr 155,344o1,204,166 e 0.017 GB/day 0% BackTracker’s analysis of attacks

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