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

8. Vulnerability Modeling S0 V4S5 S2 Application Functionality in S2 Protocol State Machine S4 V4 Vulnerability 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 Exploit Event S0 S3 S2S1 S5 Message

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 Protocol { uses transport = { TCP|UDP/ } // session-local vars ; grammar { // msg-local vars ; NonTerminal  : { } …. }; State-machine { (, IN|OUT|Timeout)  handler; initial-state = ; final-state = ; }; Session-identifier ( ) { return ; }; Handler ( ) { // handler-local vars ; return “ ; }; }; // protocol

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. Raw bytes Spec ID Event for Session i Interpret (Handler) ParsePayload Drop TearDownSession New Policies Per-App Spec Session State Session State Session State i How to parse message How to identify a session HandlerAt(State, Event) Session Dispatcher Policy Loader Application Dispatcher State Machine Engine Shield Interpreter SetNextState Raw bytes Port # CurState Exe->Spec ID 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 Software PatchFirewallTraditional IDSShield Time WindowAfter patchingAfter vul discovery Vul-specific?YesService-specificExploit-specificYes Working LayerApplicationNetworkTransportTransport to Application Easy to DeployNoYes False AlarmingNoHighMediumLow

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 21

22. 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 RuleIDMethod ==Filename ==Header == LEN 1DELETE** 2POSTHeader.php* 3*awstats.pl* 4*fp40reg.dllname==“host”; len(value)>300 5**name==“User-Agent”; len(value)>544

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

24. 24 Step 2: Iterative Matching RuleIDMethod ==Filename ==Header == LEN 1DELETE** 2POSTHeader.php* 3*awstats.pl* 4*fp40reg.dllname==“host”; len(value)>300 5**name==“User-Agent”; len(value)>544 PDU={Method=POST, Filename=fp40reg.dll, Header: name=“host”, len(value)=450} S 1 ={2} Candidates after match Column 1 (method==) S2=S2=S1S1 A2A2 +B2+B2 ={2}{}+{4}={}+{4}={4} S 3 =S 2 A3+B3A3+B3 ={4}{4}+{}={4}+{}={4} Si Don’t care matcher i+1 require matcher i+1 In A i+1 R1 R2 R3

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

26. Parsing Results Trace TH DNS TH WINRPC NU WINRPC TH HTTP NU HTTP DARPA HTTP Avg flow len (B) 778795966.6K55K2.1K Throughput (Gbps) Binpac Our parser 0.31 3.43 1.41 16.2 1.11 12.9 2.10 7.46 14.2 44.4 1.69 6.67 Speed up ratio 11.211.511.63.63.13.9 Max. memory per connection (bytes) 1615 14 26

27. Parsing+Matching Results TraceTH WINRPC NU WINRPC TH HTTP NU HTTP DARPA HTTP Avg flow length (B) 8795966.6K55K2.1K Throughput (Gbps) Sequential CS Matching 10.68 14.37 9.23 10.61 0.34 2.63 2.37 17.63 0.28 1.85 Matching only time speedup ratio 41.811.311.78.8 Avg # of Candidates 1.161.480.0330.0380.0023 Avg. memory per connection (bytes) 32 28 11.0 8-core 27

28. Scalability Results Performance decrease gracefully 28

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

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