Monthly Archives: April 2008

iSkoot disclosure of Skype credentials resolved – new version by Wednesday

If you have been following this weekend’s discovery by Dameon Welch-Abernathy, a.k.a. PhoneBoy, of the iSkoot program disclosing Skype usernames and passwords (see also the chronology), you will know that the problem has been fixed and a formal statement from iSkoot would be forthcoming. That statement from iSkoot CEO Mark Jacobstein has now been issued on their blog. The key part related to the vulnerability is this:

A recent build allowed a development/pre-production version of the Symbian client to be downloaded in place of our production version, which did indeed produce the issue Phoneboy reported. We have checked our other platforms (Blackberry, J2ME, Windows Mobile, etc.) and fortunately this issue impacted only Symbian devices. We’ve pulled the development/pre-production build and fixed the bug and will be doing a forced upgrade to every Symbian user no later than Wednesday (4/30).

The folks at iSkoot are definitely to be applauded for their quick response. The incorrect build has been pulled from their site and, as stated, they intend to have a new version out no later than Wednesday. In the meantime, I would personally suggest that iSkoot users on Symbian devices simply stop running the application until the new build has been downloaded.

Good outcome, all in all.

Technorati Tags:
, , , , , ,

Chronology of the blogosphere and iSkoot weekend response to the iSkoot security issue

Given commentary now appearing in the blogosphere around the speed of the response this weekend by both various blogs and also the folks at iSkoot responding to the security issue tracked on this blog, I thought I would take a moment and just capture the chronology of what did occur. (Partly to emphasize what Andy points out in his post today – that the blogosphere can help companies that join in the conversation.) Here’s what I saw – all times converted to Eastern US:

  • Saturday, April 26, 2008 – 4:22am (1:22 Pacific) – PhoneBoy (Dameon Welch-Abernathy) posts his initial report of the problem.
  • 4:35am – Dameon emails a group of us who write about VoIP with the URL to his story.
  • 4:45am – Dameon emails the group again noting that the problem is actually worse than he originally reported because Skype credentials are exposed in the clear.
  • 5:41amI post my piece here on the VOIPSA weblog just emphasizing that we need to be cautious and confirm the issue since all of iSkoot’s material clearly states it uses SSL to prevent exactly this type of exposure. Shortly after posting, I email a reply back to the group with the URL to my piece.
  • Somewhere in there Andy Abramson puts up a VoIP Watch post indicating there is an issue. (His blog, like ours here at VOIPSA, doesn’t put public timestamps on blog posts.)
  • 6:51am – I send a message to “” (listed on their website), “”, and the email address of a PR contact found in their news releases pointing to all three posts (Dameon’s, Andy’s and mine). “” bounces.
  • 7:10amJim Courtney sends an email to the group saying he will get the information to the right people at iSkoot and get a response. Andy responds indicating he’s already been in touch with someone he knows there as well.
  • Jim and Andy (and perhaps others) work their connections to get information to people. Several of us are communicating with each other via Skype chat.
  • 1:39pm – Dameon posts a tcpdump packet capture clearly showing a Skype username (“insecure-user”) and password (“insecure-password”) in the clear.
  • 4:34pm – iSkoot CEO Mark Jacobstein leaves a comment to the post here stating unequivocally that they always use SSL. Because we moderate comments and I was traveling all day, it is not actually published to the site until around 7:50pm. (The time shown on the comment is actually GMT/UTC, which we apparently have this blog set to use – and which we’ll be fixing in the future.)
  • Evening – Various conversations continue via email and Skype chat. I now started communicating directly with Mark as well saying this didn’t make sense. At 9:36 pm, Mark replies to an email of mine saying he was having his CTO look into it because something was definitely not right.
  • Sunday, April 27, 2008, 10:46 am – Alec Saunders publishes a post on his blog noting the issue, the mitigating circumstances and the larger issue that people use the same password on too many sites and that a crack of your Skype password could lead to exploitation on other sites.
  • Around 4:00 pm – Mark Jacobstein sends email messages to several of us stating that there is a problem with the Symbian version (but not the others), that they’ve pulled it down and will be pushing out a fix soon.
  • 4:20 pm – Jim Courtney posts to Skype Journal that the issue has been resolved and a fix is on its way.
  • 5:19 pm – Jim posts a reply to the post here relaying Mark’s statement.
  • 6:03 pm – Dameon publishes a post stating that issue will be fixed.
  • Monday, April 28, early morning – Andy posts on VoIP Watch about the resolution as I do on Disruptive Telephony. Other blog posts start to appear pointing to the issue and resolution.

