Analysis & Signature of Skype VoIP Session Traffic using wireshark

1. Analysis & Signature
of
VoIP Session Traffic
AHMED SOHAIR KHAN
FA2019/MSEE-008

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. AIM
“To Analyze network traffic with the goal to
detect patterns that are intrinsic to the
Skype protocol”

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. 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. 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. 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. 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. 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. Skype Operation Overview

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. 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. 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. 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. 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. 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. 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. Skype Message Flow Analysis
 General Query / Response Patterns
Increment of 2 on every new request
First 2 bytes

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. 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. UDP Probe
Varies for v2.0
Same for both
versions

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Port 80 Operation

35. TCP Authentication
 After TCP Connection established to SN, the SC needs to authenticate itself
 2 login servers discovered by Baset are confirmed
 195.215.8.141
 212.72.49.141
 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. 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. TCP Authentication
 Same pattern observed when connecting to another group of LS
 195.215.8.140
 212.72.49.155
 These are only connected when user calls using PSTN
 We assume them to be Skype-to-PSTN gateways (SkypeOut)
 Another LS group
 195.215.8.142
 212.72.49.142
 These are connected whenever a user adds, blocks or deletes an address on his
contact list

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. THANK YOU!