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 theres 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
• Coroners 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
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 objects time threshold
• If so, add event to graph, add edge
• High- low-control event
• Affecting ! controlling an object, and then
  theres 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 its hard for an intruder
  to perform a task solely relying on low-control
  events

9
Dependency graphs
Event log
Complete graph
GraphGens 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
Prioritizing dependency graphs

• Dependency graphs may be too large
• Not all objects events are equally important
• Filter them out _at_ 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
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

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
BackTrackers analysis of attacks
bind ptrace openssl-too self
Time period analyzed 24hr 61hr 24hr
objects (o) events (e) in log 155,344 o 1,204,166 e 77,334 o 382955 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 EventLoggers log 0.017 GB/day 0.002 GB/day 1.2GB/day
Time overhead of EventLogger 0 0 9
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