Area: Analyzing Security Incidents with System Call Capture and Replay

Attack analysis is often a time-consuming and error-prone task, especially for targeted or day-zero exploits. Often, attackers install backdoors and disguise or delete evidence. Our approach to this problem, embodied in our tool Malfor, is experimental: We capture system calls of processes during normal operation and enter them into a database. Once an intrusion has been detected, we replay them selectively on a standby system. Using Delta Debugging, we find out exactly which processes and which inputs were responsible for the attack.

Master Thesis: Ordering Constraints During Syscall Replay

The Problem. When replaying concurrent processes, some ordering must be maintained if the replay is to be meaningful. For example, if, during capture, process P sends a message to process Q, then process Q must block during replay until process P sends the message. Or, if process P begins its existence after process Q has exited, this relationship must hold also during replay.

At the moment, we guarantee these constraints in an ad-hoc manner, but we are looking for a more general solution. For example, there is what we call the Weak Concurrency Consistency Criterion (WCCC), which says that a system call can only be replayed if it is the earliest system call that is as yet un-replayed. Replaying of any other system call must be delayed until it is the earliest un-replayed call.

The Task. Your task is to implement a framework for order-maintaining strategies within the currently existing replay infrastructure and to show proof-of-concept by implementing an example strategy for WCCC.

Your code must run under Linux.

Prerequisites. If you want to take up this task, you need to be fluent in C and C++. In order to understand the ordering constraints you will be implementing a framework for, you need at least a basic understanding of multithreading, concurrency, and operating systems.

None of your tasks require writing kernel code. An understanding of how Linux works under the hood is useful, though not required.

Bachelor Thesis: Analyze Attacks With Malfor

The Problem. Malfor has successfully analyzed a number of attacks. However, this number is rather small, and in order to get more experience with Malfor, we want to apply it to more attacks.

The Task. Your task would be threefold:

• Build up a repository of attacks. This includes building disk images for User Mode Linux to boot, and automating both the attack and a detection method that can tell whether the attack was successful or not;
• Capturing the attacks with Malfor. This includes not only running the attack, but also running harmless background processes in order to have a more realistic analysis.
• Analyzing the attack with Malfor and evaluating the results.

We are aiming for a publication of your results. This should influence some of your decisions concerning the thesis.

Prerequisites. You need a good understanding of current attacks and how to run them. Strictly no script kiddies! You need a good amount of perseverance in finding attacks and getting them to run on a UML.

Bachelor Thesis: Visualizing Process Replay

This project has already been taken!

The Problem. When replaying processes, there is a lot of low-level action happening. The sheer number of events that are happening in quick succession prevents humans from understanding what is going on. The current replay system already emits events like “Delta Debugging started with these processes: 123, 124, 167”, “A test ended with the result UNRESOLVED”, “A process with PID 789 has just started” and so on. What we need is a way to visualize these events and to record them for offline re-replaying.

The Task. When replaying processes, there is a lot of low-level action happening. The sheer number of events that are happening in quick succession prevents humans from understanding what is going on. Your task, should you choose to accept it, is interfacing with the replaying processes, accepting the events they emit, and turn them into a visual display of the debugging process.

You must be able to display a process tree (classes to extract the tree from a database are already written) and the changes which it undergoes as it is processed by delta debugging. However, I don't yet know precisely what I want from such a display, so you should expect occasional changes.

Your code must run under MacOS 10.X and under Linux.

You must be able to save a replay and to re-replay it later. Your program must be able to fast-forward a re-replay.

Prerequisites. If you want to take up this task, you need to know portable graphics programming. Knowledge of portable toolkits such as Qt is a definite plus. You do not need to understand how the replaying works in detail.

Master Thesis: Automatic Extraction of Attack Signatures

This project has already been taken!

