Shield: VulnerabilityDriven Network Filters for Preventing Known Vulnerability Exploits

1
Shield Vulnerability-Driven Network Filters for
Preventing Known Vulnerability Exploits

• H. Wang et. al -- Microsoft Research
• SIGCOMM 2004
• Presented by Amir R. Khakpour khapour_at_cse.msu.edu
  

2
Outline

• Introduction
• Vulnerability Modeling and Shield Usage
• Shield Architecture
• Detailed Design Issues
• Shield Policy Language
• Analysis, Implementations and Evaluations
• Related Works

3
Motivation

• More than 90 of the attacks today are
  exploiting known vulnerabilities
• Worms used the known (for long time)
  vulnerabilities
• Slammer, MSBlast, CodeRed, Nimda
• Software patching is not effective (why?)
• Disruption
• The system or service need to be rebooted
• Unreliability
• The patches are released very fast, so because of
  the possible lack of tests they make the program
  unreliable
• Irreversibility
• Patches are mostly irreversible
• Unawareness
• An administrator may simply miss a patch
  announcement for some reason,

4
Basic Contribution and Approach

• Protect the time window between vulnerability
  disclosure and patch application
• Apply intermediate patching in network stack to
  perform filtering function
• Shield is vulnerability-specific and exploit
  generic
• One Shield per vulnerability
• An application layer approach

5
Introduction

• Shield operates on only network traffic and drop
  the attack traffic
• Shields are non-disruptive and easily reversible
• Automatic installation is also feasible
• Just manipulates the network traffic so it is
  easy to test it

6
Vulnerability Modeling and Shield Usage

• Designing a method of modeling and expressing a
  vulnerability signature
• The vulnerability signature is specifies the
  vulnerability state machine and describes how to
  recognize any exploits and how to react

7
Vulnerability Modeling and Shield Usage

• When a new vulnerability is discovered, a shield
  designer creates a Shield policy for the
  vulnerability (conceptually, there is one Shield
  policy per vulnerability) and distributes it to
  users running the application as in anti-virus
  signature distribution and installation
• Using this policy, Shield intercepts its
  applications traffic and walks through the
  vulnerability state machine when reaching the
  pre-vulnerability state, the Shield examines the
  vulnerable event for possible exploits and takes
  the specified actions to protect against the
  exploits if they are present.

8
Shield Architecture

• Goals
• Minimize and limit the amount of state maintained
  by Shield
• DoS resilient ? It needs to manage its state
  space
• Basically shield, as an end-host-based entity,
  needs to be as DoS-resilient as the service it is
  shielding
• Enough flexibility to support any application
  level protocols
• Needs to encompass any application protocol, at
  the same time independent from the applications
  (since otherwise is not scalable)
• Design Fidelity
• We must design Shield in such a way that Shield
  does not become an easier alternative attack
  target

9
Flexibility

• Separating policy from the mechanism
• Mechanisms generic elements of all application
  level protocols
• Implementation of the application level protocols
  using Finite state automaton
• Datagram-based protocols must support
  out-of-order application datagram for the session
• Implementations of application-level protocols
  that allow message fragments must handle
  fragmentation
• Using an event based system for carrying out the
  state transition
• Policies specifies
• Application identification
• using the service port for this purpose
• Event identification
• how to extract the message type from a received
  message
• Session identification
• how to determine which session a message belongs
  to
• State machine specification
• States, transitions, and

10
When a new policy arrives the old policies will
be updated
Per application vulnerability state machine
specification
Contains the state machine instances (SMIs) where
each instance corresponds to one session.
Extracting multiple messages and recognize the
event type and session ID
The Shield Interpreter interprets event handler,
which specifies how to parse the
application-level protocol payload and examine it
for exploits.
11
Detailed Design Issues

• Scattered Arrivals of an Application Message
• An application message is the smallest
  interpretable unit by the application
• Scattered because Congestion control or
  application-specific message handling
