Backtracking Intrusions

1. Backtracking Intrusions

2. 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)

3. 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

4. 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

5. 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

6. 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

7. 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

8. Process File Socket Detection point Fork event Read/write event

9. 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

10. BackTracker • Monitors OS-level objects • Files • Filenames • Processes • Events (system calls)

11. 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

12. Objects • Filename object • Directory data • Identified uniquely by an absolute path

13. 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

14. Process/Process Dependencies • One process can affect another by • Creating it via fork() (parentchild) • Sharing memory with it via clone() (parentchild) • Signaling it

15. Process/File Dependencies • Processfile • Write-like system calls (chown, chmod, utime) • Mapping a file write-only • Fileprocess • Read-like system calls (fstat, open, chdir, unlink, execve) • Mapping a file read-only • Processfile • Mapping a file read-write

16. Process/File Dependencies • A child process inherits its parent’s dependencies

17. 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 • Filenameprocess • System calls that include a filename argument • open, creat, link, unlink, mkdir, rename, rmdir, stat, chmod • Readdir

18. Process/Filename Dependencies • Processfilename • System calls that modify a filename argument • creat, link, unlink, rename, mkdir, rmdir, mount

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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

26. 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

27. 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

28. 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

29. Evaluation • httpdbashwget/tmp/bindbind/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

30. Process File Socket Detection point Fork event Read/write event

31. Process File Socket Detection point Fork event Read/write event

32. 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