iSkoot CEO Mark Jacobstein also indicated that a public statement will come from them at some point as well (but is not yet visible on their site or blog). If there were other posts during this timeframe from other bloggers that I missed in there, my apologies… I’m just reporting what I personally saw. (And feel free to send me a link to add.)

What’s interesting to note from this timeline is that it was about 36 hours – on a weekend – from the time of the initial published report by Dameon to the first published report by Jim that the issue had been resolved.

Mark Jacobstein and his team at iSkoot certainly deserve kudos for the speed of their response but its also important to note that part of this came about because iSkoot had previously engaged with the blogosphere. They had worked with Jim Courtney at Skype Journal as well as Andy Abramson at VoIP Watch. Because of those relationships – as well as the communication within the circle of us who write about VoIP online – iSkoot was able to quickly be brought into the issue and get engaged with confirming the problem and working on a resolution. Note, too, that this previous engagement obviously left a positive view because the focus was on trying to confirm the issue and resolve it. There was no animosity or malicious publication, i.e. you could see with a company that people hate where someone could really spin this negatively.

There are some other lessons out of all of this, some related to this blog, that I will write about separately. Meanwhile, I just thought capturing this would provide a view into how the blogosphere can respond to an issue in a way that helps a company.

I’m just glad to know that the issue was not across all their products and is on the way to being fixed.

Technorati Tags:
, , , , , ,

Are your Skype username and password completely exposed if you use iSkoot?

UPDATE #1: Ironically, email to “” bounced. I did send it to several other addresses, though.

UPDATE #2: The iSkoot FAQ indicates that passwords are encrypted using SSL. So either the FAQ is now wrong or Dameon’s capture is wrong.

UPDATE #3: Dameon has now posted a packet trace clearly showing a Skype user name (“insecure-user”) and a password (“insecure-password”).

UPDATE #4: iSkoot CEO Mark Jacobstein has commented on this post stating unequivocally that they always encrypt with SSL.

UPDATE #5, April 27, 2008: As Jim Courtney notes in a comment to this post, iSkoot CEO Mark Jacobstein sent messages to several of us indicating that after further research on their end, there IS an issue with the Symbian version of the iSkoot software and that will be addressed quickly.

UPDATE #6, April 28, 2008: For those interested, I’ve published a chronology of the communication that occurred around this issue.

UPDATE #7, April 28, 2008: As noted here, iSkoot now has issued a formal statement and plan for a fix.


iskootlogo.jpgIf you use iSkoot to put Skype on your mobile phone, could it be that your Skype credentials (username, password) are transmitted in the clear? Based on some disturbing news from Dameon Welch-Abernathy, a.k.a. “PhoneBoy”, it certainly looks that way. In his post late last night, “iSkoot Transmits Your Data In The Clear“, he discusses his tests of capturing network traffic from both the new Skype for Mobile client and also from iSkoot. The difference is disturbing:

First of all, Skype appeared to use a TCP connection on a non-standard port. Fine with me. I looked at the raw packets generated by Skype Mobile and saw an opaque blob–exactly what I expected to see.

iSkoot uses TCP port 80–the same port used by HTTP, the lingua franca of downloading web pages. It sends various things as a series of HTTP GET calls. The scary part of this that your text chat messages–and lots of other interesting information, including your Skype credentials–is being transmitted in the clear. That’s right, iSkoot takes all that perfectly good encryption that Skype employs and throws it out the window. For no good reason.

