1. 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. Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits 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. Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits 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. Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits 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. Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits 5/40 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. Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits 6/40 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. Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits 7/40 Outline Introduction Vulnerability Modeling and Shield Usage Shield Architecture Detailed Design Issues Shield Policy Language Analysis and Implementation Evaluations Related Work and Conclusions

8. Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits 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. Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits 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. Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits 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. Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits 11/40 Vulnerability Modeling (cont’d)

12. Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits 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. Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits 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. Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits 14/40 Outline Introduction Vulnerability Modeling and Shield Usage Shield Architecture Detailed Design Issues Shield Policy Language Analysis and Implementation Evaluations Related Work and Conclusions

15. Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits 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. Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits 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. Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits 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. Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits 18/40

19. Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits 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. Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits 20/40 Outline Introduction Vulnerability Modeling and Shield Usage Shield Architecture Detailed Design Issues Shield Policy Language Analysis and Implementation Evaluations Related Work and Conclusions

21. Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits 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. Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits 22/40 Outline Introduction Vulnerability Modeling and Shield Usage Shield Architecture Detailed Design Issues Shield Policy Language Analysis and Implementation Evaluations Related Work and Conclusions

23. Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits 23/40 Slammer

24. Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits 24/40 CodeRed

25. Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits 25/40 MSBlast

26. Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits 26/40 Outline Introduction Vulnerability Modeling and Shield Usage Shield Architecture Detailed Design Issues Shield Policy Language Analysis and Implementation Evaluations Related Work and Conclusions

27. Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits 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. Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits 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. Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits 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. Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits 30/40 Outline Introduction Vulnerability Modeling and Shield Usage Shield Architecture Detailed Design Issues Shield Policy Language Analysis and Implementation Evaluations Related Work and Conclusions

31. Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits 31/40 Applicability of Shield

32. Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits 32/40 Application Throughput

33. Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits 33/40 Application Throughput (CPU) Dell PWS650 3.06 Ghz CPU, 1GB RAM, Windows SP1

34. Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits 34/40 Application Throughput (Mbps) 1Gbps Switch

35. Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits 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. Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits 36/40 Outline Introduction Vulnerability Modeling and Shield Usage Shield Architecture Detailed Design Issues Shield Policy Language Analysis and Implementation Evaluations Related Work and Conclusions

37. Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits 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. Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits 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. Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits 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. Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits 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