Se ha denunciado esta presentación.
Se está descargando tu SlideShare. ×

Analysis & Signature of Skype VoIP Session Traffic.pptx

Cargando en…3

Eche un vistazo a continuación

1 de 51 Anuncio

Más Contenido Relacionado

Más reciente (20)


Analysis & Signature of Skype VoIP Session Traffic.pptx

  1. 1. Analysis & Signature of VoIP Session Traffic AHMED SOHAIR KHAN FA2019/MSEE-008
  2. 2. Introduction  Skype is a peer-to-peer VoIP application launched in 2003  None of Skype's algorithms or its protocol specification are available for public inspection  Skype uses a proprietary signaling and media protocol for voice calling, instant messaging, audio conferencing and file transfers  End-to-end encrypted, currently not known what exact information is transported with the application  This also impedes Protocol analysis for potential security holes  User-friendly, deliver mechanisms to circumvent many applied network security restrictions i.e NAT, firewall, proxy
  3. 3. AIM “To Analyze network traffic with the goal to detect patterns that are intrinsic to the Skype protocol”
  4. 4. Sequence  Literature review/Previous work done in the field  Skype Operation Overview  Methodology  Analysis  Skype Message Flow Analysis  Skype Detection Signature  Conclusion/Future Work
  5. 5. Literature Review  Not yet widely covered in the research community, due to Skype’s Closed Operation Model  Suh et al.  Monitor Skype traffic using relay nodes.  Instead of examining payload content they use heuristics and statistical analysis to detect Skype traffic  Guha et al.  Measure combined Skype signaling and media traffic and present a Skype traffic model and compare it to other peer-to-peer applications
  6. 6. Literature Review  Baset and Schulzrinne.  Present a broad analysis of Skype operation mechanisms, including basic Skype message flows. Their analysis is based on older versions of the Skype protocol up to version 1.4  Did no present a detection signature  Fabrice.  Presented first results in his attempt to reverse engineer Skype.  Outlines possibilities to debug the Skype binary application and shows initial results in decrypting Skype's protocol operation
  7. 7. Skype Operation Overview  Unlike client-server based SIP, Skype uses an overlay peer-to-peer (P2P) network [baset]  Three Main Components of Skype Network:  Skype Login Server (LS)  Central component of the network. Used for User Authentication  Skype Client (SC)  Participating user. Provide all user functionality i.e. login, initiate and receive calls, instant messages and file transfer  Super Node (SN)  Any SC can also become a super node.  Provides additional functionality to other SN & SC
  8. 8. Super Node (SN)  Routing tasks such as forwarding requests to appropriate destinations and answer to queries from other SC or SN  Forward login requests if login server is unreachable directly from a SC  Provide media proxying capabilities for other SC that have restricted internet access i.e. NAT or Firewalls  Every SC will automatically become a SN if it meets certain criteria, e.g. high speed and unrestricted internet access  Generally difficult to prohibit a SN from becoming a SN  Several SN are hard coded into the SC's executable. These bootstrap SN are contacted upon first launch of the client to gather an updated and more extensive list of currently available SN.  Baset lists seven different bootstrap SN
  9. 9. Skype Operation Overview  Except for some dedicated operations like authentication, user list storage or Skype-to-PSTN connectivity, there are no further central servers in the Skype  All other operations performed in a decentralized way by the SN  Both signaling and media traffic is encrypted  Only one message contains plain text  After installation, SC contacts the Skype web page to check for latest update
  10. 10. Skype Operation Overview
  11. 11. Methodology  Conducted on Windows XP  Skype versions 1.4 and 2.0  Ethereal packet sniffer  Analyze only signaling traffic  Modified network parameters at both nodes to gain a broader data set  Firewall (3 diff settings):  No firewall protection  UDP/TCP incoming port restriction  Both incoming & outgoing port restrictions
  12. 12. Methodology  NAT :  Public IP addresses without NAT  Private IP addresses behind a full-cone NAT  These combinations varied between caller and callee  Operations:  Creating a new account  Logging in to skype network  Logging in to the Skype network with known contacts of other Skype users are stored already in Skype’s “Buddy list” Online & offline  Login with different user names, and also with wrong credentials  Different call scenarios
  13. 13. Methodology  Re-iteration of tests several times  2 methods for re-iteration:  Simply logging off  Complete uninstallation of skype including registry  Analysis focus on:  Protocol and port usage  Packet size (denoted as ‘s’), identified as content after TCP/UDP header  Packet Content (when clear characteristics are discernable)
  14. 14. Skype Port Analysis  Uses both UDP & TCP  As fallback, use TCP port 443 (https) and 80 (http)  For UDP traffic, generally arbitrarily set port. The user can change this port number from SC's configuration dialogue  The only fixed UDP port number is 33033, used to contact bootstrap SN  We could not devise a pattern for UDP port usage if this port is not selected by the user  Even though skype uses both UDP & TCP, UDP is not mandatory for its operation. SC was able to login even with only TCP
  15. 15. Skype Port Analysis  For TCP, the SC tries to contact other hosts at ports higher than 1024  If firewall, it tries port 443 and then 80  The SC clients selects its source TCP port in the following way:  Initially start at port between 1026 – 1040, increment if no answer  If no answer after 2 hours, it stops sending packet for 30 mins  After restarting skype, it continue from previous number with increment of 5  If wait more than 1 hour before restarting, it again start between port 1024 – 1040  After reaching port 5000, it start over at 1026  Hence skype depends on port 1026 – 5000. If unable to establish connection this way, it gives up with an error  This behavior only in v1.4. Version 2.0 gives error after 8 min
  16. 16. Skype Port Analysis  For Proxy Internet Configuration, the SC tries to directly contact other peers on port over 1024, port 443 and then port 80  It only uses proxy as a fallback if it can not establish direct connection  Hence proxy can be used for skype traffic monitoring only in case where internet access is available exclusive behind a proxy
  17. 17. Skype Message Flow Analysis  Skype exchanges messages whenever a user logs in to the network  General Query / Response Patterns  A key feature discovered in UDP messages from client to different destinations (not those which are sent as reply to a message)  First two bytes of those UDP requests contain a number that is increased by two on every new request  Number is of 16 bit size  First request is sent using an arbitrarily selected number  Increase occurs with every new initiating connection, independent of the destination  This might be a global session identifier for Skype  we have witnessed a pattern for the third byte for messages with s = 26, 51 or 53 byte. These bytes are either set to 0x02 or have the lower nibble3 set to 0xd
  18. 18. Skype Message Flow Analysis  General Query / Response Patterns Increment of 2 on every new request First 2 bytes
  19. 19. Skype Message Flow Analysis  Skype Network Traffic Analysis  Three distinct tasks a SC performs after application startup 1. UDP Probe : check network restrictions and contacts potential SN (U1-U4) 2. TCP SN Handshake : SC connects to a SN to establish a permanent connection to last for the whole session (T1-T4) 3. TCP Authentication : SC contacts a Login Server (LS) for authentication (L1-L4)
  20. 20. UDP Probe  After startup, a SC initiates a double-two-way handshake:  2 queries (U1 & U3)  2 responses (U2 & U4)  Dest port 33033 when bootstrap SN and user preference for others  Different message size of U1 & U3 for v1.4 & v2.0  With Skype v1.4, s(u1) is fixed at 18 byte, while v2.0, s(u1) varies  In both versions, s(u3) = s(u1) + 5 bytes  In both versions, s(u2) = 11 byte & s(u4) is either 18, 51, or 53 byte  These messages were analyzed regarding payload and classified as:  Session identifiers  Function parameters  IP address exchange
  21. 21. UDP Probe Varies for v2.0 Same for both versions
  22. 22. 1. Session Identifiers  U1 is a initiating message, hence the first two bytes in this message contain a session identifier  Discovered equal session identifiers in U2 & U3  However, this match is not kept with U4
  23. 23. 2. Function parameters  The third byte of a message seems to be a message type encoding  We have observed that this value is 0x02 for U1 & U4  The value changes for both U2 & U3, however, the lower nibble stays always the same  It is 0x7 for U2 and 0x3 for U3  In the case of U3, we have witnessed that the 4th byte of the message has always the value 0x01
  24. 24. 3. IP Address Exchange  The remainder of these messages contain 4 x four-byte-values exchanged between the SC & the SN  We have discovered that two of these 4-tuples contain IP addresses of the originating & destination network  These exchanges were observed within U2 & U3  U2(4-7) contains the SC's IP address, while U3(9-12) contains the SN's IP address  We assume that this message exchange is part of Skype's NAT detection algorithm  These address fields never contain private addresses. Instead, the host's publicly visible (e.g. the address of the NAT device) is transferred  Two other 4-tuples are transported twice over the network and occur in the following way:  U1(8-11) = U3(13-16) and U2(8-11) = U3(5-8)  The significance of these two 4-tuples is unknown
  25. 25. 3. IP Address Exchange  We observed that If s(U4) = 18 byte, the SC successively attempts to establish a TCP connection to the same SN  If s = 51 or 53 byte, no TCP connection is initiated and the SC contacts another host with a simpler handshake  This means that only s =18 is affirmative and 51 or 53 is reject or redirect  The successive, simpler handshake consists only of a message like U1 with an answer resembling U4; U2 and U3 don't occur
  26. 26. 3. IP Address Exchange  This simpler pattern is continued until a TCP connection is established  Depending on the number of messages exchanged (four or two) we refer to a full UDP probe or a partial UDP probe  The SC continues to initiate partial UDP probes, even after it has been logged into the Skype network (in case the SC changes its contacted SN)
  27. 27. TCP SN Exchange  SC needs at least one open TCP connection to a SN to successfully login. TCP connection setup works as fol:  A TCP connection is initiated to a potential SN after a positive UDP probe. Port remains same  If the TCP connection is closed or times out, the SC initiates other TCP connections with positively UDP probed hosts  If a TCP connection is successful, SC and SN exchange messages. After this handshake the TCP connection either is kept alive or closed  If the TCP connection is kept alive, it is closed only when the user terminates the application.  However, if the previous SN can not operate as a SN any more or becomes unavailable, new connection established  In this case the new TCP connection is established in the same way the previous connection was established
  28. 28. TCP SN Exchange  TCP message flow consists of several messages exchanges between SC and SN  Within the first six messages exchanged, the SC and SN agree upon keeping this connection or dropping it  Skype “pushes” – i.e. sends TCP messages with the PSH bit set  A pattern has been determined based on TCP payload size  For skype v1.4, after TCP connection message with payload size s = 14 byte (T1) is sent by SC  Followed by message of varying size  SC sends third message with s between 22 & 29 byte, replied with message of varying size (T3)  This message is ack by SC with s = 4,15,16 or 17 bytes (T4)
  29. 29. TCP SN Exchange  Whenever the SN sends T3 with s = 339 byte, TCP connection is terminated and the SC tries to establish a different connection to another SN  Why other size different from 339 byte and bigger than 57 byte, the TCP connection will be kept alive  Same happens in Skype v2.0, except that T1 size is not fixed at s = 14 bytes, but varies.  Additional message is sent to the SN before T2. T2, T3, and T4 stay the same
  30. 30. TCP SN Exchange with TCP Restriction  When SC unable to establish regular TCP connection, it tries TCP connection over port 443 and 80  Well known ports, but protocol used is different  Skype uses a modification of the Transport Layer Security (TLS) protocol for port 443, but it does not utilize HTTP over port 80  In restricted mode, 3 messages are exchanged R1-R3 followed by slightly modified SN TCP handshake (consisting only T2 – T4)  R1-R3 vary depending on port and skype version
  31. 31. Port 443 Operation  We observe that in both versions, s(R1) = 72 byte  R1's payload begins with the 56 byte sequence (hexadecimal notation)  It is observed that this sequence is a fully compliant TLS 1.0 ClientHello message wrapped in a SSLv2 record layer  All observed R1 messages differ only in last 16 bytes  The size of the reply R2 varies, however in about 40% it was 93 byte  The first 79 bytes of R2 are always same (hexadecimal notation)  This pattern is partly modelled after a TLS ServerHello message 56 bytes of R1 79 bytes of R2
  32. 32. Port 443 Operation  It is interesting that the fields which in TLS context must not be static, are static in Skype's usage  These are:  gmt_unix_time R2(12-15) which is fixed at Jan, 31, 2004  random_bytes R2(16-43)  The remainder of R2 from 80 byte onwards does not comply to TLS Standard  The SC responds with R3 with s = 14 bytes for skype v1.4 however it varies for skype v2.0 79 bytes of R2
  33. 33. Port 80 Operation  In Skype v1.4, R1 has always a size of 16 byte. R2 has varying sizes and R3 = 14 byte  In Skype v2.0 R1-R3 are of varying size  No static payload is transmitted in case of port 80. However a pattern is observed:  In Skype v1.4, higher nibbles of R1(5-6) are the same as the higher nibbles R1(15-16)  In Skype v1.4, higher nibbles of R1(6-14) are the same as the higher nibbles R1(16-23)  Special implications if sR1 < 24 byte, as the comparison range will be shorter
  34. 34. Port 80 Operation
  35. 35. TCP Authentication  After TCP Connection established to SN, the SC needs to authenticate itself  2 login servers discovered by Baset are confirmed    4 x TCP messages are exchanged (L1-L4) between SC and LS  First 2 messages are of size 5 bytes, and rest 2 are varying  Further messages exchanged in case of wrong password  After authentication, connection to LS closed
  36. 36. Payload of L1-L4  L1(1-5)  0x16 0x03 0x01 0x00 0x002  L2(1-5)  0x17 0x03 0x01 0x00 0x00  L3(1-15)  0x16 0x03 0x01 0x00 0xcd 0x41 0x03 0x00 0x09 0x80 0x40 0x04 0x08 0xc0 0x01  Additionally, the byte sequence 0x00 0x0c 0x01 0x17 0x03 0x01 0x00 occurs at an undetermined position within L3  L4(1-4)  0x17 0x03 0x01 0x00  bytes sequence 0x16 0x03 0x01 0x00 0x00 also occurs in the beginning of TLS ServerHello  However, in the same context 0x17 0x03 0x01 0x00 0x00 is not a valid TLS message fragment
  37. 37. TCP Authentication  Same pattern observed when connecting to another group of LS    These are only connected when user calls using PSTN  We assume them to be Skype-to-PSTN gateways (SkypeOut)  Another LS group    These are connected whenever a user adds, blocks or deletes an address on his contact list
  38. 38. Restricted Access  Restricted Access to LS  SC relays the traffic through another SN  In this case only messages L3 & L4 exchanged  L1 & L2 not observed  Restricted TCP Access  If TCP access over port 1024 was not allowed, the SC initiated the same handshake over ports 443 and 80  In all three cases the handshake does not differ
  39. 39. Automatic Login  Information is stored encrypted in the file  C:Documents and Settings<usernameApplication DataSkypeuserconfig.xml  The file contains a section <Account> with subsection <credentials> that only occurs whenever the Automatic Login option is enabled  With this option enabled no connection to any LS is observed at startup i.e. no traffic matches messages L1-L4  Enabling Auto Login only affects Login traffic. UDP probe and TCP SN remains the same
  40. 40. Skype Detection Signature  Criteria for signature  Should be Compact  Should consider all possible cases of how traffic can be injected into network  The number of false positives should optimally be zero  These three goals are difficult to achieve with skype  First idea is to detect packets with byte sequence 0x16 0x03 0x01 0x00 0xcd 0x41 0x03 0x00 0x09 0x80 0x40 0x04 0x08 0xc0 0x01 as they always occur in exchange with LS  However in case of Automatic Login enabled, these wont occur  So, a different signature detection is proposed
  41. 41. Skype Detection Signature  Signature Detection based on UDP probe detection & TCP SN Handshake with additional monitoring of port 443 and 80  Step-1  Scans for UDP packets with a payload size of 18 bytes and the third byte of the payload set to 0x02 (U1)  For Skype v2.0 only payload scanning is feasible since the size varies  Save both IP address / port tuple of the originator (CON-SC) and the destination (CON-SN )  Also, save the first two bytes of this message U1(1-2)
  42. 42. Skype Detection Signature  Step-2  Scan for a reply CON-SC ← CON-SN (U2) with s = 11 byte and U2(1-2) = U1(1-2) and the lower nibble of U2(3) = 7  Step-3  Scan for another request CON-SC → CON-SN (U3), with the following three conditions:  s(U3) = s(U1) + 5  U3(1-2) = U1(1-2)  lower nibble of U3(3) = 3
  43. 43. Skype Detection Signature  Step-4  Scan for a reply CON-SC ← CON-SN (U4) with  s(U4) = 18 and U4(3) = 0x02.  We now have detected Skype usage in the network  Step-5  Scan for subsequent occurrences of steps 1-4  This is necessary to detect a possible SN change  Step-6  Scan for a TCP connection CON-SC → CON-SN  This might be TCP SN Handshake
  44. 44. Skype Detection Signature  Step-7  Within this TCP connection scan from a packet CON-SC → CON-SN with s between 22 and 29 byte (T2)  Step-8  Scan for a reply from CON-SC ← CON-SN (T3)  Check if sT3 = 339 byte, in this case the contacted node will not become the SN  Continue again from step 6. This is necessary to detect a possible SN change  Step-9  If s(T3) is not equal to 339 and s(T3) > 57, scan for a final reply from CON-SC → CON-SN, with s = 4, 15, 16, or 17 byte  We now have detected a successful connection from the SC to SN
  45. 45. Skype Detection Signature  Step-10  Continue scanning from step 6 onward to detect a possible SN change during the session  Keep the parameters of the last active SN, discarding previous SN parameters  Step-11  Scan for TCP connection close of the last active SN connection  This signals the termination of Skype usage by the client
  46. 46. Skype Detection Signature  Monitoring Port 443  scan for outgoing packets with s = 72 byte that begin with hexadecimal pattern:  scan for a reply CON-SC ← CON-SN beginning with:  We have detected initial SN communication. Continue with step 7
  47. 47. Skype Detection Signature  Monitoring Port 80  Examine outgoing packets (R1) where the higher nibble of R1(5-6) = higher nibble of R1(15-16) (for Skype v1.4)  Higher nibble of R1(6-14) = higher nibble of R1(16-24) (for Skype v2.0)  Initial SN communication is detected, continue with step 7
  48. 48. Signature Analysis  Signature is complete in a way that it can detect Skype session start & Stop under all known skype operation modes  The signature does not need to take TCP authentication into account since authentication traffic only occurs after connection to SN has been established  Only in the unlikely case that the user has no automatic login activated and provides wrong credentials, this signature detects Skype usage while in fact only the application is running  Actual detection is being done in steps 6-9, other steps are to improve accuracy  The tool was also tested with skype v2.5 and was successfully able to detect skype traffic. However, there was variation in port 80 restricted traffic (R1). Tool was still able to detect by checking TCP SN handshake (Step 7-9)
  49. 49. Conclusion & Future Work  We have been able to determine several characteristics of Skype Protocol through packet inspection  Skype detection is possible through deep packet inspection in combination with port usage correlations  Developed signature is able to detect Skype v1.4 and skype 2.0 traffic from the moment user logs in to skype network untill it logs out from the server  Because of Skype’s p2p character, security operator needs to install monitoring systems at all network ingress points  Patterns differ between the examined version 1.4, 2.0, and 2.5. It is likely that this will continue with newer Skype versions
  50. 50. Conclusion & Future Work  For future, our interest lies in detection of actual voice calls  2 possibilities:  Detect signatures for voice signaling traffic (low possibility due to encryption)  Detect voice calls by analyzing the voice traffic itself  We have concentrated our efforts on Skype traffic occurring immediately after application launch, where full encryption of traffic still has to be established
  51. 51. THANK YOU!