Voice of VOIPSA

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:
iskoot, skype, voip, voip security, security, skype security, phoneboy

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:41am - I 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 “info@iskoot.com” (listed on their website), “security@iskoot.com”, and the email address of a PR contact found in their news releases pointing to all three posts (Dameon’s, Andy’s and mine). “security@iskoot.com” bounces.
• 7:10am - Jim 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:
skype, iskoot, security, voip, voip security, phoneboy, skype security

UPDATE #1: Ironically, email to “security@iskoot.com” 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.

——–

If 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:
skype, skype security, iskoot, security, voip, voip security

Blue Box Podcast #76 is now available discussing Cisco, Skype and BT
vulnerabilities, when SIP looks like SPIT, VoIP security threat
predictions and the FBI forgets to pay their bills, plus listener
comments and more…

Jonathan and I recorded the show on January 22nd and I’m now *almost*
caught up with 1 main show still in the production queue (and about
10 special editions!)

Technorati Tags:
bluebox, blue box, voip, voip security, security

If you are using Skype on Windows, today would be a good day to upgrade! As noted in their release notice, this new version 3.6.0.248 includes a fix to the cross-site scripting vulnerability, along with a wide range of other fixes.

Technorati Tags:
skype, skype security, security

Skype today announced that there is a serious security vulnerability in Skype for Windows versions older than 3.6.x.216. As noted:

An exploitable memory corruption may occur during the parsing of URIs which can result in arbitrary code execution under the user rights of the current Windows account.

It turns out that this was fixed in the release back on November 15th, but Skype had an “unintentional communication oversight”:

At Skype, we strive to inform the public of vulnerabilities and malware that may affect Skype software. While this particular vulnerability was fixed, there was an unintentional communication oversight and we failed to bring the case to the public’s attention. All we can do now is to apologize.

Oops!

Thanks for the apology, Skype… and now would be a really good time for any Windows Skype users out there to look at upgrading!

P.S. Tip of the hat to Ryan Naraine’s Zero Day blog where we noticed the item this morning.

Technorati Tags:
skype, voip, voip security, security

Last week I meant to write about this, but Skype is advising people about some malware that is floating around that tries to entice Skype users to click a link that will then infect your computer. The rather despicable fashion the malware uses is to send a chat message that says “Please help me find this girl” referring to Madeleine McCann. Facetime Security Labs has a lengthy writeup that goes into all sorts of details about the particular worm variant. It propagates via IM, so it’s not anything particularly tied into VoIP, but obviously just something people should be concerned about.

Technorati Tags: skype

Skype is certainly taking some punishment recently. Today the news broke that someone has let loose a worm that uses the Skype API to send a chat message to your Skype contacts. The chat message includes a link which (if the user clicks on it) will download the w32/Ramex.A virus, which in turn infects their PC, and will visit their Skype friends. Obviously, this is a big concern for anyone with a user base as large as Skype’s, since even a small percentage of users that click on the link can cause wide distribution.

More: Skype Blog

Well, the official word is out from Skype and it can be summarized: the reboots from Microsoft patches triggered a previously-undetected condition and crashed out network. 

Skype PR staffer Villu Arak writes in “What happened on August 16“:

On Thursday, 16th August 2007, the Skype peer-to-peer network became unstable and suffered a critical disruption. The disruption was triggered by a massive restart of our users’ computers across the globe within a very short timeframe as they re-booted after receiving a routine set of patches through Windows Update.

The high number of restarts affected Skype’s network resources. This caused a flood of log-in requests, which, combined with the lack of peer-to-peer network resources, prompted a chain reaction that had a critical impact.

Okay… I can buy that this type of thing could trigger some kind of chain reaction, but I don’t understand why this month was different than any other month.  For.. what? two or three years now (more?) Microsoft patches have been coming out like clockwork on the second Tuesday of each month.  Each second Tuesday or Wednesday, the millions of computers set to auto-update do so.  All those zillions of computers restart automatically.  Each and every month.  What was so special about this August that was different from every other month?  Was the number or restarts in a short period of time really that much different from other months? Why? Is the issue that there are so many more Windows Skype users than in previous months and years? Was this just the so-called “tipping point” when there were enough Windows Skype users that the normal restarts triggered this chain reaction?

The issue has now been identified explicitly within Skype. We can confirm categorically that no malicious activities were attributed or that our users’ security was not, at any point, at risk.

In other words, it was not a DDoS by Russian hackers, as one rumor had it (which had actually already been dismissed by every security researcher who looked at the alleged exploit code).

This disruption was unprecedented in terms of its impact and scope. We would like to point out that very few technologies or communications networks today are guaranteed to operate without interruptions.

Fair enough statement - if you are looking at data or web technologies… but the PSTN, to which Skype would seem to like to be compared, is designed to operate without interruptions (or with as minimal as possible).  You know, there is this wee little market for “carrier-grade” equipment/software/etc. that is designed to be highly available without downtime.  If a carrier’s network were down for over 48 hours, there would be a zillion lawsuits, intense government inquiries and more.  The carriers that make up what we call the “PSTN” put an incredible effort into ensuring availability.  If Skype wants to play in that game, they have to be ready to play at the same level.

Skype has now identified and already introduced a number of improvements to its software to ensure that our users will not be similarly affected in the unlikely possibility of this combination of events recurring.

Good. We would expect that.

I appreciate that Skype has been as communicative as they have through their blog and heartbeat site.  Thank you, Skype, for communicating - and leaving the comments open.  However, to me the information provided today is still lacking one key piece:

Why were the mass restarts associated with the August 2007 Microsoft updates different from the mass restarts associated with any other month’s Microsoft updates

(Cross-posted from my Disruptive Telephony blog where I’ve been tracking the Skype outage.)

With the rise of new Skype clients for the Blackberry, such as iSkoot and IM+, one of the obvious questions raised by bloggers (including myself) was “what about the security?” Particularly since you have to give the Blackberry client your Skype username and password, essentially giving the client (and its developers) full access to your Skype account. Well, Jim Courtney over at Skype Journal also writes a good bit about Blackberries as well as Skype download, and posted his response to the issue on Friday: “Security, Skype and the Blackberry“.

I still suffer a lingering uncertainty, but I’ll admit that Jim’s digging does seem rather persuasive.

Technorati tags: skype, skype journal, jim courtney, blackberry, rim