• What to save (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
• How to differentiate parsing state belonging to
  multiple sessions
• Safe to use socket here because only one socket
  should be used for delivering a complete
  application level message despite the M-M
  relationship between sockets and sessions.
• Pre-session copying before the session info
  arrives
• When the session ID is not arrived completely
• The parsing state is associated with the socket
  only
• In-session copying after the session info
  arrives
• The parsing state becomes part of the session
  state

12
Detailed Design Issues

• Out of order arrival
• Shield copies the out-of-order datagrams, and
  passes them on to the applications
• examine the packets in their intended sequence
• Maximum number is same as the application and is
  specified by the policy description
• Application Level Fragmentation
• Working on the top of transport layer, not
  dealing with the IP layer fragmentation, so here
  were talking about the application layer
  re-assembly
• TCP protocols bytes are not out of order
• UDP Protocols the copied datagrams should be
  place in order

13
Shield Policy Language
Policy description of the vulnerability behind
MSBlast
14
Analysis

• Scalability with number of vulnerabilities
• The shields will be removed when its
  corresponding vulnerability is patched
• N Shields for N different applications are
  equivalent to a single shield in terms of their
  effect on the performance of any single
  application (overhead)
• Multiple vulnerabilities in a single application
  has one state machine (preferably)
• Otherwise each packet should be traverse the
  whole state machine
• Not significant because no more than 3 wormable
  vulnerabilities seen in any single application in
  2003
• Application throughput is, at worst, about
  halved and low impact on end customer machines

15
Analysis

• False positive
• Near-zero false positives by nature
• Two sources
• Misunderstanding of protocol and payload spec
  can be debugged
• Different treatment of some network event
• could be an exploit in one runtime setting, and
  yet completely legal in another

16
Implementation
More than 10000 lines of C code using Windows
LSP
17
Evaluation

• Working shields for the vulnerabilities behind
  MSBlast, Slammer, CodeRed
• lt 32 bytes of partial payload saved per session
• Small number of states
• Detailed study over 15 vulnerabilities and
• 7 protocols, such as RPC, HTTP, SMTP, and FTP
• scenario
• Server sends data to client as fast as possible
  in a RPC-like session over an Ethernet switch
• Each session requires 1 KB partial payload saved
• Outgoing shield on the server
• 3.06 GHz CPU and 1GB RAM for both the client and
  server, all run Windows XP SP1

18
Evaluation Shieldability

• What are hard to shield
• Virus
• vulnerability-driven 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.
• But for SSL/TLS, an SSL-based shield framework
  can potentially be built on top of SSL
• Study of 49 vulnerability form MS Security
  Bulletin board in 2003

19
Evaluation

• All achieved max throughput, 92.8 Mbps
• lt 50 clients LSP incurs 11-28 overhead, Shield
  lt3 more
• LSP overhead not inherent

LSP degrades throughput by 12, Shield degrades
by 11 more
20
Evaluation False Positive

• Evaluate on shield for Slammer
• Used an SSRP stress test suite obtained from a
  MS test group 32 test cases for 12 message types
• No false positives observed.
• SSRP (SQL Server Resolution Protocol ) is
  protocol of MS-SQL 2000. SSRP is a very simple
  protocol with only 12 message types.

21
Related Works

• Threats of Internet worms
• 0wn Internet, CodeRed study, Inside Slammer,
  Internet quarantine, Warhol
• Compile-time static checks
• false negatives inevitable
• Mitigation techniques (i.e., Stackguard,
  non-executable stack or heap)
• Can be circumvented by different exploits
• Service DoS
• Firewall
• IPSec traffic
• More coarse-grained, high-false positive solution
• Will be much improved by fast exploit-signature
  generation schemes such as EarlyBird and
  Autograph
• NIDS (such as Bro and Snort), traffic
  normalizers, protocol scrubbers
• Different layers and different purposes from
  Shield

22
Thank you !Questions?