UPDATE #1: Ironically, email to “firstname.lastname@example.org” 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:
- 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.
- 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?
- 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.
skype, skype security, iskoot, security, voip, voip security
I did not do extensive testing, but I saw it at least once per session. In my mind, once is enough to create an exposure risk.
Hi Dan –
I’d like to reassure you and our users that our clients absolutely utilize SSL encryption and that nothing with respect to our security measures–which iSkoot regards with utmost importance–has changed in our recent client releases. As indicated on our website, the user’s password is stored on the handset only, and any time this information is sent to the server it is 100% SSL encrypted. We never store passwords to the server.
Additionally, please note that iSkoot does not have a WiFi client available on the market. Our clients utilize the mobile voice and data channels only, and users cannot utilize iSkoot over WiFi. If users are running a mobile Skype client via WiFi, they are not using publicly available iSkoot product. I can also assure if we did release a WiFi client to market, our security measures would be no less stringent – we always employ SSL encryption.
Mark Jacobstein, CEO
Thank you for commenting here and providing a response from iSkoot. Your statement is consistent with what is on your website, what is in past interviews and, quite frankly, what I would expect for you to do.
However, Dameon has now posted a tcpdump packet capture showing a Skype username and password ( http://www.phoneboy.com/2244/proof-of-iskoot-passing-credentials-in-the-clear ). If it were SSL-encrypted there is no way he should be seeing this.
Something is not right here – and probably the best step for all involved would be for you and Dameon to be directly in contact and sort this out. I will send you contact information via email.
Thanks again for your comment,
P.S. Regarding the use of WiFi, as far as I understand Dameon is running your *regular* program on his dual-mode Nokia phone. Your program uses his phone’s *data connection*, which would normally be the carrier network unless he is in range of a WiFi hotspot in which case his phone flips to use WiFi for the data connection. This should be transparent to you and as far as I know an SSL connection would work identically across either data connection.
As a result of an email exchange I have had with Mark Jacobstein, he set his developers to work today (Sunday) and came back with the following statement:
“Unfortunately, it turns out that Dameon was right. We’re not sure how, but a non-production Symbian build ended up on the site, and it had this bug. We’re pulling the build and fixing the bug and will be doing a forced upgrade to every Symbian user as soon as possible. We also checked all the other builds, and they’re all fine (Windows Mobile, Blackberry, J2ME, etc.)”
Dameon’s and your diligence are appreciated by all; also kudos to iSkoot for addressing the issue so promptly such that we can all be assured of the security integrity of iSkoot going forward (even if one had to do handstands combined with backflips to find the security bug).
Pingback: Security flaw on iSkoot: discovered and solved over the weekend | LucaFiligheddu.com
Pingback: Voice of VOIPSA » Blog Archive » Chronology of the blogosphere and iSkoot weekend response to the iSkoot security issue
Pingback: Voice of VOIPSA » Blog Archive » iSkoot disclosure of Skype credentials resolved - new version by Wednesday
Pingback: iSkoot SSL Problem, Disclosure Of Skype User Names And Passwords, Has Been Fixed. | VoIP MoVoIP Blog
now think about the skype dual.triple login without notification….. very unsafe. all accounts that have been exposed to active exploit of this type of bug via iskoot. should be notified. what responsibility does skype and iskoot take for it’s usercloud. should the users involved not be notified, just like you notify your customers when the alarm system in a car has failed… are there not laws that force the voip providers to take action ? or will it just blow over…