Category Archives: Skype

Microsoft Researching Skype Password Reset Security Hole

This morning The Next Web reported on an exploit where Skype’s password reset web page could be used to hijack a user’s Skype account using only the password associated with the account. So… if you could guess someone’s email address (which can often be found through a Google search), you could effectively take over their Skype account.

Microsoft/Skype has DISABLED this feature while they investigate further so it appears that for the moment the security risk is limited.

However, it may be wise to watch closely the email account associated with your Skype ID for the next bit to see if any random password reset messages are sent to your account. Odds are that attackers will be sniffing around trying to see if there is any other way to exploit the apparent vulnerability.

The Next Web team reports that they were able to reproduce the attack on two Skype accounts of willing victims, confirming that the vulnerability was indeed real. They also reported the issue to Skype and worked with folks there.

The vulnerability is interesting in that it shows the complexity of modern communication applications. Skype is for the most part a desktop/mobile application, but yet it does rely on a centralized cloud-based service for authentication/passwords, etc. A vulnerability in the web interface for that central service then weakens the security of the overall system.

The “good” news for Microsoft/Skype is that because this appears to be a vulnerability in the web interface of the centralized system, this is probably something relatively easy for them to fix – and without requiring any client updates.

Kudos to Microsoft/Skype for reacting quickly to minimize the risk and we look forward to the issue being addressed.

UPDATE #1: Skype has issued a brief statement on their “heartbeat” web site with the same text that has been quoted in several articles.

UPDATE #2: The Verge has an article out now where many people in the comments are suggesting you change the email address associated with your Skype account to something less likely to be guessed. While Microsoft seems to have removed the immediate attack vector and this change is no longer critical to do, it may be something some of you may want to consider.

UPDATE #3: There’s a long Hacker News thread on this issue that also includes a link to an article walking through the exploit step-by-step as well as walking through links to protect your account. Note that because of the steps Microsoft has taken the exploit steps no longer work.

Skype for iOS/iPhone Vulnerable to Cross-Site-Scripting (XSS) Attack

News from the SUPEREVR security blog is that Skype for iOS is vulnerable to a cross-site scripting (XSS) attack that allows an attacker to send someone a message and, for instance, capture that user’s address book from their iPhone.

The author of the article posted a video that demonstrates the attack:

He further states in a tweet that he notified Skype of the vulnerability on August 24th:

In case anyone is wondering, I disclosed the vulnerability to Skype on 8/24. I was told an update would be released early this month.

Skype has issued a statement through their PR firm:

We are working hard to fix this reported issue in our next planned release which we hope to roll out imminently. In the meantime, we always recommend people exercise caution in only accepting friend requests from people they know and practice common sense Internet security as always.

Skype’s mitigation recommendation is a good one as the default privacy setting is typically that you can only receive chat messages from people on your Contact list. Therefore, the attacker would have to be someone who you have authorized and added to your contact list.

Meanwhile, hopefully Skype will be out with their update soon.

P.S. Hat tip to Tom Keating for writing about this exploit as that was where I first learned of it.

Skype encryption partially cracked?

skypelogo.jpgThe big news circulating through the Internet right now related to Skype is that someone may have reverse-engineered part of Skype’s encryption. Two posts of note:

The comments on the TechCrunch article are particularly worth reading as a number of security-related folks have jumped into the debate – and the author of the reverse-engineered code has jumped in as well (or someone claiming to be him, anyway).

People have been trying to reverse-engineer Skype’s proprietary encryption algorithm’s for years… and there have been various presentations at conferences and much data out there. In this case now, a developer named Sean O’Neil has made code available that apparently will decrypt one layer of Skype’s encryption.

Now, the code does NOT give you access to actual Skype messages. O’Neil writes in the TechCrunch comments:

Decryption of the RC4 layer gives nothing other than the ability to check CRC-32 of the packets, mere detection of random-looking encrypted packets as Skype. Maybe some firewalls will be able to block it at last.