If true (and I have no reason to doubt Dameon), this is obviously of great concern. Someone using iSkoot from their mobile over WiFi is effectively allowing their Skype credentials to be seen by anyone who can intercept their traffic (i.e. is either on the local WiFi network or is between them and iSkoot’s servers). Yes, Skype chats can also be intercepted (but that’s been a known issue with iSkoot) and while that is of concern, especially because users may assume the chats are encrypted as they are with Skype, the larger concern is interception of credentials… if someone gets your Skype username and password they can obviously login to Skype.

I am a bit surprised by the exposure of credentials (and did email Dameon back to confirm he could definitely see them) because when I raised my concerns about iSkoot last July, Jacqueline Van Meter from iSkoot Product Management responded to my concerns in a comment (left, actually, to a subsequent post I made about iSkoot) and stated this:

Of course, we take the issue of password security very seriously. Login and password information are always encrypted. The information is stored on the handset only—never the server—and only in cases where the user selects the auto sign-in option. The communication from the client to our server is also encrypted and secured, using https.

Jim CourtneyPhil Wolff, in his excellent review of iSkoot last October when it was announced that it would be used in the 3 Skypephone also says this about Skype chats over iSkoot:

Downside 5: Because Skype hasn’t shared their encryption algorithms with iSkoot, your Skype chats aren’t encrypted, although your login is.

If Skype credentials are now exposed, this is indeed a serious matter that iSkoot needs to address, especially given the millions of users of the 3 Skypephone which uses the iSkoot client. Did something change during one of the releases and the protection referenced above was inadvertantly removed? If HTTPS was used for encryption why didn’t Dameon see that? (Or did Dameon see the unencrypted chats but miss that the login was encrypted?)

Before we jump to conclusions, though, it strikes me that we need to do a couple of things:

  1. Verify again with a packet trace that the Skype username and password are visible during the iSkoot login (or subsequent message exchange). This is what I’ve asked of Dameon but with time differences, he is asleep right now. If anyone else has the capacity to test this, it would be good to have that confirmation. Unfortunately, I can’t personally as I don’t have any WiFi devices on which to run iSkoot.
  2. Understand how often the Skype credentials are sent by the iSkoot client. Is it only at the very first login? Or are they sent with every transaction?
  3. Contact iSkoot to see what they say. (I’ve just sent an email.)

After all of that, we can understand what risk is here right now.

Regardless of the outcome (and I hope that the credentials are not in the clear), this whole experience does show a stark difference between Skype’s new Mobile version and the iSkoot client. Skype, obviously, can secure all of the chats and communication in general. iSkoot, being a third-party app, can’t. Will that matter in the market place? Or does iSkoot have a friendlier model for carriers?

Meanwhile, let’s do some testing… I’ll update this post with more info as we can get it.

Technorati Tags:
, , , , ,

Information Week interviews SecureLogix about VoIP security

While I was sick at VoiceCon and didn’t record any of the videos I was planning to do, it’s great to see that Fritz Nelson over at Information Week did capture this video of Mark Collier of SecureLogix:

The TechWeb folks did a nice job on the video, particularly in cutting in to some of the slides explaining what Mark was talking about. Fritz has an article accompanying the video as well.

Oh, yeah, Mark was great, too! 🙂

P.S. For those who don’t know, Mark has been involved with VOIPSA and in fact was on a panel I moderated on VoIP security there at VoiceCon.

Technorati Tags:
, , , ,

Australian government outlines plans to regulate VoIP

voipnewsau.jpgFrom the land Down Under comes this interesting piece, “How ACMA Plans to Regulate VoIP” (ACMA= “Australian Communications and Media Authority”):

Speaking at the CommsDay Summit 2008 in Sydney, Chris Cheah, Acting ACMA Chairman explained how the organisation was adopting a three-strand approach to VoIP which included a review of existing regulation and a new “VoIP engagement strategy” to better understand the regulatory framework and ACMA’s approach.

ACMA wants to understand how existing regulation applies to the kinds of services that are now available, engage with the industry and consumers and finally put in place a specific compliance program. As part of the strategy ACMA will advise VoIP providers how the regulations apply to them and outline the types of services subject to regulation.

