Shield: Vulnerability-Driven End-Host Firewall for Preventing Known Vulnerability Attacks

1. Shield: Vulnerability-Driven End-Host Firewall for Preventing Known Vulnerability Attacks Sigcomm ’04

2. Software patching not an effective first-line defense • Sasser, MSBlast, CodeRed, Slammer, Nimda, Slapper all exploited known vulnerabilities whose patches were released months or weeks before • 90+% of attacks exploit known vulnerabilities [Arbaugh2002] • People don’t patch immediately

3. Why don’t people patch? • Disruption • Service or machine reboot • Unreliability • Software patches inherently hard to test • Irreversibility • Most patches are not designed to be easily reversible • Unawareness

4. Firewall also not an effective first line defense • Traditional firewalls • Typically in the network • One-size-fits-all solution, lack application-awareness, miss end-to-end encrypted traffic • Course-grained • High false positive rate • Exploit-driven firewalls (or 1st gen intrusion detection) • Filter according to exploit (attack) signatures • Attack code obfuscation, e.g., polymorphism, metamorphism, can evade the firewall • Worms spread fast (in minutes or seconds!) • Real-time signature generation and distribution difficult

5. Shields: End-host Vulnerability-Driven Network Filters • Goal: Protect the time window between vulnerability disclosure and patch application. • Approach: Characterize the vulnerability instead of its exploits and use the vulnerability signature for end-host firewalling • Shields combine the best features of • Patches: vulnerability-specific, code level, executable • Firewall: exploit-specific, network level, data-driven • Advantages of Shield: • Protection as good as patches (resilient to attack variations), unlike exploit-driven firewalls • Easier to test and deploy, more reliable than patches

