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 HighLowLow

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 == LEN1 DELETE * *2 POST Header.php *3 * awstats.pl *4 * fp40reg.dll name==“host”; len(value)>3005 * * 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 == LEN1 DELETE * *2 POST Header.php *3 * awstats.pl *4 * fp40reg.dll name==“host”; len(value)>3005 * * 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 ParsersKeep 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.1KThroughput (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.1KThroughput (Gbps) Sequential CS Matching

10.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

Thro

ughp

ut (G

bps)

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”