Malfor
MALware FORensics

Malfor News

2006-06-01 We can analyze a realistic and complicated attack version of Malfor on a Linux system. In a graphical representation of that attack, you can see relevant processes in red and irrelevant processes in green. The attack downloads C source, compiles it, downloads a loadable kernel module, causes privilege escalation through a bug in suidperl, loads the kernel module which modifies the password file, and exits, deleting all intermediate files.

2006-03-22 We can replay a realistic and complicated attack on a Linux system. You can download a new version of Malfor that has this ability.

2006-02-15 You can download Malfor·

2005-12-13 We are distributing copies of Malfor for free. If you want one, write to malfor (at) st (dot) cs (dot) uni-sb (dot) de. While Malfor is free, you must adhere to its License. it is much like the BSD License. 2006-02-15 UPDATE: Please do not write to the above address any more; instead, please use the download instructions at the bottom of this page.

2005-08-10 We can isolate the relevant inputs (i.e., the attack vector) in a test environment. We are currently working on getting the attack vector for a real hole in Apache.

2005-07-15 We have summarized our work so far in a paper, which has been accepted at NDSS '06.

2005-04-22 We can isolate the processes relevant to an attack in a test environment.

2005-03-04 We'll be at the CeBit this year; come visit us in Hall 9, Booth D09.

What is Malfor?

Malfor is a system that can automatically find the cause of a break-in. It does so by capturing and experimentally replaying the events that have occurred in a computer system.

How does Malfor Work?

The idea of Malfor is that there are malicious inputs that make processes do things they should not do. If we can find these inputs or processes, we can analyze the attack. For example, a Linux service contained a security hole that allowed attackers to execute arbitrary commands on the attacked machine. This hole would be exploited by a specially crafted input that is sent to the service over the Internet. With Malfor, you can trace back evidence of an intrusion, such as a modified password file, to that specially crafted packet.

On the left side of this figure are the input sources of a typical computer system, such as network switches, disks, and modems. They all provide inputs to the system under attack. These inputs are all captured by Malfor and stored in a database. When a break-in is detected, Malfor uses this database to replay parts of these inputs to the replay systems on the right. These systems are configured identically to the system under attack.

How Does Malfor Find the Bad Packets or Processes?

Malfor uses the Delta Debugging algorithm or one of its variations to find a small subset of the inputs or processes that cause the breakin to happen. How small is that subset? It is so small that you can't remove any single element from the input and still have the breakin occur.

As a simplified example, assume that a Web server has a buffer overflow vulnerability that is only triggered by an overly long User-Agent field. A failure-inducing input could look like this:

The failure is triggered only when lines 1 and 3 are present, because if line 1 is missing, the resulting input is not a well-formed HTTP request.

Delta Debugging now systematically tests the Web server with different subsets of lines 1–6 to see whether they cause a buffer overflow or not. The following outcomes may result:

• the program completes successfully and the buffer overflow does not occur (denoted by PASS);
• the program exhibits the buffer overflow (denoted by FAIL); or
• the program crashes or otherwise delivers an inconclusive result (denoted by UNRESOLVED). This happens for example if line 1 is not transmitted, because the result is no longer a well-formed HTTP request.

Line 0 contains the initial input, which makes the program fail. In line 1, the input is split into halves, and the first half (lines 1–3 of the HTTP request) is tested. Since these constitute a well-formed HTTP request and also contain the overly-long “User-Agent” field, the outcome is FAIL. This allows Delta Debugging to narrow down its investigation to this first half of the input.

This subset is then again split into nearly equal halves, consisting of line 1 alone and lines 2–3. Testing line~1 alone gives PASS, since it is a well-formed HTTP request and does not contain line 3. Delta Debugging cannot narrow down lines 1–3 on this result.

Testing lines 2–3 gives UNRESOLVED, since line 1 is missing. Both halves of the input now give results that cannot be used to narrow down the subset. Delta Debugging then increases the granularity of subsets to get more subsets, and splits lines 1–3 into three subsets of one line each.

The subset consisting only of line 1 was already tested and need not be re-tested. The two remaining subsets each give UNRESOLVED, because line 1 is missing. At this point, Delta Debugging tries the complements of the one-element subsets with respect to the subset containing lines 1–3. The first such complement, containing lines 2 and 3, was already tested. The next complement contains lines 1 and 3, which results in FAIL. This allows Delta Debugging to focus on these lines.

At this point, Delta Debugging would split the subset containing lines 1 and 3 into two halves. Both resulting subsets have already been tested, however, so the algorithm stops because progress is no longer possible.

This example illustrates some features of Delta Debugging:

• it works by repeatedly splitting its inputs, increasing the granularity of splits, and trying complements of subsets that were already tested;
• it will find a subset S of the input that makes the outcome FAIL; and
• it is impossible to remove any single element from S so that the outcome is still FAIL.

In our example, Delta Debugging needed six steps. Zeller and Hildebrandt have shown that if the input has n items, Delta Debugging will at most take O(n²) steps. In our experience, however, Delta Debugging will often terminate in O(n log n) steps.

How Much Overhead Does Malfor Incur?

We are still measuring the overhead for capture and replay. Preliminary results suggest that the overhead in time is not very large (about 8%–13%). The overhead in space (for the database) is unknown at this time, but is suspected not to be overly large. Most of the data in the database is also amenable to compression (at a slight performance cost). We will publish the results on this page as soon as they become available.

Can I use Malfor On My Production System?

Yes, Malfor can be used on production systems. Malfor incurs some overhead, both in storage space and execution time, but the time overhead is low (about 8%–13%), and the space overhead is getting more tolerable with time.

How Much of Malfor is Currently Running?

As of 2006-06-01, Malfor is able to extract intrusion-causing processes for a realistic and complicated attack on Apache.

Can I Get Malfor?

Yes, you can. If you want a copy, download it now. Also download the UML/Malfor patch to the Linux kernel. While Malfor is free, you must adhere to its License. It is much like the BSD License. Also, please be aware that while we earnestly want you to be able to run Malfor, we can only give you support on a best-effort basis.

The tarball contains a file called INSTALL which you should read.

Impressum ● Datenschutzerklärung