6. Vulnerability vs. Exploit (1:M) • Many exploits against a single vulnerability • E.g., many different strings can overrun a vulnerable buffer • Vulnerability signatures generated at vulnerability discovery time • E.g., sizeof (msg.buffer) > legalLimit • Exploit signatures generated at attack time • E.g., Snort signature for Slammer: alert udp $EXTERNAL_NET any -> $HOME_NET 1434 (msg:"MS-SQL Worm propagation attempt"; content:"|04|"; depth:1; content:"|81 F1 03 01 04 9B 81 F1 01|"; content:"sock"; content:"send";

7. Shield Policies Overview of Shield Usage New Shield Policy • Shield intercepts vulnerable application traffic above the transport layer. • Policy distribution very much like anti-virus signature model – automatic, non-disruptive, reversible Incoming or Outgoing Network Traffic Shielded Traffic to Processes or Remote Hosts End-Host Shield

8. Vulnerability State Machine S0 Message S0 S2 S1 S2 S3 S5 V4 S5 Application Functionality in S2 Vulnerability Modeling V4 S4 Exploit Event Protocol State Machine • Shield Policy (Vulnerability Signature): • Vulnerability state machine + how to recognize and react • to exploits in the vulnerable state • Protocol analysis is the key for vulnerability-driven filtering

9. Shield Architecture: Goals • Flexibility: support protocol analysis for any application level protocols • Fidelity: protocol analysis consistent with that of the application • DoS resilience: hold less state than that of the application

10. Flexibility: separate mechanism from policy • Mechanism: protocol analysis – reconstruct message and session semantics: e.g., parsing, state machine operations • GAPA: generic application-level protocol analyzer • Policy: a language that describes protocol state machine, message formats, and specific vulnerabilities • GAPAL: GAPA language • Shield policy: a GAPAL script that blocks according to a vulnerability

11. Achieving Shield Fidelity • Infidelity results in evasion or false positives • Sources of inconsistencies: • Misunderstanding of the protocol or message format • Test suites or trace-driven debugging • Event dispatching logic: • Session as an abstraction independent of socket or host pair • Scattered message arrivals: • Message as an abstraction independent of the packet

12. Achieve DoS-resilience: • Session state: • Current protocol state • Parsing state • Handler continuation • Parsing: • Exploit-checking only -- much streamlined parsing • Aggressive byte skipping • Save the partial field only (instead of partial message)

13. Achieving Safety: GAPAL State-machine <name> { (<state>, IN|OUT|Timeout)  handler; initial-state = <stateName>; final-state = <stateName>; }; Session-identifier (<startNonTerminal>) { <code> return <session ID>; }; Handler <name> (<startNonTerminal>) { // handler-local vars <baseType> <varName>; <grammar visitor> <post-parsing code> return “<nextState>; }; }; // protocol Protocol <protoName> { uses <lowerLayerName> transport = { TCP|UDP/<port> } // session-local vars <baseType> <varName>; grammar { // msg-local vars <baseType> <varName>; NonTerminal  <name>:<type> { <code>} …. };

14. Key Properties of a GAPAL • Completeness • Binary as well as text-based protocols • Layering • Ease of authoring protocol descriptions • Payload parsing grammar similar to BNF • E.g., HTTP RFC spec - text ~= GPA policy for HTTP • Safety • Strong typing • No dynamic memory allocation • No general-purpose loops or iterators • Semantic checking and optimization at compile time

15. GAPA as a General Facility • Rapid protocol analysis enabler for IDSes, firewalls, and network monitors; and allow flexible customization • Easy authoring of Shield vulnerability signature • Vulnerability signature authoring as refinement of previously specified protocol • Merging vulnerability signatures of the same application becomes trivial

16. Per-App Spec Policy Loader New Policies Exe->Spec ID How to parse message How to identify a session HandlerAt(State, Event) Session Dispatcher State Machine Engine Application Dispatcher Raw bytes Port # Raw bytes Spec ID Event for Session i CurState Interpret (Handler) ParsePayload Shield Interpreter Session State i Drop Session State Session State SetNextState TearDownSession Shield Architecture

17. Shield Implementation and Evaluation • First prototype implemented as Windows Layered Service Provider (LSP) • Working shields for vulnerabilities behind Blaster, Slammer, and CodeRed • Near-zero false positives • Performance and scalability results promising: • Negligible overhead for end user machines • 14-30% throughput overhead for an artificial scenario stressing Shield • Second prototype based on GAPAL • 48Mbps for CodeRed, 72Mbps for host header, 8-18Mbps for Blaster • MSRC 2003 Bulletin study (49 bulletins) • All 12 worm-able vulnerabilities are easily shield-able • Some of the other 37 may also be shield-able

18. Comparison Across Defenses

19. Limitation • Low throughput • Parallelization across protocols? • Difficult to write application-level protocol • Automatic protocol generation? • Protocol parser is coupled with signature, resulting in poor extensibility. • Decouple protocol parser with signature engine.

20. NetShield: Massive Semantics-Based Vulnerability Signature Matching for High-Speed Networks Sigcomm ’10

21. Motivation of NetShield

22. Matching Problem Formulation Suppose we have n signatures, defined on k matching dimensions (matchers) A matcher is a two-tuple (field, operation) or a four-tuple for the associative array elements Translate the n signatures to a n by k table This translation unlocks the potential of matching multiple signatures simultaneously Rule 4: URI.Filename=“fp40reg.dll” && len(Headers[“host”])>300

23. Matching Algorithms Candidate Selection Algorithm Pre-computation: Decides the rule order and matcher order Runtime: Decomposition. Match each matcher separately and iteratively combine the results efficiently

24. Step 2: Iterative Matching S1 A2 Don’t care matcher i+1 S3=S2 A3+B3 ={4} {4}+{}={4}+{}={4} Si require matcher i+1 In Ai+1 PDU={Method=POST, Filename=fp40reg.dll, Header: name=“host”, len(value)=450} S1={2} Candidates after match Column 1 (method==) S2= +B2 ={2} {}+{4}={}+{4}={4} R1 R2 R3 24

25. High Speed Parsing Tree-based vs. Stream Parsers • NetShield uses stream parser to save memory and running overhead. Keep the whole parse tree in memory Parsing and matching on the fly VS. Parse all the nodes in the tree Only signature related fields (leaf nodes) VS.

26. Parsing Results

27. Parsing+Matching Results 11.0 8-core

28. Scalability Results Performance decrease gracefully

29. Contribution • Significantly speed up vul sig matching, making vul-based IDS practical.

30. Limitation • No support for statefulvul. compared with Shield. • Speed-up is only effective for symbolic constraint signature. • “HttpMethod=POST &&HttpFilename=header.php”