Identifying Skype 2.0 with Version Detection

[doug () hcsw org]

Hello nmap-dev,

I'm working on integrating the latest batch of service submissions
into the nmap-service-probes file (by the by, thanks to everyone who
has submitted!). After tallying the stats, I was very suprised to see
the proprietary skype VoIP protocol was the 5th most submitted protocol
after some of the usual suspects: http, ftp, telnet, and smtp.

Some time ago, I added the following match line to the X11Probe:

# Skype - Protocol seems to spew out 14 random characters upon
# connection. Luckily, this shouldn't conflict any other X11 services.
match skype m|^.{14}$|s p/Skype VoIP data channel/

This simple match line seemed to work quite well for skype version 1
and, after it was added to the official Nmap distribution, stemmed
the tide of skype submissions.

I came up with this match line after examining dozens of user submissions
and testing against an installed client. I was happy to read the excellent
reverse engineering treatment of skype presented at blackhat europe by
Philippe Biondi and Fabrice Desclaux which confirms this probe's
effectiveness. See slide number 48 in their handout here:

http://www.secdev.org/conf/skype_BHEU06.handout.pdf

(I had the opportunity to meet Philippe at CanSecWest a few weeks
ago. Check out scapy - c'est tres cool. :) )

Problem solved, right? Well, unfortunatley, everyone's favourite
obfuscators have done it again with skype version 2 by breaking
Nmap's ability to identify this protocol (skype 2.0 beta was released
Dec 1st, 2005; the official release January 19th, 2006). The large number
of service submissions suggest that this is a very important service for
us to match but I don't have the resources to properly reverse engineer
this protocol - especially since the creators seem to have gone to some
effort to discourage exactly such activity (read the rest of Biondi and
Desclaux).

So, nmap-dev, I'm asking if anybody has any more information on this
protocol or is willing to help reverse engineer it enough so that
we can create an accurate match line. Here is what I know so far:


UDP: I've only seen 2 submissions and they were on high random ports.
It looks like some probes might elicit exactly 10 bytes of garbage data
but, of course, more data is needed.


TCP: It seems to listen on ports 80, 443, and a random high port.

To the GetRequest probe skype replies

"HTTP/1.0 404 Not Found\r\n\r\n"

To other probes, it replies with (ballpark) 50 to 70 garbage bytes.

We *could* match on the GetRequest probe but this is a very
generic response and I am hesitant to do so for accuracy reasons:
I've always thought it's better not to match a service than to
match an incorrect service.


So, we have 2 options:

1) Find a pattern in the bytes or lengths of responses from one
of the existing probes (looks somewhat unlikely).

2) Discover a sequence of bytes (a "probe") that we can send to
a listening port in order to verify a skype server.


I have a large number of skype submissions but I'm afraid I can't
send across any of them due to the confidentiality of service
submissions - especially since I don't know what information might
be embedded in the obfuscated connections! However, if any of
you are so inclined, you might be able to help by sending me
full (both directions) packet dumps of skype *version 2* connection
initiations. Even better, devise a probe or match line yourself!
Here's the definitive document for doing that:

http://www.insecure.org/nmap/vscan/

Sending the list any information on reverse engineering the
protocol would also be great. I'm sure other people would benefit
from this information as well. It goes without saying: be careful
of the legal issues and ensure anything you do is legal in your
locality.

Doug



_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev