{"id":952,"date":"2009-12-01T21:38:55","date_gmt":"2009-12-02T02:38:55","guid":{"rendered":"http:\/\/mikeconley.ca\/blog\/?p=952"},"modified":"2023-12-20T16:25:18","modified_gmt":"2023-12-20T21:25:18","slug":"fiddling-around-with-skyp","status":"publish","type":"post","link":"https:\/\/mikeconley.ca\/blog\/2009\/12\/01\/fiddling-around-with-skyp\/","title":{"rendered":"Fiddling Around with Skype"},"content":{"rendered":"

As I said last week<\/a>, I’ve been working with a partner (Mohammad Jalali<\/a>) on a project for our networks course.<\/p>\n

The idea:\u00a0 given an arbitrary IP and port number, we want to find a way of determining whether or not there is an FTP server, an HTTP server, or a Skype node on the other side.\u00a0 FTP<\/a> and HTTP are trivial – those protocols essentially announce themselves to the world.<\/p>\n

Skype<\/a> clients, on the other hand, act a little more strangely.\u00a0 Skype goes out of its way to hide its traffic – from straight-up encryption, down to making their client executable really hard to reverse engineer.\u00a0 Because of this, Skype has been an interesting challenge to the hacker community.<\/a><\/p>\n

Anyhow, my partner and I have learned a few interesting things about Skype – and in particular, we’ve found a reliable way to determine whether or not Skype is running behind an arbitrary IP and port.\u00a0 Cool.<\/p>\n

Fact 1:\u00a0 Skype pretends to be an HTTP server<\/h3>\n

I’m serious, it does.\u00a0 Using Wireshark<\/a>, we noticed that both UDP and<\/em> TCP packets were being sent to one particular port.\u00a0 Pretty funny behavior…so, we took a closer look.\u00a0 And this is what we found.\u00a0 Pop open your Skype client, connect to the network, then use nmap to find the ports that Skype is using:<\/p>\n


\n$>nmap localhost -p10000-50000<\/code><\/p>\n

Starting Nmap 5.00 ( http:\/\/nmap.org ) at 2009-12-01 20:33 EST
\nInteresting ports on localhost (127.0.0.1):
\nNot shown: 39999 closed ports
\nPORT\u00a0\u00a0\u00a0\u00a0\u00a0 STATE SERVICE
\n48915\/tcp open\u00a0 unknown<\/p>\n

Ok, cool – there’s something at 48915, and it looks like it accepts TCP connections.\u00a0 Pop open Telnet, connect to it, and feed it an HTTP request:<\/p>\n


\n$>telnet localhost 48915
\nTrying 127.0.0.1...
\nConnected to localhost.
\nEscape character is '^]'.
\nGET \/ HTTP\/1.1
\nHTTP\/1.0 404 Not Found
\nConnection closed by foreign host.
\n<\/code>
\nOk, we got an HTTP response – looks like there’s an HTTP server back there, right?<\/p>\n

Wrong.\u00a0 Reconnect, and send it some garbage:<\/p>\n


\n$>telnet localhost 48915
\nTrying 127.0.0.1...
\nConnected to localhost.
\nEscape character is '^]'.
\nthisissomegarbagetextthatisnotanHTTPrequest
\n\ufffd\ufffdNun\u0006\ufffd\ufffd2\ufffd=\ufffd\ufffd\ufffd1\ufffd\ufffdN$O\/(\ufffd\ufffd\ufffd\ufffd
\n\ufffd\ufffd\ufffdu.)(\u0006yy\ufffd\u001bg\ufffd\ufffd$
\n\u0219\ufffdoT\ufffdb\ub811\ufffd-z#x\ufffd&\ufffd\u0004\ufffd\ufffd[P\ufffd\ufffd\ufffd\\\u001d\ufffd\ufffd(yVO\ufffd\ufffd\ufffd
\n<\/code><\/p>\n

See all of those funny characters down at the bottom?\u00a0 That’s what I got back.\u00a0 In the words of Obi-Wan Kenobi…that’s no HTTP server…it’s a space station (Skype node).<\/p>\n

So we’ve learned something here – Skype opens a port, and “spoofs” an HTTP server.\u00a0 We can easily check for this – just write a script that connects to a port, spews some garbage, and check to see if we got binary garbage back.<\/p>\n

It’s so easy, that someone else has already done it<\/em>.\u00a0 Remember that nmap tool we used earlier?\u00a0 Somebody over in that camp wrote a script for the Nmap Scripting Engine<\/a> that runs this exact analysis on some ip\/port.\u00a0 Don’t believe me?\u00a0 Read the script yourself!<\/a> We stumbled upon that script while trying to figure out what Skype was doing with the spoofed HTTP server.
\nAnd sure enough:
\n
\n$>nmap localhost -p48915 --script skype.nse
\nStarting Nmap 5.00 ( http:\/\/nmap.org ) at 2009-12-01 20:45 EST
\nInteresting ports on localhost (127.0.0.1):
\nPORT\u00a0\u00a0\u00a0\u00a0\u00a0 STATE SERVICE
\n48915\/tcp open\u00a0 skype2<\/code><\/p>\n

Nmap done: 1 IP address (1 host up) scanned in 0.14 seconds<\/p>\n

Hmph.\u00a0 So much for cutting edge, never-been-done research.\u00a0 Go figure.<\/p>\n

Fact 2:\u00a0 Given some UDP packets, Skype echos back a predictable pattern<\/h3>\n

For this part, we’re pretty sure no one else has tried this.<\/p>\n

While connected to Skype, we recorded some packets with tcpdump.\u00a0 We wrote a script that loaded up those packets, and could “replay” the packet payloads to an arbitrary IP and port.<\/p>\n

So, we played some packets against an IP\/port with Skype behind it.\u00a0 Most of the time, we got TCP packets with RST flags (which is TCP’s way of telling us to “shut yer trap”).\u00a0 But wayyyy down in the middle, there was a section of UDP packets that actually got a response:<\/p>\n\n\n\n\n
\"\"<\/a><\/td>\n<\/tr>\n
From Misc Blog Images<\/a><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

192.168.0.19 was the computer we were playing the packets from, and 192.168.0.14 was the computer with Skype running on it. See those UDP packets that are getting echoed back?\u00a0 That’s the interesting part…instead of just shutting us down with RST’s, Skype appears to be saying something back.<\/p>\n

So, is there a pattern in all of this?\u00a0 Actually yes.\u00a0 We isolated 4 of those UDP packets, and repeatedly fired them at the same IP\/Port on the computer running Skype, and we found a pattern.<\/p>\n

The pattern:\u00a0 the first two bytes that are sent in our UDP packets are echo’d back to us in the first two bytes of the UDP packets that come back. <\/em><\/p>\n

So, for example,\u00a0 one UDP payload we sent looked like this:
\n
\n92 40 02 a1 66 65 ea 0d 8c 82 c3 0c 27 cd c5 e7
\n4e 78 fe a1 50 a6
\n<\/code>
\nAnd we got back:
\n
\n92 40 17 c0 a8 00 13 74 a0 41 f0
\n<\/code>
\nSee that common 92 40?\u00a0 Bingo.\u00a0 \ud83d\ude09<\/p>\n

And it’s pretty consistent<\/em> – if we repeat the same UDP packet, we get (almost) the same response.<\/p>\n


\n92 40<\/strong> 67 c0 a8<\/strong> 00<\/strong> 13<\/strong> 11 00 10 4f
\n<\/code><\/p>\n

And if we repeat again…<\/p>\n


\n92 40<\/strong> 37 c0 a8 00 13<\/strong> 68 08 43 3a
\n<\/code><\/p>\n

92, 40, and c0, a8, 00, 13. Nice!\u00a0 Looks like a fingerprint to me!<\/p>\n

Except…<\/h3>\n

Except, remember, we already found a way of determining whether or not Skype was running behind a given IP\/port.\u00a0 This last finding was just bonus.\u00a0 My partner and I aren’t sure if our instructor is going to let us stay with this topic, seeing as how it’s pretty much been solved by other people before.\u00a0 We’ve only got 2 weeks before this project is due, so…if we get another project, let’s hope it’s relatively simple.\u00a0 Push come to shove, we could always try to fingerprint a different protocol…maybe BitTorrent clients.<\/p>\n

Either way, working on this stuff has been pretty cool…and it let me try out some pretty neat tools that are usually reserved for the people with<\/a> coloured<\/a> hats<\/a> (and no, I didn’t mean Red Hat):<\/p>\n