Protocol-Independent Adaptive Replay of Application Dialog

1
Protocol-Independent Adaptive Replay of
Application Dialog

• Authors Vern Paxson, Nicholas C. Weaver, Randy
  H. Katz
• Published At 13th Annual Network and Distributed
  System Security Symposium, Feb 2006
• Presented By Anvita Priyam

2
Overview

• Intent of the Paper
• RolePlayer, Its properties and goals
• Mechanism
• Evaluation
• Weaknesses
• Suggestions for improvement

3
Application Dialog

• Refers to recorded instance of an application
  session
• Two main entities
• gt Initiator- host that starts a session
• gt Responder- The entity which the
  initiator contacts

4
Why do we need Replay??

• Different attacks exploiting the same
  vulnerability often conduct same application
  dialog.
• When developing new security mechanism repeat
  attacks to evaluate the systems response.

5
RolePlayer

• A system which mimics both client and server
  sides of the session.
• It uses examples of an application session

6
Key Properties

• Operates in application-independent fashion
• Does not require specifics of the application
  that it mimics
• Uses byte-stream alignment algorithms
• Heuristically determines and adjusts IP
  addresses, ports, cookies and length fields

7
Goals

• Protocol Independence
• gt so that it works transparently
• Minimal training
• gt uses only a small number of
  examples
• Automation
• gt correct operation without manual
  intervention

8
Basic Idea

• Locates the dynamic fields in an application data
  unit (ADU)
• Adjusts them as necessary before sending the ADUs

9
Types of Dynamic Fields

• Endpoint-address hostnames, IP addresses, port
  numbers
• Length length of ADU/subsequent dynamic field
• Cookie session specific opaque data e.g.
  transaction id
• Argument domain name, destination directory
• Dont care opaque fields appearing in only one
  side of the dialog

10
Work of RolePlayer

• Preparation
• gt first searches for end-point addresses
  argument fields
• gt then for length fields and cookie
  fields
• Replay
• gt first searches for new values of
  dynamic fields
• gt then updates them with new values

11
Service Protocol Discovery (SPD)
12
SPD contd

• Requests have seven fields
• LEN-0 holds length of message
• TYPE message type (1-gtrequest, 2-gtresponse)
• SID session identifier (server echoes in
  response)
• LEN-1 Length of HOSTNAME
• LEN-2 Length of SERVICE
• Responses have five
• LEN-0, TYPE SID are same
• LEN-1 Length of IP-port field

13
Preparation Stage
14
Replay Stage

• 
  NO
• 
  
• 
  Yes
• SEND
  RECEIVE
• NO
  
  
  
• 
  
  NO
• YES
  
  
• 
  
  YES

Start Replay
Next Packet?
Finish Replay
Send or Rcv?
Rcv Packet
First Packet?
Send Packet
Last Packet?
Update Dynamic Fields in ADU
Find Dynamic Fields in ADU
15
Test Environment

• Isolated testbed, set of nodes running on VMWare
  Workstation
• Both Windows XP Professional, Fedora Core 3
  images were used
• RolePlayer ran in the Linux host system

16
Evaluation
17
Weaknesses

• Its coverage is not universal
• Can not accommodate protocols with time-dependent
  states
• Protocols using cryptographic authentication/encry
  pted traffic are out of league
• Adversary can detect its presence through the
  unchanged dynamic fields
• It can be detected due to inconsistency b/w OS of
  application RolePlayer.

18
Suggestions

• Randomize certain dynamic fields
• Manipulate packet headers to match expected
  operating OS.
• Identify test additional, complex application
  protocols.