Mike Hsiao 20070928 Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits Helen J. Wang, Chuanxiong Guo, Daniel R. Simon,

Mike Hsiao 20070928

Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits

Helen J. Wang, Chuanxiong Guo, Daniel R. Simon, Alf Zugenmaier

Microsoft Research

SIGCOMM ‘04

2/40


Outline

• Introduction• Vulnerability Modeling and Shield Usage• Shield Architecture• Detailed Design Issues• Shield Policy Language• Analysis and Implementation• Evaluations• Related Work and Conclusions

3/40


Introduction

• Software venders develop and distribute reparative “patches” to their software as soon as possible after learning of a vulnerability.• In fact, more than 90% of the attacks today are

exploiting known vulnerabilities.

• There are several reasons why we may fail to install software patches• Disruption• Unreliability• Irreversibility• Unawareness

4/40


Introduction (cont’d)

• The goal (of this paper) is to address the window of vulnerability between vulnerability disclosure and software patching.• Firewall (5-tuple) may block all traffic to a port.• Exploit-Signature-based firewalls (string-match) can not

filter polymorphic variations.

• Ideally, prevention mechanisms would be deployed well before attacks occur• even before the public disclosure of a vulnerability• only traffic that exploits the vulnerability would be

blocked, while all other traffic would be allowed to pass through to the application.

5/40



• They explore the possibility of applying an intermediate “patch” in network stack to perform filtering function, to delay the need for patch.

• Shield is a system of vulnerability-specific, exploit-generic network filters (shields)• installed at the end host• examine the incoming or outgoing traffic of

vulnerable applications• correct the traffic according to vulnerability signature• operates at the application protocol layer (IPSec, SSL,

application-message-based inspection, …)

6/40



• Conceptually, there is one shield per vulnerability.• For example, a shield designed to protect against

a buffer overrun vulnerability would detect and drop or truncate traffic that resulted in an excessively long value being placed in the vulnerable buffer.

• Shields are deployed in the network stack of the end host. (separated from the vulnerable application)

• Shield is non-disruptive and easily reversible

7/40


Outline


8/40


Vulnerability Modeling

• An essential part of the Shield design is the method of modeling and expressing vulnerability signatures.• Not all vulnerabilities are suitable for shielding.

• A Shield vulnerability signature specifies• all possible sequences of application messages

and• specific payload characteristics that lead to any

remote exploit of the vulnerability.

9/40


Vulnerability Modeling (example)

• The signature for the vulnerability behind the Slammer worm is• the arrival of a UDP packet at port 1434 • with a size that exceeds the legal limit of the

vulnerable buffer (128) used in the Microsoft SQL server 2000 implementation.

• More sophisticated vulnerabilities require tracing a sequence of messages leading up to the actual message that can potentially exploit the vulnerability.

10/40


Vulnerability Modeling (taxonomy)

• Each application can be considered as a finite state machine (application state machine)

• Overlaying the application state machine is the Protocol State Machine• Much smaller and simpler (than app)

• Pre-vulnerability state is the state in protocol state machine at which receiving an exploitation network event could cause damage.• vulnerability state machine: the partial protocol state machine

that lead to the pre-vulnerability state• vulnerable event: the message that can potentially contain an

exploit

11/40


Vulnerability Modeling (cont’d)

QuickTime™ and aTIFF (Uncompressed) decompressor

are needed to see this picture.

12/40


Vulnerability Modeling (cont’d)

• A shield vulnerability signature• Specifies the vulnerability state machine• Describes how to recognize any exploits in the

vulnerable event

• A shield policy for a vulnerability includes• the vulnerability signature• the actions to take on recognizing an exploit

13/40


Shield Usage

• When a new vulnerability is discovered, the vendor can create a shield policy for the vulnerability.

• Shield intercepts the application traffic and walks through the vulnerability state machine.

• When reaching the pre-vulnerability state, the Shield examines the vulnerable event for possible exploit, and take specified actions.

• Similar fashion to a firewall, but much more application-specific knowledge. (filter outgoing traffic, don’t require restarting or rebooting.)

14/40


Outline


15/40


Shield Architecture (Goals)

• Minimize and limit the amount of state maintained by Shield• resist any resource consumption (DoS) attacks

• Enough flexibility to support any application level protocol (policy and mechanism)

• Design Fidelity• Shield does not become an easier alternative attack

target.• It is crucial to defend against carefully crafted

malicious messages that may lead to Shield's misinterpretation of the application's semantics.

16/40