I interpret that to mean that this code could help differentiate Skype traffic from other network traffic. The value there is really only, as the author says, that tools could be able to block Skype traffic because it could be more easily identified.

O’Neil goes on to say he has reverse-engineered more of Skype’s protocols and will be laying it all out at the Chaos Communication Conference in Berlin in December. We’ll have to see what gets said then…

Skype Trojan Records Your Calls

Apparently there’s a new piece of malware floating around that targets audio processors like Skype:

The Trojan has the ability to record audio from the computer — including any Skype calls in progress — and store the files locally in an encrypted MP3 file, where they can later be transmitted to the attacker.

The Trojan, which Symantec calls Trojan.Peskyspy, can be downloaded to a computer by tricking the user with an email scam or other social engineering tactic, Symantec says. Once a machine has been compromised, the threat can exploit an application that handles audio processing within a computer and save the call data as an MP3 file.

New Threats, Old Friends

On a lightning visit to the Infosec show in London, I chanced to meet with Ari Takanen of Codenomicon (fuzzing and quality assurance experts). Ari has a new book out: “Fuzzing for Software Security Testing and Quality Assurance”, from Artech House, available at Amazon.com and (as they say) all good bookstores. Of course, just because there’s a credit crunch doesn’t mean that security is any less of a problem, and it doesn’t mean that software defects are any the better. It sounds like Codenomicon have a pretty good market niche.

Enigma Machine

Facetime were talking about their new Unfied Security Gateway. This appliance goes beyond URL blocking and reporting, and implements reporting for VoIP and Skype, and the whole range of IM and P2P applications. In addition they have some pretty granular tools for finding out what the usage of social sites like Facebook (FB) and Myspace, and the resulting bandwidth usage might be. You can even drill down into the subsections being used (apps, music etc), which will be useful as increasingly FB is used for legitimate messaging and networking purposes in business. Facetime’s “special guest” on the stand was an original Engima encryption device, brought down from Bletchley Park (a.k.a “Station X”), the UK’s premier code-breaking museum. This is a refurbished and fully working Enigma, and on the Facetime stand they were even allowing us to have a go. I can report that it is satisfyingly mechanical to use.

AEP were also there showing some high-grade encryption equipment for enabling remote sites with access to secure systems. Law enforcement and government customers have a legal duty to protect the data that they handle, which and even remote users (or temporary sites) must protect data from snooping. Data at rest is a particular risk, and UK government agencies have embarrassingly lost large numbers of laptops and pen drives in recent years. It’s safer to leave the data in the secure site (rather than the USB stick) and access it over secure links when needed. The AEP solution fits into a laptop bag, and enables a team of people to share secure data and VoIP links to a central site, routed over any convenient satellite, 3G or WAN links.

The Infosec show is still on today and tomorrow at Earls Court exhibition centre in London.

Internet phone calls, terrorism and finding the balance for law enforcement

The Times of London is out today with a provocatively titled piece: “Internet phone calls are crippling fight against terrorism” and leads with this:

The huge growth in internet telephone traffic is jeopardising the capability of police to investigate almost every type of crime, senior sources have told The Times.

As more and more phone calls are routed over the web – using software such as Skype – police are losing the ability to track who has called whom, from where and for how long.

The key difficulty facing police is that, unlike mobile phone companies, which retain call data for billing purposes, internet call companies have no reason to keep the material.

And goes on to mention issues security officials have with the new world of online communication:

At present security and intelligence agencies can demand to see telephone and e-mail traffic from communication service providers, such as mobile telephone companies. But rapid expansion of new providers, such as gaming, social networking, auction and video sites, and technologies, such as wireless internet and broadband, present a serious problem for the police, MI5, Customs and other government agencies.

Communications data is now a key weapon in securing convictions of both terrorists and serious criminals. It also plays a central role in investigations into kidnappings and inquiries into missing and vulnerable people.

