Shield: Vulnerability-Driven End- Host Firewall for Preventing Known Vulnerability Attacks Sigcomm...
-
Upload
daniel-atkinson -
Category
Documents
-
view
217 -
download
0
Transcript of Shield: Vulnerability-Driven End- Host Firewall for Preventing Known Vulnerability Attacks Sigcomm...
Shield: Vulnerability-Driven End-Host Firewall for Preventing Known
Vulnerability Attacks
Sigcomm ’04
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
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
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
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
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";
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
Vulnerability Modeling
S0
V4 S5
S2
Application Functionality in S2
Protocol State Machine
S4V4
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
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
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
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
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)
Achieving Safety: GAPALProtocol <protoName> { uses <lowerLayerName> transport = { TCP|UDP/<port> } // session-local vars <baseType> <varName>;
grammar { // msg-local vars <baseType> <varName>; NonTerminal <name>:<type>
{ <code>}….
};
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
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
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
Raw bytesSpec ID
Event for Session i
Interpret (Handler)ParsePayload
DropTearDownSession
New Policies
Per-AppSpec
SessionState
SessionState
SessionState i
How to parse messageHow to identify a session HandlerAt(State, Event)
SessionDispatcher
PolicyLoader
ApplicationDispatcher
State MachineEngine
ShieldInterpreter SetNextState
Raw bytesPort #
CurState
Exe->Spec ID
Shield Architecture
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
Comparison Across DefensesSoftware Patch Firewall Traditional IDS Shield
Time Window After patching After vul discovery
After vul discovery
After vul discovery
Vul-specific? Yes Service-specific Exploit-specific Yes
Working Layer Application Network Transport Transport to Application
Easy to Deploy No Yes Yes Yes
False Alarming No High Medium Low
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.
NetShield: Massive Semantics-Based Vulnerability Signature Matching for
High-Speed Networks
Sigcomm ’10
Motivation of NetShield
Theoretical accuracy limitation of regex
State of the art regex Sig
IDSesNetShield
Existing Vulnerability
Sig IDS
Accuracy HighLow
Low
Hig
hS
peed
21
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”])>300RuleID Method == Filename == Header == LEN
1 DELETE * *
2 POST Header.php *
3 * awstats.pl *
4 * fp40reg.dll name==“host”; len(value)>300
5 * * name==“User-Agent”; len(value)>544
Matching AlgorithmsCandidate Selection Algorithm1.Pre-computation: Decides the rule order and
matcher order2.Runtime: Decomposition. Match each matcher
separately and iteratively combine the results efficiently
23
2424
Step 2: Iterative Matching
RuleID Method == Filename == Header == LEN
1 DELETE * *
2 POST Header.php *
3 * awstats.pl *
4 * fp40reg.dll name==“host”; len(value)>300
5 * * name==“User-Agent”; len(value)>544
PDU={Method=POST, Filename=fp40reg.dll, Header: name=“host”, len(value)=450}
S1={2} Candidates after match Column 1 (method==)S2= S1 A2 +B2 ={2} {}+{4}={}+{4}={4}S3=S2 A3+B3 ={4} {4}+{}={4}+{}={4}
1 ii AS
Si1 ii AS
Don’t care matcher i+1
requirematcher i+1 In Ai+1
R1
R2
R3
High Speed Parsing
• NetShield uses stream parser to save memory and running overhead.
Tree-based vs. Stream Parsers
Keep the whole parsetree in memory
Parsing and matchingon the fly
Parse all the nodes in the tree
Only signature relatedfields (leaf nodes)
VS.
VS.
25
Parsing Results
Trace TH DNS
TH WINRPC
NU WINRPC
TH HTTP
NU HTTP
DARPA HTTP
Avg flow len (B) 77 879 596 6.6K 55K 2.1K
Throughput (Gbps) Binpac Our parser
0.313.43
1.4116.2
1.1112.9
2.107.46
14.244.4
1.696.67
Speed up ratio 11.2 11.5 11.6 3.6 3.1 3.9Max. memory per connection (bytes)
16 15 15 14 14 14
26
Parsing+Matching Results
Trace TH WINRPC
NU WINRPC
TH HTTP
NU HTTP
DARPA HTTP
Avg flow length (B) 879 596 6.6K 55K 2.1K
Throughput (Gbps)
Sequential
CS Matching10.6814.37
9.2310.61
0.342.63
2.3717.63
0.281.85
Matching only timespeedup ratio
4 1.8 11.3 11.7 8.8
Avg # of Candidates 1.16 1.48 0.033 0.038 0.0023Avg. memory per connection (bytes)
32 32 28 28 28
11.08-core
27
Scalability Results
0 200 400 600 800
01
23
4
# of rules used
Th
rou
gh
pu
t (G
bp
s)
Performancedecreasegracefully
28
Contribution
• Significantly speed up vul sig matching, making vul-based IDS practical.
Limitation
• No support for stateful vul. compared with Shield.
• Speed-up is only effective for symbolic constraint signature.– “HttpMethod=POST && HttpFilename=header.php”