Malicious Websites Can Initiate Skype Calls On iOS

An anonymous reader writes "In this article, security researcher Nitesh Dhanjani shows how iOS insecurely launches third-party apps via registered URL handlers. Malicious websites can abuse this to launch arbitrary applications, such as getting the Skype.app to make arbitrary phone calls without asking the user. Dhanjani 'contacted Apple's security team to discuss this behavior, and their stance is that the onus is on the third-party applications (such as Skype in this case) to ask the user for authorization before performing the transaction.' He also discusses what developers of iOS apps can do to design their software securely and what Apple can do to help out."

Uhm...

[larpon]

Anyone using the Skype public API can make apps that call someone.
Kopete IM for KDE is the first that pops to my mind.

Re:Is this *really* only an Apple bug??

[Anonymous Coward]

I'm conflicted. On one hand, Skype is sort of known for getting hacked (having had my "Skype account" hacked and a bunch of money charged to my credit card even though I didn't have and never did have a Skype account. It was a pain to sort out but as identity theft goes, not as bad as it could have been.)

So what you're saying is, your credit card number was stolen/skimmed and someone registered a Skype account with it to run up charges?

I fail to see how this is a Skype issue. The same thing could happen with Amazon or any other business that accepts credit cards over the Internet.

Re:Is this *really* only an Apple bug??

[Anonymous Coward]

This is not at all what the article is about. The iPhone won't execute random URLs either. This is only for apps that have explicitly registered their own protocols (like skype). So if you open skype://call?somecontact it will open skype and try to call that contact. Same exact thing happens on Windows with Skype installed, and it is exactly the same non-issue there.

Re:Is this *really* only an Apple bug??

[XMode]

Well you ARE telling it its a file... ssh://example.com would be an example of an ssh URL...

Re:Apple should handle but it's Skype's fault

[Anonymous Coward]

>> ANY app can be opened this way.

Wrong. No app can be opened this way unless they register a URL handler. And if they do, that is not in itself a security flaw. I wrote an app that registeres a handler and can be told to open a document. So a webpage could conceivably open my app. Not a practical flaw because people would have to have that app installed, then there would have to be an action that contains a security flaw that can lead to remote code execution. In other words, there is nothing here, and you don't know what you're talking about..

Re:Apple should handle but it's Skype's fault

[atchijov]

First of all, please check your facts before making such a broad assumptions. Application need to be configured in particular way in order to be invocable via URL in iOS. I will be surprised if 1 in 1000 applications in Apple iTunes App Store using this functionality. Secondary, It is 100% application responsibility to act "properly" when invoked via URL. All iOS does is firing app and informing it that it was invoked via URL. Skype choose to start call without getting confirmation from the user. Too bad for Skype.

Re:Is this *really* only an Apple bug??

[jrumney]

As an iOS developer - I kind of agree with Apple. I write apps which register URL handlers - and when one clicks on on - I make the *user* validate that this is what they really want to do.

If I write a seemingly harmless application that registers a url handler for the phish: protocol, then I agree that it is the application that is at fault, but I do expect the OS to protect users from this. Android pops up a dialog asking which application you want to handle the protocol - even when there is only one choice, and the user has to explicitly tick the "always use this application" box to skip that confirmation step.

Re:Is this *really* only an Apple bug??

[moonbender]

When I run a callto: URL in my Firefox/Linux, I get a dialog asking me if I want to open gnomemeeting. It's not opened by default, although there is a checkbox to do that for future invocations.

Re:Is this *really* only an Apple bug??

[enoz]

Historically that used to work on windows. You could launch executables with the browser.

I'm pretty sure only Internet Explorer behaved badly in that way.

Re:Apple should handle but it's Skype's fault

[wkcole]

It's not just Skype, that was just an example.

ANY app can be opened this way.

That is false. Most apps do not register URL handlers.

Should the small minority of apps that register URL handlers be trusting that when they get a URL tossed at them, the user knows and approves of the app being opened for that purpose? Of course not. That would be inconsistent with how iOS is documented to operate. Safari or any other app sending an OpenURL message has no way to know whether a particular URL scheme has a potentially risky handler on the other end. An app that receives an HandleOpenURL message knows what its URL scheme does and knows whether handling a particular URL might be risky. Some developers seem to be making use of the opacity of that mechanism.

It's definitely Apple's problem. Skype could have been really awesome fixed the problem on their end, but that would not have solved the problem for the 200,000 other apps that can be launched this way.

Where do you get that number? The biggest list of registered URL schemes I can find seems to have about 140 listed ("seems" = a crapulous website showing ~10 per page, 14 pages.) Most apps would have no need to register an URL scheme.

Skype dropped the ball here. Their app is doing something potentially costly in response to a system message that Skype knows the user might not have knowingly initiated. The app should be asking the user for authorization before initiating the call. Doing that would be more accurately described as "minimally competent" than "really awesome" unless you consider elementary security awareness "really awesome."

I don't get me wrong. I'm not saying that Apple shouldn't fix the design issue here, they should. But this is a UI design problem more than it is really a security problem. A wisely designed app that needs this functionality can ask for user authorization, but only after it has been launched and put in the foreground. Apple should generalize the integration they use in their own apps to a system-level feature that asks the user for authorization before switching apps whenever an OpenURL is sent that would switch apps. Let apps request quiet switching in their Info.plist and let users toggle that on a per-scheme basis. In the interim, they should go through the app store and remove every app that registers an URL scheme which it handles to do something risky without user authorization.

Re:3rd Party Responsibility?

[Bogtha]

In case anybody was wondering about that documentation, Apple specifically warn against this in the documentation for this API [apple.com]:

Be sure to validate the input you get from URLs passed to your application; see "Validating Input" in Secure Coding Guide [apple.com] to find out how to avoid problems related to URL handling.

And in that Secure Coding Guide, you will read things like this:

Any time your program accepts input from an uncontrolled source, there is a potential for a user to pass in data that does not conform to your expectations. If you don't validate the input, it might cause problems ranging from program crashes to allowing an attacker to execute his own code.

If your application has registered a URL scheme, you have to be careful about how you process commands sent to your application through the URL string. Whether you make the commands public or not, hackers will try sending commands to your application. If, for example, you provide a link or links to launch your application from your web site, hackers will look to see what commands you're sending and will try every variation on those commands they can think of. You must be prepared to handle, or to filter out, any commands that can be sent to your application, not only those commands that you would like to receive.

Re:3rd Party Responsibility?

[GameboyRMH]

You wish...Search for the list of security in Android, it is on here somewhere. Many of them are months (not the 2 weeks of the PDF exploit on iOS) and at least 5 of them are more serious, a couple can be exploited remotely.

Ouch! RIP strawman.

Your "interesting" post only pointed out one iOS security flaw, the "PDF" exploit and it still required the user to [do] someting.

Yeah like follow a link. Very remote chance of that happening, I know.

Your outrage over the URL handlers shows you know nothing at all about application development, url handlers, iOS, iPhones, web browsers, or application security.

LOL yeah I know nothing about those because I think a trivial-to-implement, HTML-based drive-by call activation exploit is a big issue. I'm totally blowing it out of proportion. This was a gigantic fail on Skype's part and Apple shares some blame too. Oh sorry, my ignorance is showing, I WUV APPLE!

I love your signature line touting the most completely insecure mobile environment available today.

The only thing insecure about it is that it doesn't protect stupid and determined users from hurting themselves. I welcome this "insecurity."