It is indeed a challenging problem. How do government security services exercise their legitimate need to have access to some communications-related data in the pursuit of a crime when the communications providers are no longer easy to identify?

In the old days of just the PSTN, the communications carriers were easy to identify and easy to work with… in the sense that jurisdiction was usually rather clear since the provider was based in the country where the communication was taking place. Government security services could work with those companies to be able to do lawful intercept and other such actions.

VoIP changes all of that. From a technical perspective, geography goes out the window. You can use a software product created by a company from anywhere in the world to communicate with someone else. It can be encrypted. It can use different protocols. It can be unencrypted yet go over an encrypted VPN.

THERE IS NO CENTRAL CONTROL!

And without central control, there is no central way for a government agency to be able to easily obtain that communications data.

So what do you do? Do you create (and somehow futilely attempt to enforce?) draconian and Orwellian legislation that gives government agencies extremely broad powers to access Internet-carried information? (As it sounds like is happening in the UK?) Do you try to have industry entities voluntarily assist security agencies? Do you give up and admit that it’s next to impossible to really get all this kind of information?

There’s a balance to be struck somewhere in there – and finding that balance is going to be one of the toughest policy issues we all will confront over the next few years.

I can see both sides… as a strong privacy advocate, I do not want the government to have broad powers to intercept and view Internet traffic – the potential for abuse and mis-use is far too high in my opinion. Yet at the same time as a father and husband I can assure you that if something were ever to happen to any of my family, I would want law enforcement to have access to every tool imaginable to track down the perpetrators and bring them to justice.

Where’s the line? What’s the right approach?

No easy answers…

Technorati Tags:
, , , , , ,

China’s TOM-Skype Surveillance

According to a report published on October 1st by Citizen Lab, full chat text messages from TOM-Skype users were found on publicly-accessible web servers as well as the encryption key required to decrypt the data.  Additional data such as millions of IP address, user names, and land-line phone numbers, and records of international users who regularly communicated with Chinese users were found alongside the chat logs.

From an Ars Technica article about the report:

Clearly, there are a number of problems with this discovery, starting with security. Villeneuve notes that the information contained on the servers could be used to exploit the TOM-Skype server network, and an attacker can access detailed user profiles. “In fact, evidence suggests that the servers used to store captured data have been compromised in the past and used to host pirated movies and torrents (for peer-to-peer file sharing),” reads the report. Clearly, crafty hackers already know where these servers are and how to get into them.

While troubling from an overall Skype security standpoint, it’s not much of a surprise that the Chinese government had a way to monitor their Skype users, especially with Skype being partnered with TOM Online, a Chinese company.

Since around September 2005, Chinese users attempting to download the Skype client were blocked from doing so, instead being redirected to a modified Chinese version hosted by TOM.  Did anyone really think that this modified version wasn’t backdoored?  Who wants to bet that they have keys to decrypt the voice channels as well?

The reason why (probably) you can use Phweet on a plane when Skype is blocked

Update #1: Since publishing this post this morning, I’ve learned of David Berlind’s success using AOL’s video chat from the plane. Odds are that it works for a similar reason to what I outline for Phweet below (and that eventually it will be blocked).

Update #2: As expected, GigaOm is now reporting that Aircell is blocking the Tringme VoIP client used by Phweet.

So how did Andy Abramson make a call using Phweet on the new Aircell Gogo Internet service on American Airlines planes? Why was the call not blocked like Skype or Sightspeed calls were?

As I discussed in my last post, VoIP calls have certain network characteristics that make them easy to identify and, in Aircell’s case, block. A VoIP call starts up… a stream of typically 100 packets per second start streaming over UDP between two endpoints… the networking monitoring software notices this, watches it for several seconds, decides it’s VoIP, and blocks the stream.

So why was Phweet’s web-based solution different? Why did it work when Skype, Sightspeed and other services fail?

THE CASE OF THE MISSING PROTOCOL

