1. Shield: Vulnerability-Driven Network Filters for Preventing Known Vulnerability Exploits H. Wang, C. Guo, D. Simon, and A. Zugenmaier Microsoft Research

2. Motivation Slammer, MSBlast, CodeRed, Nimda, all exploit known vulnerabilities whose patches are already released. Software patching has not been an effective first line worm defense.

3. Why don’t people patch? Disruption –Service or machine reboot Unreliability –Patches can have serious undetected side effects Irreversibility –Most patches are not designed to be easily reversible Unawareness –Miss a patch announcement

4. Our Proposal: Shielding Before Patching Shields: vulnerability-specific network filters that lie above the transport layer. Currently focused on end-host based shields. Patch is the ultimate fix of the vulnerability –Shield is removed upon patch application

5. Why apply Shields instead? Non-intrusive –No service or machine reboot Easy testability – Reliable –Configuration independent, unlike patches Easily reversible

6. 1.Write a policy 2.A syntax tree is made from the policy Ex: the arrival of a UDP packet at port 1434 with a size of 376 bytes is the Slammer worm Vulnerability Modeling

7. Shield Architecture: Goal Minimize the amount of state maintained by Shield Enough flexibility to support any application level protocol Defensive design –Shield does not become an easier alternative attack target

8. Flexibility: Separate Policy from Mechanism Shield Mechanisms: generic for all applications –Out-of-order datagram handling –Application level fragmentation handling Shield Policies: dependent on application –Application identification –Event identification –Session identification –Vulnerability state machine specifications

9. Shield Architecture: Essential Data Structures Per-app vulnerability state machine spec (Spec): –Transformed from Shield policy –Instructions for emulating vulnerability state machines in Shield at the runtime: Application identification: static or dynamic port States, events, handlers for recognizing and reacting to potential exploits The offset and size of necessary information in the packet Session State: current state for exploit-checking

10. Shield Architecture

11. Shield Modules Policy Loader: Turns the Shield policy expressed in the Shield policy language into the syntax tree Application Dispatcher: Determines which Spec to reference for the arrived data based on the port number Session Dispatcher: Recognizes the event type and session ID State machine Instance (SMI): Consults which event handler to invoke Shield Interpreter: Interprets the event handler, which specifies how to examine for exploits. Also carries out actions like packet dropping and registering dynamic port.

12. Scattered Arrivals of an Application Message Each data does not necessarily represent a complete application level message An application message is the smallest interpretable unit by the application Parsing state: the name of the current incomplete field, the value of the current incomplete field only if the value is needed by Shield later –Per application message

13. Out-of-Order Application Datagrams Save out-of-order datagrams Additional information needed in Shield policy: sequence number location and max number of saved datagrams

14. Application Level Fragmentation Treated the same as scattered arrivals Additional information needed in Shield policy: frag ID location

15. Shield Policy Language Describes the vulnerabilities and their countermeasures for an application Highly specialized for Shield’s purpose

16. (state transition) Policy description (MSBlast) (state, event, handler) (handlers) maybe MSBlast not MSBlast It’s MSBlast. Tear down session. (events) (Shield description) (information location)

17. Analysis: Scalability Number of Shields doesn’t grow indefinitely, because Shields are removed upon corresponding patching N Shields for N applications are equivalent to a single Shield in terms of their effect on the performance of any single application Multiple vulnerabilities of a single application can be compounded

18. Analysis: False Positives Low false positives by nature –Filters only traffic that exploits a specific vulnerability False positives may arise from incorrect policy specification due to misunderstanding –Can easily be debugged with large traffic trace or test suites

19. Shield Prototype Implementation Shield Prototype Using WinSock2 LSP

20. Evaluation: Applicability (1) What are hard to shield: –Virus Anti-virus software would be a better alternative –Vulnerabilities that could be embedded in HTML scripting –Application-specific encrypted traffic May be hard to get the key

21. Evaluation: Applicability (2) Study of 49 vulnerabilities from MS Security bulletin board in 2003. While many vulnerabilities may not appear to be suitable for the Shield treatment, the most threatening ones (those prone to exploitation by worms) are Shield-compatible.

22. Evaluation: CPU Usage CPU Usage at the server. Most overhead is caused by LSP, not by Shield.

23. Evaluation: Throughput Shield degrades the throughput by 11 %. A well-designed kernel implementation of Shield could eliminate much of the overhead.

24. Evaluation: False Positives Evaluated on Shield for Slammer Used a stress test suite obtained from MS test group which contains a total of 36 test cases for exhaustive testing. No false positives observed.

25. Conclusion Shield: vulnerability-specific network filters for preventing exploits against known vulnerabilities Initial prototyping and evaluation results are encouraging