Shield Architecture (mechanism)

• Application level protocols between two parties (say, a client and a server) are implemented using finite state automata.

• Session is the unit of communication that is modeled by the protocol state machine.

• Implementations of datagram-based protocols must handle out-of-order application datagrams for their sessions.

• Implementations of application-level protocols that allow message fragments must handle fragmentation.

17/40


Shield Architecture (policy)

• Application identification• how to identify which packets are destined for which

application. (service port number)

• Event identification• how to extract the message type from a received

message.

• Session identification (if applicable)• how to determine which session a message belongs to.

• State machine specification• the states, events, and transitions defining the protocol

automaton.

18/40




19/40


Data Structures (Spec)

• The purpose of a Spec is to instruct Shield how to emulate the application vulnerability state machines at runtime.• Spec contains the state machine

specification, port number(s) for application identification, and event and session identification information.

20/40


Outline


21/40


Detailed Design Issues

• Scattered Arrivals• could be due to TCP congestion control or some specific

message-handling implementations of an application

• Out of Order Arrivals• UDP can arrive out of order• Applications that care about the ordering of these

datagrams will have a sequence number field in their application-level protocol headers.

• Application Level Fragmentation• the Spec needs to contain the location of the

application-level fragment ID in the message.

22/40


Outline


23/40




Slammer

24/40




CodeRed



25/40


MSBlast



26/40


Outline


27/40


Analysis (scalability)

• Each shield will presumably be removed when its corresponding vulnerability is patched.

• Shields are application-specific, adding negligible overhead to applications to which they do not apply.

• The state machines that model multiple vulnerabilities (on an application) should preferably be merged into a single one.• For worm-exploitable vulnerabilities, no more than

three vulnerabilities ever appeared over a single application protocol throughout the whole year.

28/40


Analysis (False Positives)

• Shields are able to recognize and filter only traffic that exploits a specific vulnerability, and hence should have very low false positives.

• False positives may arise from incorrect policy specification due to misunderstanding of the protocol state machines or payload formats.

29/40


Implementation

• Windows XP• Microsoft WinSock2 Layered Service Provider (LSP)• 10702 lines of C++• Flex and Byacc• Slammer, MSBlast,

CodeRed, 12+• buffer overruns, integer

overflows, malformed URL• SSRP, RPC, HTTP,

Telnet, SMB, RTP, SMTP



30/40


Outline


31/40


Applicability of Shield



32/40


Application Throughput





33/40


Application Throughput (CPU)



Dell PWS650 3.06 Ghz CPU, 1GB RAM, Windows SP1

34/40


Application Throughput (Mbps)



1Gbps Switch

35/40


False Positives

• They obtained a stress test suite for SSRP from the vendor• The test suite contains a total of 36 test

cases for exhaustive testing of SSRP requests of various forms.

• Running this test suite against our Shield, they did not observe any false positives.

• Of course, this example does not prove that Shield is false positive-free.

36/40


Outline


37/40


Related Work

• Static checkers that perform data flow analysis over source code have been effective in finding software defects systematically before software releases.• However, such tools are not false negative-free.

• Attack prevention techniques address attacks against known vulnerabilities.• These techniques make use of well-defined

invariants, namely the known vulnerabilities.• Shield falls into this category.

38/40


Related Work (cont’d)

• Firewall can be used for worm containment.• but work in a much cruder way,• and they are not deployed on the end host• un-aware of most application level protocol

• Exploit signature-based Network Intrusion Prevention systems (NIPS) filter out malicious traffic according to attack signatures.• The signatures are typically in the form of regular

expressions.• polymorphism

39/40


Related Work (cont’d)

• Rate-limiting and scanning worm containment are mostly useful for fast-spreading worms, rather than the “stealthy” kind.

• Network Intrusion Detection Systems (NIDS), exemplified by Bro and Snort, monitor network traffic and detect attacks of known exploits.• more customized by application than firewalls, but

deal with known exploits rather than known vulnerabilities

• Honeypots, Network Telescope

40/40


Conclusion and Further Work

• They have shown that network-based vulnerability-specific filters are feasible to implement, with low false positive rates, manageable scalability, and broad applicability across protocols.• The range of Shield's applicability and the adequacy of the

Shield policy language.• Develop automated tools to ease Shield policy generation• Deploy Shield in a firewall or router, or a special purpose box• Automating the Shield’s testing process• Ensuring the secure, reliable and expeditious distribution of

Shields is crucial• Apply Shield to virus problem