A lot of people contacted me about my post on FD. No, I have no clue of what's really going and I can happily live believing the official reports (http://heartbeat.skype.com/) on the issue. This is the complete message I posted to FD in reply to Valery Marchuk (http://lists.grok.org.uk/pipermail/full-disclosure/2007-August/065343.html):
Valery Marchuk wrote:
> > Hi all!
> > On SecurityLab.ru forum an exploit code was published by an anonymous
> > user. Reportedly it must have caused Skype massive disconnections
> > today. The PoC uses standard Skype client to call to a specific
> > number. This call causes denial of service of current Skype server and
> > forces Skype to reconnect to another server. The new server also
> > "freezes" and so on ... the entire network.
> > Liks: http://www.securitylab.ru/news/301422.php
> > PoC: http://en.securitylab.ru/poc/301420.php
imho fake (the poc does nothing except looping forever, missing
execve(), exec() in place of system(), etc)
should be something like
#!/usr/bin/perl
for ($i=0;$i<(256*256);$i=$i+256) {
# ctrl + q for fast quit from skype
print "Try with $i\n";
$eot='AAAA' x $i;
$str="\"/home/p/bin/skype_static-1.4.0.74/skype\" \"/uri:$eot\"";
#$str="\"/home/p/bin/skype_static-1.4.0.74/skype\" \"/file:$eot\"";
#$str="\"/home/p/bin/skype_static-1.4.0.74/skype\" \"/callto:$eot\"";
#$str="\"/home/l/bin/skype_static-latest/skype\" \"/uri:$eot\"";
#$str="\"/usr/bin/skype\" \"/uri:$eot\"";
#$str="\"C:\\Program Files\\Skype\\Phone\\Skype.exe\" \"/uri:$eot\"";
#print($str);
system($str);
}
uri is a legit skype protocol handler
0x2,"Classes\skype\shell\open\command", "", "%SystemDrive%\Program
Files\Skype\Phone\Skype.exe" "/uri:%1"
0x1,"Classes\Skype.Content\Shell\Open\Command", "",
"%SystemDrive%\Programs\Skype\Phone\Skype.exe" "/file:%1"
0x2,"Classes\callto\shell\open\command", "",
"%SystemDrive%\Programs\Skype\Phone\Skype.exe" "/callto:%1"
but still doesn't work
Regards,
Francesco `ascii` Ongaro
http://www_ush_it/
_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Naturally we are (in a relaxed fashion) discussing this issue on our internal mailing list so I just translated to English my feelings on the issue. The message is dated 17 August 2007.
Jimmy Jimmy wrote:
> Surely a DOS has occurred. Yesterday I was disconnected from the [Skype] network every five minutes.
Yes, also on my side, and today it was not better (P2P errors, no contacts, etc). Only tonight everything seems back to work and there are ~4 million users online.
On what has caused the DOS I don't have any sure information (Microsoft (TM) Update? Ubuntu-like attack (60% hacked servers)? DOS on core servers? DOS on servers troughs clients? Protocol bug?)
For what concerns the exploit code the following are my thought:
http://en.securitylab.ru/poc/extra/301419.php <-- This was the first to be published on FD and the one I replied to.
#!/usr/bin/perl
# Simle Code by Maranax Porex ;D
# Ya Skaypeg!!
for ($i=256; $i>xCCCCC; $i=$i+256){
$eot='AAAA' x $i;
call_sp();
}
exit;
sub call_sp(){
$str="\"C:\\Program Files\\Skype\\Phone\\Skype.exe\" \"/uri:$eot\"";
}
1) Why "for ($i=256; $i>xCCCCC; $i=$i+256){" doesn't work as expected:
1a) xCCCCC problems
k@d ~ $ perl -e 'print xCCCCC'; k@d ~ $
k@d ~ $ perl -e 'print \\xCCCCC'; SCALAR(0x814d70c) k@d ~ $
xCCCCC is NULL/0 because it's undefined, Perl makes no complaint.
k@d ~ $ perl -e 'print AAAA'; k@d ~ $
Overwise a condition of the type "small number > big number" would immediately exit.
1b) The condition should be "< big number" and not "> big number".
If this was the real intention a while 1/TRUE would be much cleaner than for ($i=256; $i>xCCCCC; $i=$i+256){.
1c) A consideration that isn't strictly correlated to this code: if you found a BOF at X bytes why start from 256*4 (1024) that hardly causes a BOF on a protocol handler (witch task is to carry data)?
1e) If you know that the BOF is at X bytes that put a fixed multiplier and the cycle (for or while that is) will represent the Skype server that you want to crash and not the multiplier.
1f) The missing system(). Could be a kiddie protection anyway.
2) On the "$str="\"C:\\Program Files\\Skype\\Phone\\Skype.exe\" \"/uri:$eot\"";" line
2a) Why this (in the provided descriptions) would crash the server and not the client? This would means that the client supports arbitrary length inputs (malloc to the end of free memory) but the server not (hard to believe since Skype developers are smart from what it can be deduced by the anti-reversing techniques they put in place both on the client binary and the protocol).
2b) (pro) Skype has a closed protocol and this makes the development of a magic packet (or a series of magic packers, perhaps after authentication and all the crypto/compression/obfuscation stuff) extremely hard to develop. It's much more easy to use the client to delivery the attack since it knowns the protocol.
2c) (pro) "/uri:" is effectively a registered Skype protocol
0x2,"Classes\skype\shell\open\command", "", "%SystemDrive%\ProgramFiles\Skype\Phone\Skype.exe" "/uri:%1" 0x1,"Classes\Skype.Content\Shell\Open\Command", "", "%SystemDrive%\Programs\Skype\Phone\Skype.exe" "/file:%1" 0x2,"Classes\callto\shell\open\command", "", "%SystemDrive%\Programs\Skype\Phone\Skype.exe" "/callto:%1"
2d) (pro) In the past expoits for the Skype protocol handler occurred, but:
- They were against the client
- They were format strings and command injection (but also BOF)
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-2312
http://secunia.com/advisories/17305/
http://news.zdnet.com/2100-1009-5453313.html
http://news.zdnet.com/2100-1009_22-5913631.html
http://www.blackhat.com/presentations/bh-europe-06/bh-eu-06-biondi/bh-eu-06-biondi-up.pdf
http://www.frsirt.com/english/advisories/2005/2197
2e) The exploit code published on FD miss the execution part (http://en.securitylab.ru/poc/extra/301419.php) but in an other Russian site there's a system() (http://www.xakep.ru/post/39746/default.asp that can be translated with http://translate.google.com/translate).
Practically there is no more code to analyze so move on to the general and non-code considerations:
3a) The POC code is pretty bad and isn't that convincing.
3b) The description isn't that convincing.
3c) Some native speaking Russian should analyze the comments in securitylab.ru since if they were who started the hoax (to make visits or for fame) they could be unmask themselves in the comments (from a comment: "With humor work =)" referred to "# Skaypeg Ya!!", http://www.habrahabr.ru/blog/skype/23351.html)
3d) Explanations of these 10 lines of Perl are various (http://blogs.zdnet.com/Ou/?p=683 and http://www.securitylab.ru/news/301422.php):
The PoC uses standard Skype client to call to a specific number. This call causes denial of service of current Skype server and forces Skype to reconnect to another server. The new server also “freezes” and so on … the entire network.
On http://www.xakep.ru/post/39746/default.asp we read:
During the search of local buffer overflow was discovered to send a long line of server and overtax his clipboard, which resulted in the fall. It took another server of P2P networks and as it is a mistake, and so forth. In a few hours the entire network Skype came to a denial of service and the team was forced to disable authentication.
On a third site of witch I cant' find the url, the DOS factor was the number of calls made from the client and not the lenght of the argument.
3e) "Simle Code by Maranax Porex ;D" I expected that the only (short) English sentence in the code didn't contains a typo ("Simle" -> "Simple").
3f) Perl and Windows? A bat script/c/vb script/when ether would be mostly a photocopy, all the code is 3 instructions.
So IMHO this is only somebody who has taken the occasion to publish a fake by using an outage. It could be working (it's hard to judge a DOS exploit if the server isn't working since it's the expected result and also because of the nature of the Skype network, closed source and hardly debuggable) but IMHO it has the same probability that "cat /dev/urandom | nc target 80" has to crash Apache.
Anyway who knows : ) There's a lot of hype on this lately and I see no reason for Skype to be invulnerable to security problems (and it's not because "They love costumers and others don't" as I read in a comment).
Now feel free to speculate more but only the system administrators who spent the last days fixing this problem knows the truth.
Bye, Francesco `ascii` Ongaro