[VOIPSEC] Soft Phone Vulnerabilities

Craig Southeren craigs at postincrement.com
Wed Jun 14 22:48:51 CDT 2006


On Wed, 14 Jun 2006 09:17:20 -0400
"Michael Slavitch" <slavitch at gmail.com> wrote:

> Hello;
> 
> This is my first post to this list, so I'll summarize my points quickly and
> look forward to having detailed discussions on my points later.
> 
> I led a session on Skype in the enterprise on Monday June 12 at the  eBay
> Devcon.
> 
> More details are here <http://www.well.com/%7Etheek/p2pe.html> (
> http://www.well.com/~theek/p2pe.html).
> 
> Point 1:  The security aspects of Skype.  I consider Skype security to be a
> solved problem, orders of magnitude better than what has been implemented by
> vendors using products based on ITU,  3G and the proposed IMS standards.
> Standards are useless unless implementations work correctly.  The security
> analysis done by *Dr. Thomas A.
> Berson*<http://www.anagram.com/berson/index.html>is valid and correct.

While Berson's paper appears to be an excellent review of one version of
the Skype code, I don't consider that one review constitutes a comprehensive
peer review of the entire network. See my previous email on this list on
this topic.

> The only implementations that approach or exceed
> Skype's level of security and trust are arguably the personal trust of PGP
> ZRTP, high-cost proprietary systems for commercial or military use, and the
> research coming from *Henning Schulzrinne<http://www.cs.columbia.edu/%7Ehgs/>
> * and  *Eunsoo Shim* <http://www.arkko.com/tools/stats/eunsooshim.html> that
> are being considered for use in a future P2PSIP standard.  

These assertions may or may not be true. Regardless, they only make
statements about Skype's security relative to other systems, and do not
say anything about Skype's security per se. 

> The assertions in
> my presentation could not have been made if Skype security was *an open
> issue. * 

There are several logical fallacies in this statement. I'll leave their
enumeration as exercise for the student :)

> As a comparison, millions of financial transactions use IIS/IE as
> the underlying platform.  Any public opinions on IIS/IE security are best
> left to the reader.

Not sure why a comparison to IIS/IE security is relevant here.

> Point 2:  The security aspects of Software vs Hardware. Many SIP phones have
> a default password that cannot be changed. One vendor in particular has one
> 3-digit numeric root password for all its phones that cannot be overridden.
> Many commodity phones have Linux firmware with open holes in telnet/ftp/tftp
> and onwards, the better ones have passwords that are difficult to crack.
> Almost all have a default root password that is stored in firmware and
> almost all do their provisioning over clear text http.  Given the choice
> between using one of these phones and Skype for a sensitive conversation
> outside a NAT I must choose Skype because it is more trustworthy.  Hardware
> is insecure because the underlying platform is almost certainly poorly
> implemented. It is closed hardware that cannot be trusted, not closed
> software.  

The issues you raise (open holes in telnet/ftp etc) are actually all
software issues, not hardware, so I can't really see the differentce
between security holes in embedded software and security holes in
software that runs on general purpose PCs.

> I won't get into the security aspects of POTS.  That would be
> silly.

Not so much silly as well known.

> Point 3:  Unknown relays in Skype.  Jon Callas rightly points out that
> unknown relays in Skype cause a concern regarding sensitive communications,
> and I agree with him. My proposal for Skype Enterprise Peers calls for the
> creation of preferred relays.  Enterprises could put a multi-session
> enterprise peer outside the NAT for all its incoming and outgoing session.
> The same peer could of course be used by individuals if it was available to
> them.  This places control over ingress and egress as it concerns them in
> the hands of the end user without need for any core infrastructure or core
> provisioning.  There are implications downstream of this: replacement of
> involuntary relays with voluntary relays creates the potential for a social
> network that could recover its costs through advertising ("this Skype call
> brought to you by Bob's Pizza") that in turn also creates a network based on
> trust and transparency. To test this I created a brute-force voluntary peer
> in Skype by using hard firewall rules on a NAT gateway, which forced all
> Skype peers that were behind it to use the only Skype node they could reach,
> which was another Skype node under my control on the public Internet.

As long as the relay (voluntary or not) is a closed system the privacy
problems still remain
 
> Point 4:  Skype Reliability.  A side-effect of my DMZ test  was increased
> reliability and sound quality for nodes behind a NAT, mostly because the
> relay node on the public side was on an otherwise idle machine which did
> nothing but Skype.  Skype (and all P2P based systems) can be made better
> than 5-nines reliable by throwing commodity hardware at the problem and let
> it scale up. By definition server clusters running preferred relays and
> super nodes would be far more reliable than the PSTN, the advantage is that
> these supernodes would be self-organization and wouldn't need provisioning.
> You could replace the PSTN with a high-limit credit card and an order from
> Dell.

I know from personal experience that Skype is far from being as reliable
as the PSTN, and it's got nothing to do with the reliability of the
boxes that Skype is running on.

I expect users within the continental US don't see the problems that we
get here out here in the back-blocks, but try calling between (say)
Australia and Turkey via Skype. You can do it anyway you like - Skype to
Skype-Out, Skype to Skype, and in either direction. You'll get a
connection no more often than one in two call attempts, and when you do
get a connection, the latency will be about 3-4 seconds. And that's with
an ADSL broadband connection at both ends. Of course, calling to and
from the US works just fine on both those endpoints.

But PSTN, or even cellphone, will get a connection over the same route
nearly every time.

All of this not withstanding, the fact still remains that Skype is a
highly useful service, and has managed to acheive many objectives that
previous attempts to monetise the VoIP space have failed to do. And I
have no doubt that the people behind Skype are nice and enthusiastic
people with all of the best intentions and motives.

But none of these are reason to gloss over the hard technical facts that
it is still a closed system, and as such, cannot be assumed to be any
more secure than any other closed system. No amount of straw-man
comparisons with other failed closed source and open source systems will
change that fact. 

Experience shows that security comes from interoperabilty with devices
written by third parties to a documented standard, and from the ability
to withstand attacks (either on paper or in real-life) by parties that
are knowledgable about the internal design of the system. This applies
to both the design and the implementation of the components.

Neither of these conditions apply (yet) to Skype.

   Craig

-----------------------------------------------------------------------
 Craig Southeren          Post Increment – VoIP Consulting and Software
 craigs at postincrement.com.au                   www.postincrement.com.au

 Phone:  +61 243654666      ICQ: #86852844
 Fax:    +61 243656905      MSN: craig_southeren at hotmail.com
 Mobile: +61 417231046      

 "It takes a man to suffer ignorance and smile.
  Be yourself, no matter what they say."   Sting





More information about the Voipsec mailing list