Computer Security and Cryptography Seminar:
December 2004 Events

(This is a practice talk for the 20th Annual Computer Security Applications Conference, ACSAC'04.)

A common way to elude a signature-based NIDS is to transform an attack instance that the NIDS recognizes into another instance that it misses. For example, to avoid matching the attack payload to a NIDS signature, attackers split the payload into several TCP packets or hide it between benign messages. We observe that different attack instances can be derived from each other using simple transformations. We model these transformations as inference rules in a natural-deduction system. Starting from an exemplary attack instance, we use an inference engine to automatically generate all possible instances derived by a set of rules. The result is a simple yet powerful tool capable of both generating attack instances for NIDS testing and determining whether a given sequence of packets is an attack.

In several testing phases using different sets of rules, our tool exposed serious vulnerabilities in Snort---a widely deployed NIDS. Attackers acquainted with these vulnerabilities would have been able to construct instances that elude Snort for any TCP-based attack, any Web-CGI attack, and any attack whose signature is a certain type of regular expression.

This is a joint work with Somesh Jha and Bart Miller.

This informal talk presents a paper by Christopher Kruegel (Tech Univ Vienna), William Robertson (UCSB), and Giovanni Vigna (UCSB), from ACSAC'04. Come ready to critique and brainstorm.

A rootkit is a collection of tools used by intruders to keep the legitimate users and administrators of a compromised machine unaware of their presence. Originally, rootkits mainly included modified versions of system auditing programs (e.g., ps or netstat on a Unix system). However, for operating systems that support loadable kernel modules (e.g., Linux and Solaris), a new type of rootkit has recently emerged. These rootkits are implemented as kernel modules, and they do not require modification of user-space binaries to conceal malicious activity. Instead, these rootkits operate within the kernel, modifying critical data structures such as the system call table or the list of currently-loaded kernel modules.

This paper presents a technique that exploits binary analysis to ascertain, at load time, if a module's behavior resembles the behavior of a rootkit. Through this method, it is possible to provide additional protection against this type of malicious modification of the kernel. Our technique relies on an abstract model of module behavior that is not affected by small changes in the binary image of the module. Therefore, the technique is resistant to attempts to conceal the malicious nature of a kernel module.

This is an informal seminar presenting the work of Helen J. Wang, Chuanxiong Guo, Daniel R. Simon, and Alf Zugenmaier from Microsoft Research, as published in SIGCOMM 2004. Come ready to critique and brainstorm.

Software patching has not been effective as a first-line defense against large-scale worm attacks, even when patches have long been available for their corresponding vulnerabilities. Generally, people have been reluctant to patch their systems immediately, because patches are perceived to be unreliable and disruptive to apply. To address this problem, we propose a first-line worm defense in the network stack, using shields --- vulnerability-specific, exploit-generic network filters installed in end systems once a vulnerability is discovered, but before a patch is applied. These filters examine the incoming or outgoing traffic of vulnerable applications, and drop traffic that exploits vulnerabilities. Shields are less disruptive to install and uninstall, easier to test for bad side effects, and hence more reliable than traditional software patches. Further, shields are resilient to polymorphic or metamorphic variations of exploits.

In this paper, we show that this concept is feasible by describing a prototype Shield framework implementation that filters traffic above the transport layer. We have designed a safe and restrictive language to describe vulnerabilities as partial state machines of the vulnerable application. The expressiveness of the language has been verified by encoding the signatures of several known vulnerabilites.

In our Shield design, we model vulnerability signatures as a combination of partial protocol state machines and vulnerability-parsing instructions for specific payloads. For generality, we abstract out the generic elements of application-level protocols. For flexibility, we express vulnerability signatures and their countermeasures in a safe and restrictive policy language, interpreted by the Shield framework at runtime. We also minimize Shield's maintenance of protocol state (for scalability), and apply defensive design to ensure robustness. We have implemented a Shield prototype and experimented with 10 known vulnerabilities, including the ones behind the (in)famous MSBlast and Slammer worms. Our evaluation provides evidence of Shield's low false positive rate and small impact on application throughput. An examination of a sample set of known vulnerabilities suggests that Shield could be used to prevent exploitation of a substantial fraction of the most dangerous ones.

This is an informal seminar presenting a paper by Christian Collberg, Edward Carter, Saumya Debray, Andrew Huntwork, Cullen Linn, and Michael Stepp appeared in PLDI 2004. Come ready to critique and brainstorm.