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
Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits
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
Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits
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
Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits
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
Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits
Introduction (cont’d)
• 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
Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits
Introduction (cont’d)
• 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
Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits
Outline
• Introduction• Vulnerability Modeling and Shield Usage• Shield Architecture• Detailed Design Issues• Shield Policy Language• Analysis and Implementation• Evaluations• Related Work and Conclusions
8/40
Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits
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
Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits
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
Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits
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
Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits
Vulnerability Modeling (cont’d)
QuickTime™ and aTIFF (Uncompressed) decompressor
are needed to see this picture.
12/40
Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits
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: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits
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
Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits
Outline
• Introduction• Vulnerability Modeling and Shield Usage• Shield Architecture• Detailed Design Issues• Shield Policy Language• Analysis and Implementation• Evaluations• Related Work and Conclusions
15/40
Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits
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: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits
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: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits
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
Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits
QuickTime™ and aTIFF (Uncompressed) decompressor
are needed to see this picture.
19/40
Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits
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
Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits
Outline
• Introduction• Vulnerability Modeling and Shield Usage• Shield Architecture• Detailed Design Issues• Shield Policy Language• Analysis and Implementation• Evaluations• Related Work and Conclusions
21/40
Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits
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
Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits
Outline
• Introduction• Vulnerability Modeling and Shield Usage• Shield Architecture• Detailed Design Issues• Shield Policy Language• Analysis and Implementation• Evaluations• Related Work and Conclusions
23/40
Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits
QuickTime™ and aTIFF (Uncompressed) decompressor
are needed to see this picture.
Slammer
24/40
Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits
QuickTime™ and aTIFF (Uncompressed) decompressor
are needed to see this picture.
CodeRed
QuickTime™ and aTIFF (Uncompressed) decompressor
are needed to see this picture.
25/40
Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits
MSBlast
QuickTime™ and aTIFF (Uncompressed) decompressor
are needed to see this picture.
26/40
Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits
Outline
• Introduction• Vulnerability Modeling and Shield Usage• Shield Architecture• Detailed Design Issues• Shield Policy Language• Analysis and Implementation• Evaluations• Related Work and Conclusions
27/40
Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits
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
Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits
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
Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits
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
QuickTime™ and aTIFF (Uncompressed) decompressor
are needed to see this picture.
30/40
Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits
Outline
• Introduction• Vulnerability Modeling and Shield Usage• Shield Architecture• Detailed Design Issues• Shield Policy Language• Analysis and Implementation• Evaluations• Related Work and Conclusions
31/40
Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits
Applicability of Shield
QuickTime™ and aTIFF (Uncompressed) decompressor
are needed to see this picture.
32/40
Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits
Application Throughput
QuickTime™ and aTIFF (Uncompressed) decompressor
are needed to see this picture.
QuickTime™ and aTIFF (Uncompressed) decompressor
are needed to see this picture.
33/40
Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits
Application Throughput (CPU)
QuickTime™ and aTIFF (Uncompressed) decompressor
are needed to see this picture.
Dell PWS650 3.06 Ghz CPU, 1GB RAM, Windows SP1
34/40
Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits
Application Throughput (Mbps)
QuickTime™ and aTIFF (Uncompressed) decompressor
are needed to see this picture.
1Gbps Switch
35/40
Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits
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
Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits
Outline
• Introduction• Vulnerability Modeling and Shield Usage• Shield Architecture• Detailed Design Issues• Shield Policy Language• Analysis and Implementation• Evaluations• Related Work and Conclusions
37/40
Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits
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
Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits
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
Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits
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
Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits
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
Top Related