The Problem. An attack signature is the input to a system of processes that causes an intusion. Usually, attack signatures can only be extracted during massive attacks where hundreds of almost identical attack vectors are launched against computers. We want to extract attack signatures from one-time attacks. We may also want to find similarities between two or more similar attacks in order to arrive at a generalized attack signature.

The solution to this is to use Delta Debugging (or any other minimization technique) on the inputs of the captured processes. This creates its own (technical) problems, whose solution is part of your thesis.

The Task. The thesis proceeds in several natural stages:

• Find an attack on which to base your development. This attack will ideally concern only one network service.
• Find out how to reconstruct a process's input from the database. (This step is interchangeable with the step above.)
• Implement delta debugging on process inputs, possibly using a toy program for debugging.
• Try your algorithm on the attack you found in the first step.
• Try variations of the attack and see if yu can spot any obvious places for signature generalization.
• Try some more attacks to evaluate your implementation.
• Write up your results in a paper, to be published at a security conference.

Note how the goals become successively more vague from top to bottom, except for the very last step. This is intentional; the goals can become more defined only when we know what the results of the preceding steps are.

As you can see from the last step, we are aiming for a publication of your results. This should influence some of your decisions concerning the thesis.

Prerequisites. If you want to take up this task, you need to know C and C++. You also need a knowledge of operating systems. You will need to understand in some detail how replaying works, but this knowledge is gained “on the job”.

Area: Testing for Security Flaws

Master Thesis: Security Effects of Fault Injection Tests

This project has already been taken!

The Problem. Fault injection is a testing method that changes parts of the program state to to (possibly illegal) values during a program run in order to examine the program's behavior. The purpose if this work is to examine the suitability of fault injection for testing for security-related defects.

A related method is Fuzz Testing. This method works by randomizing program inputs. Existing results show that a non-negligible percentage of programs can be made to crash this way.

The Task. The purpose of this thesis is to develop a system that can inject faults into systems written in C. The changes in system state must be controlled by a configuration file. The design of a suitable descriotion language is part of the thesis.

State changes occur in a variety of circumstances:

• A variable can change its value more or less dramatically. We need to be able to specify a range of variability for every variable that ranges from minute differences to totally random changes.
• A variable can not only take on random values, but also values of other variables, plus a random difference. Using this, we can simulate the coupling of variables.
• A variable must be changeable at various points in time, for example:
  • After the n-th execution of a line of code.
  • After a certain variable has been changed for the n-th time.
  • As soon as a location in the neighborhood of address x is changed
  • When a function is entered.
  • When a function is left.
  Further specifications are possible, but optional.

The collection of suitable programs (either by collecting existing programs or by writing your own) that show the implementation's functionality is also part of the thesis.

Prerequisites. You should be fluent in C, should know i386 assembler and the GNU debugger. A knowledge of Python is a definitive plus, since we will use the existing AskIgor framework, which is written in Python.

Area: Delta Debugging

Fopra: Hierarchical Delta Debugging

This project has already been taken!

The Problem. Delta Debugging (DD) can be used to minimize failure-inducing input; to this end, it removes parts of the input and tests whether the program still fails. DD works best when program inputs are well-formed. For example, when minimizing a HTML file that causes Mozilla to crash, we should take care that DD produces well-formed HTML; when minimizing a HTTP request that crashes Apache, DD should produce well-formed HTTP requests.

For example, a HTTP request can be split first into header and body, the header can be split into method (GET/PUT) and header, headers can be split into lines, header lines can be split into name/value pairs, and these can in turn be split into characters. On each level of splitting, we can use Delta Debugging to find a minimal failure-inducing input, and only on the last two levels do we not produce a well-formed HTTP request.

The Task. The purpose of this Fopra is to develop a framework that takes an input string and syntax description and implements a hierarchical delta debugging algorithm. Also needed is a theoretical discussion about the expected speedup versus character-based DD. Your code must be written in C++ and must run under Linux.

Prerequisites. You should be fluent in C, and should know DD.