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."

Comments

3rd Party Responsibility?

[WrongSizeGlass]

[disclaimer: Mac & iPhone user]

The responsibility is on 3rd party app developers? Hogwash! If Apple wants full control of the app development & distribution process then they get the full responsibility for the security too. Yes, 3rd party apps need to be smart and act in the best interest of the user but Apple's stranglehold of the environment puts this squarely on their shoulders. Fix it Apple, plain and simple.

Re:3rd Party Responsibility?

[Bigjeff5]

Here is how it will go down:

First, Apple say this is an app issue, and app vendors need to fix it. They will dig their heals in and effectively say "screw you" to all their loyal customers.

Then, in the next iOS update (or the one after, if the next update is scheduled to be too soon) there will suddenly be a prompt for launching applications via registered URL handlers, possibly with some hype about how Apple is looking out for you, but not necessarily.

When confronted about the dichotomy between their two positions, Steve Jobs will simply reply "Apple is always concerned about the security of our customers, of course we would want to protect them from these kinds malicious attacks." All the while giving the reporter a befuddled look, as if to suggest the reporter is crazy for even asking such a stupid question.

Re:3rd Party Responsibility?

[jo_ham]

And in the update tech document, that catalogs the changes, it will give a description of the problem, what has been done to fix it and then "credit to Nitesh Dhanjani for reporting this issue". You know, like all the other security update knowledgebase articles on Apple's site.

Re:3rd Party Responsibility?

[Culture20]

Yeah, the fix should be simple. Add this to the list of requirements for apps and don't approve any that don't implement it.

The fix _IS_ simple. "This website is attempting to open XYZ.app. [ ]Allow? [X]Deny?"

Re:3rd Party Responsibility?

[GameboyRMH]

So the curated iOS apps really then are the same as any other "Open" platform apps that user can download and install themselves. The only difference of course is that Apple get their 30% and are in a better position to control their platform - all nicely in the name of the user benefits!

You beat me to it, the "quality, security and support" arguments for curated app stores are DEAD now. Quality was a stillborn argument, security was quickly disproven, and now this support is the last nail in the coffin. When it came time for Apple to put their money where their mouth is, they offered a level of support that would only be acceptable for an amateur FOSS project (basically none, much like the weeks when the PDF exploit used by jailbreakme.com went unpatched) - except you can't even fix it yourself. And you're paying game console prices.

Re:3rd Party Responsibility?

[bh_doc]

"You are coming to a sad realization, Cancel or Allow?"

I know I've heard that somewhere, but for the life of me I just can't remember where...

Re:3rd Party Responsibility?

[tbird81]

Here is how it will go down:

First, Apple say this is an app issue, and app vendors need to fix it. They will dig their heals in and effectively say "screw you" to all their loyal customers.

Then, in the next iOS update (or the one after, if the next update is scheduled to be too soon) there will suddenly be a prompt for launching applications via registered URL handlers, possibly with some hype about how Apple is looking out for you, but not necessarily.

When confronted about the dichotomy between their two positions, Steve Jobs will simply reply "Apple is always concerned about the security of our customers, of course we would want to protect them from these kinds malicious attacks." All the while giving the reporter a befuddled look, as if to suggest the reporter is crazy for even asking such a stupid question.

After this, Apple users on Slashdot will defend Steve Jobs. They'll state this can happen on any operating system, and that it is not Apple's responsibility. Then they're say how they are immune to viruses. They'll rejoice when they get their new version of Safari, which is limited to Apple's pre-approved sites.

Then their call will cut out, their screen will break, and their data will disappear. Steve Jobs will tell them that they are "holding it wrong". Apple fans will then bend over and take this abuse, at a personal cost of $4000.

Re:3rd Party Responsibility?

[Bogtha]

In case anybody was wondering about that documentation, Apple specifically warn against this in the documentation for this API:

Be sure to validate the input you get from URLs passed to your application; see "Validating Input" in Secure Coding Guide 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.

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:Once again proving...

[Anonymous Coward]

Whether or not a similar problem exists in competing products is beside the point. Nobody pretends competing products are implicitly secure straight out of the box. Apple fans pretend exactly that.

Or do you think that it's OK that your walled garden iOS product can make calls (potentially to expensive toll numbers) without any prior warning, simply by visiting a malicious website -- and that Apple doesn't think that's a problem?

Is this *really* only an Apple bug??

[bradgoodman]

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. The same kind of exploits could be done on PCs - if you had a URL handler - like "SSH" which blindly allowed a third-party URL-click to launch SSH on your PC and log into a site - or even to do the same thing with *skype* URLs. Has anyone verified if these kind of behaviors would or would not happen on a PC or Linux machine?

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

[je ne sais quoi]

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.) On the other hand, I seem to recall that a big complaint of Windows was that it was too easy for someone to make use of a security flaw in an application because all the applications ran under administrator privileges. This smells the same way, too easy to "one-click" your way to identity theft.

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:Apple should handle but it's Skype's fault

[Bigjeff5]

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

ANY app can be opened this way.

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.

This just in

[blueg3]

URL handlers handle URLs. Geeks are shocked.

Re:Once again proving...

[Zak3056]

I really fail to see how it is Apples fault that a third part App does something.

When you require that EVERY application that can run on your platform be approved by your personnel for sale, I'd say that you bear some (though by no means all) responsibility for the application's behavior.

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:Apple should handle but it's Skype's fault

[dzfoo]

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.

So, in your recommended solution, the user would click a "skype://" link and Safari would prompt him with a necessarily generic message such as "You are about to launch Skype, are you sure?" And when the user confirms this, then Skype would launch and prompt the user with a domain-specific message such as "Call: 1-900-xxx-xxxx - This call may incur additional costs. Are you sure?"

Two clicks for the price of one. Yes, that's the kind of Apple human-computer interface we all know and love.

No, this is not a iOS security vulnerability. Safari, nor the operating system, has any way to know whether the resource offered to the external application is exploitable. Except of course when the external application is provided by the OS itself or by an application included in the built-in suite; such as the example of the "tel://" protocol scheme.

For the confirmation message to be meaningful, it must be presented by the target application--which has intimate domain and context knowledge of the resource. That, or Apple would need to keep track of the context and semantics of each and every protocol scheme and how they can be used.

However, this last one still would not be perfect, for each application is free to use the submitted resource in any way it wants to. There is nothing that prevents Skype from receiving a "skype://" URL and deciding to, say, delete your Skype address book, or initiate an HTTP download.

        -dZ.