To understand, we need to look at the traffic from the Flash softphone that is being used by Phweet. The Flash-based softphone is actually from Tringme and is integrated into Phweet’s services. Let’s look at the network capture from a call I had today with Phweet CEO Stuart Henshall using the Flash softphone:

voip-wireshark-phweet1.jpg

Like the Skype call in my other post, you can see that there is a jump here (at about the 155 second mark) where the Tringme client connects to the Phweet conference bridge. We now have streaming audio, coming in a little less than 100 packets per second (more on that later). Stuart and I talked too long so I can’t easily show you the corresponding dropoff when the call ends (and still use the same scale as my other blog post) but suffice it to say that when the call is over the traffic returns to the previous lower (and bursty) level. Like the Skype calls, the packets sent by the Tringme softphone were small.

So if the pattern is the same, why didn’t Aircell’s sniffers recognize the call and block it? (Have you figured it out yet?)

To see one of my guesses, recall that in my last post I showed how a Skype call was typically all UDP:

voipcall-wireshare-udpred-1.jpg

Now let’s look at the Phweet call with the exact same UDP display filter turned on in Wireshark:

voip-wireshark-phweet2.jpg

Oops! Where’s the UDP?

Exactly.

If I look at the traffic and set a display filter to show all the traffic to the IP address of Phweet’s conference bridge, I can see (blue line) that indeed the traffic to/from Phweet is responsible for the uptick in packets:

voip-wireshark-phweet3.jpg

So if you haven’t already figured it out, let’s bring in a graph showing the other transport protocol, TCP, in green:

voip-wireshark-phweet4.jpg

And there you go… one very possible reason why Phweet may work and Skype, Sightspeed and others were blocked is simply this:

The Tringme Flash-based softphone is sending audio over TCP and Aircell is not recognizing and blocking VoIP calls over TCP.

Or at least Aircell wasn’t blocking TCP. (They probably are by now or will be soon.)

Now to be fair, if Aircell isn’t blocking TCP, this was probably a decent assumption to make. I mean, the typical mindset to date has been… who in their right mind would send audio streams over TCP?

In all the VoIP systems I’ve worked with, I can’t think offhand of any other systems that send audio over TCP. As part of its range of tricks to get through firewalls, I understand that Skype can use TCP if it is unable to send over UDP, but I’ve never captured it doing so. The IP-PBXs I’m familiar with, both commercial and open source, all send RTP over UDP.

The reason is simple… speed. Setting up a TCP connection involves the “three-way-handshake” and each packet contains information to ensure the packet will get there. If packets aren’t received by the other end, there are requests for retransmission. Data is guaranteed to get there and get there in the right order. It’s perfect for transfers of data where you want to ensure it gets there. However, in poor network conditions, it can be slower due to frequent retransmissions.

UDP on the other hand, makes no guarantees of delivery. Packets are just tossed out on the network pointed at the other endpoint and you hope that they get there. It’s fast, because there’s no involved connection setup, no packet tracking and no retransmissions. If some packets get lost along the way, oh well. Most VoIP systems tend to use UDP because the human ear is okay with a certain degree of lost audio. If some packets get lost along the way, we can probably still make out what the other person is saying. (And cell phones have gone far to degrade our perception of audio quality… but that’s another rant.)

Now in a network with good bandwidth, the performance between UDP and TCP may be similar enough to be okay… but in poor networks, TCP will be slower. For that reason, most folks in the VoIP industry have opted to go with UDP.

So one explanation for why Phweet/Tringme worked on a plane when Skype didn’t is that Aircell made an assumption that all VoIP calls that they want to block would send audio over UDP. The Tringme softphone used TCP instead – and so it got through.

THRESHOLD TOO HIGH?

However, the network trace gives a second possibility for why Phweet worked by Skype didn’t. If you look at the capture from my last post, you can see that the Skype call was coming across right about 100 packets per second:

voipcall-wireshark-udponly.jpg