The article goes on to list out in some detail the different “compliance areas” the ACMA wants to focus on. For those concerned about government legislation and how it may impact VoIP, the piece should make for interesting reading. The article also notes that ACMA has a web site focused on VoIP regulation.

Technorati Tags:
, , , , , , ,

GNUcitizen research discovery: Default key algorithm in Thomson and BT Home Hub routers

Well, the GNUcitizen folks are at it again, and have discovered the default WEP keys shipped with Thomson and BT Home routers.  ZDnet and a few other news outlets have picked up the story, but IMHO your best bet it to read the details from the source. You can see BT’s security response here.

Australians falling victim to foreign phone hackers

Foreign-based criminals are reportedly ripping off Australian companies by hacking into their telephone systems and racking up massive bills.  Last week a Melbourne retailer and university were hit with collective phone bills for more than 100-thousand dollars of overseas calls.  And both parties are angry with Telstra which they say is insisting they pay the bills.  The Camberwell Electrics Superstore says it was contacted by Telstra to ask why it had made 20 thousand dollars worth of overseas calls in less than two weeks.  And Swinburne University says it knew nothing about the scam until it was hit with an 80-thousand dollar bill.

Xplico Network Forensic Analysis Tool

The goal of Xplico is extract from an internet traffic capture the applications data contained.  For example, from a pcap file Xplico extracts each email (POP, IMAP, and SMTP protocols), all HTTP contents, each VoIP call (SIP), and so on. Xplico isn’t a network protocol analyzer. Xplico is an open source Network Forensic Analysis Tool (NFAT).  Xplico is released under the GNU General Public License.

Quarterly VoIP Vulnerabilities Summary

While most VoIP-related vulnerabilities are posted to the VOIPSA mailing list or blog, I thought it might be useful to have a informal quarterly summary of sorts among VoIP devices per searches from NIST.  I hope folks find it helpful, and of course post comments if I’ve overlooked anything from 1 January 2008 through 31 March 2008.

VoIP Firewalls

Cisco Phones

  • CVE-2008-0531 Cisco Unified IP Phone 7940, 7940G, 7960, and 7960G 2/14/2008
  • CVE-2008-0530 Cisco Unified IP Phone 7940, 7940G, 7960, and 7960G 2/14/2008
  • CVE-2008-0529 Cisco Unified IP Phone 7940, 7940G, 7960, and 7960G 2/14/2008
  • CVE-2008-0528 Cisco Unified IP Phone 7940, 7940G, 7960, and 7960G 2/14/2008
  • CVE-2008-0527 Cisco Unified IP Phone 7935 and 7936 2/14/2008
  • CVE-2008-0526 Cisco Unified IP Phone 7940, 7940G, 7960, and 7960G 2/14/2008
  • CVE-2008-1113 Cisco Unified Wireless IP Phone 7921 3/3/2008

Snom Phones

Vocera Phones

Routers & Gateways

Asterisk PBX

Cisco Call Manager

  • CVE-2008-0026 Cisco Unified CallManager/Communications Manager 2/14/2008
  • CVE-2008-0027 Cisco Unified Communications Manager 1/16/2008

UPDATE 4/15/08

  • Milw0rm 5113 Philips VOIP841 PC-Free DECT 6.0 Wireless IP Phone 2-14-2008
  • Voice Biometrics conference May 14-15, 2008

    VoiceBiometrics.jpgWant to learn about voice biometrics? I recently learned of the “VoiceBiometrics” conference happening May 14-15, 2008, in New York City. While the agenda does not seem to have anything about VoIP, per se, it’s obviously all about voice and looks quite interesting.

    I won’t be there, but if anyone does go and wants to write up some information for this blog (or record information for the Blue Box podcast) we’d be glad to post that info.

    [P.S. In full disclosure, one of the event sponsors, VoiceVerified, is a customer of my employer, Voxeo.]

    Technorati Tags:
    , , ,