The idea:  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.  FTP and HTTP are trivial – those protocols essentially announce themselves to the world.

Skype clients, on the other hand, act a little more strangely.  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.  Because of this, Skype has been an interesting challenge to the hacker community.

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.  Cool.

Fact 1:  Skype pretends to be an HTTP server

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


$>nmap localhost -p10000-50000

Starting Nmap 5.00 ( http://nmap.org ) at 2009-12-01 20:33 EST
Interesting ports on localhost (127.0.0.1):
Not shown: 39999 closed ports
PORT      STATE SERVICE
48915/tcp open  unknown

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


$>telnet localhost 48915
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET / HTTP/1.1
HTTP/1.0 404 Not Found
Connection closed by foreign host.

Ok, we got an HTTP response – looks like there’s an HTTP server back there, right?

Wrong.  Reconnect, and send it some garbage:


$>telnet localhost 48915
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
thisissomegarbagetextthatisnotanHTTPrequest
��Nun��2�=���1��N$O/(����
���u.)(yy�g��$
ș�oT�b렑�-z#x�&���[P���\��(yVO���


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

So we’ve learned something here – Skype opens a port, and “spoofs” an HTTP server.  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.

It’s so easy, that someone else has already done it.  Remember that nmap tool we used earlier?  Somebody over in that camp wrote a script for the Nmap Scripting Engine that runs this exact analysis on some ip/port.  Don’t believe me?  Read the script yourself! We stumbled upon that script while trying to figure out what Skype was doing with the spoofed HTTP server.
And sure enough:

$>nmap localhost -p48915 --script skype.nse
Starting Nmap 5.00 ( http://nmap.org ) at 2009-12-01 20:45 EST
Interesting ports on localhost (127.0.0.1):
PORT      STATE SERVICE
48915/tcp open  skype2

Nmap done: 1 IP address (1 host up) scanned in 0.14 seconds

Hmph.  So much for cutting edge, never-been-done research.  Go figure.

Fact 2:  Given some UDP packets, Skype echos back a predictable pattern

For this part, we’re pretty sure no one else has tried this.

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

So, we played some packets against an IP/port with Skype behind it.  Most of the time, we got TCP packets with RST flags (which is TCP’s way of telling us to “shut yer trap”).  But wayyyy down in the middle, there was a section of UDP packets that actually got a response:

From Misc Blog Images

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?  That’s the interesting part…instead of just shutting us down with RST’s, Skype appears to be saying something back.

So, is there a pattern in all of this?  Actually yes.  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.

The pattern:  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.

So, for example,  one UDP payload we sent looked like this:

92 40 02 a1 66 65 ea 0d 8c 82 c3 0c 27 cd c5 e7
4e 78 fe a1 50 a6

And we got back:

92 40 17 c0 a8 00 13 74 a0 41 f0

See that common 92 40?  Bingo. 

And it’s pretty consistent – if we repeat the same UDP packet, we get (almost) the same response.


92 40 67 c0 a8 00 13 11 00 10 4f


And if we repeat again…


92 40 37 c0 a8 00 13 68 08 43 3a


92, 40, and c0, a8, 00, 13. Nice!  Looks like a fingerprint to me!

Except…

Except, remember, we already found a way of determining whether or not Skype was running behind a given IP/port.  This last finding was just bonus.  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.  We’ve only got 2 weeks before this project is due, so…if we get another project, let’s hope it’s relatively simple.  Push come to shove, we could always try to fingerprint a different protocol…maybe BitTorrent clients.

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 coloured hats (and no, I didn’t mean Red Hat):

• nmap: port scanner that can also do service/os fingerprinting
• Scapy: sculpt, gut, spoof, manipulate, and send packets – the power of C, with the simplicity of Python!  We used Scapy as a library while writing our scripts.  Lots of potential with this tool.  Feel like poisoning an ARP cache?  Scapy is for you!
• Wireshark: a network student’s best friend.

Click here to check out Mohammad’s blog post about this project.