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 > Initiator- host that starts a session > 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 system’s 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 > so that it works transparently Minimal training > uses only a small number of examples Automation > 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 Don’t care: opaque fields appearing in only one side of the dialog

10. Work of RolePlayer Preparation > first searches for end-point addresses & argument fields > then for length fields and cookie fields Replay > first searches for new values of dynamic fields > then updates them with new values

11. Service Protocol Discovery (SPD)

12. SPD cont’d Requests have seven fields: LEN-0: holds length of message TYPE: message type (1->request, 2->response) 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 YES Start Replay Next Packet? Finish Replay Send or Rcv? Rcv Packet Last Packet? Find Dynamic Fields in ADU First Packet? Send Packet Update 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/encrypted 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.