1 / 18

Backtracking Intrusions

Backtracking Intrusions. Sam King & Peter Chen CoVirt Project, University of Michigan Presented by: Fabian Bustamante. Motivation. Increasing frequency of computer intrusions What should a Sys Admin do after discovering an intrusion? Understand how the system was broken-in

honora
Download Presentation

Backtracking Intrusions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related