Voice of VOIPSA

Want a job in VoIP security? Jason Ostrom, who recently joined Sipera Systems as director of their VIPER Lab, passed along word to us that they are looking to hire two new positions related to VoIP security:

• VIPER Security Consultant

• VIPER Vulnerability Research Engineer

Job descriptions and information about applying can be found over on Sipera’s “Careers in VoIP Security” page. (i.e. please do not leave comments here about these jobs or contact us as we have nothing to do with the jobs).

Technorati Tags:
voip, voip security, security, sipera, sipera systems

News reports are coming out now (FierceVoIP, Network World and others) that in about 30 minutes or so, Avaya, Cisco, Nortel and VoIPShield Systems will be jointly announcing VoIP security vulnerabilities - and corresponding fixes.

We are delighted to see that in contrast to the previous announcement of vulnerabilities discovered by VoIPshield Systems, all three major vendors will be participating in today’s announcement.

Stay tuned… and if you are an Avaya, Cisco or Nortel user, you should probably be standing by to allocate some time to patching.

Technorati Tags:
avaya, cisco, nortel, voip, security, voip security, voipshield, voipshield systems

I recently learned that Nortel has launched their “Voice Security Technology Blog“. Their initial post outlines their goals for the blog. They only have two posts up so far but we’ll be interested to watch the blog and see what they do with it.

Technorati Tags:
voice, voip, nortel, security, voice security, voip security

Some researchers over at Johns Hopkins University have discovered that due to the way Variable Bitrate Compression does it’s thing, even if the audio stream is encrypted it is still possible to determine entire words and phrases based on the lengths of the packets with a high degree of accuracy.

According to the article referenced above it appears that the proof of concept tool is fairly limited, but given a little time and additional effort it’s capabilities could be greatly expanded, potentially to the point of transcribing entire conversations.

The researchers’ paper was presented at the 2008 IEEE Symposium on Security and Privacy a few weeks ago.

The German Asterisk Tag (Asterisk Day) takes place in Berlin 26-27th May, 2008. Some of the presentations will cover security issues as well as issues companies are facing when introducing VoIP. Among the speakers are Mark Spencer (Digium) and Phil Zimmermann, the latter one talking about Zfone.

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

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:
voip, voip security, securelogix, mark collier, security

From 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:
acma, australia, government, legislation, voip, regulation, voipsecurity, voip legislation