Not that anyone was really expecting bulletproof security using a free, ad-supported videoconferencing app on a smartphone operating system designed to make it easy for apps to share information with almost anything that's interested without worrying too much about separating private data from public, but...
Skype, running on Android, turns out to be less secure than you might have hoped.
"Sloppy coding" in the Skype client leaves most of the user-data files unprotected and sharable with apps already on the phone and, potentially malware or sniffers nearby that can identify it and send the right query.
"Skype mistakenly left these files with improper permissions, allowing anyone or any app to read them," anAndroid Police contributor and security researcher using the name Justin Case told Computerworld.
In his entry on Android Police, Case said he expected the sloppy security was from a beta version that was posted with more holes than usual.
"But upon examining the standard version of Skype for Android (which has been available since October 2010) I discovered the same vulnerability – meaning this affects all of the at least 10 million users of the app."
The only version he found that was unaffected was Skype Mobile for Verizon.
The others left data files unprotected and unencrypted, including main.db, which stores nearly all a user's relevant information, including real name, account balance, data of birth, location, office, home and cell phones, email addresses, bio information and other data. Chat logs, contacts lists and other usage information is also available.
Case posted proof-of-concept code for an exploit to collect the data and return it to him. Modifying the code and distributing it via the Android Market would give hackers a huge base of potential victims and a distribution network through which to reach them. Once the app is posted, hackers would just ahve to "watch as all that private user information pours in," he wrote.
Skype, Google Talk and other VoIP apps are a great addition to Android because it gives users the option of going around the service provider's own voice services and requirements to make calls or chat – at least to the extent that's possible while tethered to the provider's data network.
Private VoIP and chat apps are good for companies with highly mobile workforces for the same reason and because they create semi-private social networks employees can use to reach each other more easily.
The same speed and flexibility that gives smartphones great potential puts them in a position to do a lot of harm, as well.
IT people don't forget that. The likelihood they'll lose their jobs if it happens tends to keep the risk high in their thoughts.
Pressure from end users, gushing praise from tech bloggers (me included) who see the potential of consumerized IT but don't have much on the line when it fails and a constant flush of new products and services from phone makers tends to trump the instinctual reservations most IT people have to letting brand new technology drink from pools of sensitive data.
This is a good warning not to let that happen.
If you need to make the point that smartphone apps can be insecure if you don't set them up correctly (if the end users are in too big a hurry), download Case's proof of concept exploit (bottom of the page) and show one of your execs how much data you can pull off a phone.
Do it with him or her in the room so they know you're not looking in their chat files. You probably already know about the chats they'd be embarrassed to make public, but there's no reason to rub their noses in it.
Don't slow down the BYOT or handheld adoption that's already going on, if you can possibly avoid it.
Instead make yourself the expert source users can turn to, by checking out the most popular apps with your systems to identify any security holes.
Patch those, publish a list of safe apps, and users will mostly stick to that list. They'll try a bunch of apps you haven't checked; most will delete those eventually and stick to the ones you've declared to be safe.
They don't want to lose their data, either, or look stupid by using a rogue app instead of a sanctioned one for the same purpose and causing a big security headache.
That would get them fired, too. And maybe, if you've done enough to establish you're trying to check and certify a wide enough variety of apps, give users enough choice and generally take advantage of the free(ish) resources out there, even if there's a big security problem, the axe will fall on someone else instead of you.