The math behind this is fairly straightforward. If you are using the 20ms sampling rate common in VoIP systems, that means that there are 50 packets per second (simple way to figure this out – divide 1 second by 0.02 to figure out how many times 20ms is in 1 second). With two audio streams (sending and receiving), the Skype call would generate roughly 100 packets per second.

Now look at the Phweet call using the Tringme Flash softphone:

voip-wireshare-phweet5.jpg

You can see that the packet rate is not at 100 packets per second and is more somewhere between 60 and 70 packets per second. There’s a simple possible explanation here:

The Tringme Flash client could be using 30ms sampling.

If you increase the size of each audio sample from 20ms to 30ms, you reduce the number of packets generated per second from 50 to… 33. (1 divided by 0.03 to get how many 30ms packets are in 1 second) Double that for the sending and receiving audio streams and you have a total audio packet flow of around 66 packets per second. Which looks awfully close to what is here.

So a second potential reason why Phweet worked and Skype didn’t could be this:

Aircell has set their threshold too high for recognizing all VoIP calls.

It could be that their software is set to trigger on a stream of small packets between two endpoints at 80 packets per second for a period of, say, 5 seconds or more. Anything that hits that rule gets blocked. Maybe it’s 90 packets per second. Maybe it’s 70.

The point is that Aircell may have made the assumption that all VoIP clients would do 20ms sampling and generate a packet flow of ~100 packets per second. The Tringme client used by Phweet does 30ms sampling and so comes in below this threshold.

THE FUTILITY OF FIGHTING THIS ARMS RACE

Now there may yet be another reason why Aircell didn’t detect and block the Tringme softphone used by Phweet. But I would hope that the two potential explanations above would point out the inherent futility in Aircell’s attempts to block VoIP:

There will always be some VoIP client that will find a way around Aircell’s blocks.

If Aircell is blocking on pattern recognition as I’ve discussed in this post and the previous one, someone will make a VoIP client that goes to 40ms sampling over TCP, dropping the packet flow down to a total 50 packets per second. Maybe they’ll use a codec that generates larger packets so that voice traffic becomes indistinguishable from file traffic. Maybe they’ll create a VoIP client that is easily configurable by the person using it so that someone can tweak the parameters while they are on the plane (and subsequently twitter/blog about how they did it).

If they are blocking on protocols like SIP, someone will start using an IAX2 softphone… and when they block that, someone will resurrect an H.323 softphone… and so on.

If they start doing deeper packet inspection, someone will figure out how to use a VPN client that encrypts everything and perhaps fills out all packets so that they are an identical size.

There are a zillion things that people can do to route around and defeat blocking… and in this age of social media, such successes get spread via wildfile (induced by services/sites like Twitter, Techmeme and others). And so many more will learn how to get around Aircell’s blocking… until Aircell improves their blocking… until someone gets around that blocking… and Aircell improves their blocking… and someone gets around that blocking…

Aircell can fight that battle. From their ToS and comments made after this incident, it seems that they will fight this battle and waste their time, energy and resources trying to fight the never-ending cycle of creativity by those who want to go around the system.

Good luck to them.

P.S. I do think there are larger cultural issues we need to work out with regard to having access to VoIP in a plane. I do agree with Aircell’s CEO’s comment (in Joanna Stern’s article) that most all travelers have an aversion to people talking loudly on a plane. And yes, access to VoIP calls could definitely make this worse. (I recently tweeted about my experience with cell phones on the train.) But I think we need to figure out some way to deal with that outside of blocking. As Andy said on yesterday’s Squawk Box when we talked about all of this, perhaps there will be new sections on planes where people will be free to talk (or “quiet-zone” sections where they aren’t!).

Technorati Tags:
, , , , , , , ,

Dan York is Best Practices Chair for the VoIP Security Alliance and writes here and at DisruptiveTelephony. You can follow him on Twitter or identi.ca.

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: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:
, , , , , ,