Slashdot Mirror
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."
[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.
Anyone using the Skype public API can make apps that call someone.
Kopete IM for KDE is the first that pops to my mind.
Right, because this is clearly a security flaw you'll only find in Apple products.
There's no -1 for "I don't get it."
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?
I was all set to shout; "See!? This is where Android rules!" Then, I thought better of that idiotic statement. Android will have this same issue and more of the same data hijacking apps that every system will contend with. Personally, I can think of worse things than a random skype call. Come on, Saddos! This is how you meet new people in the Golden Age of Social Networking. Get with the program as say hello to your new random friend!
This is the NSA, we're gonna geet U h@x0r5! Also, what is a h@x0r5?
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?
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.
Security is mostly a superstition... Avoiding danger is no safer in the long run than outright exposure. - Helen Keller
It's odd to me that so many people on Slashdot who complain about platform openness on the iPhone, are suddenly eager to close down a channel of functionality.
In reality, you want any app to be able to use a defined URL handler path without interdiction - imagine a flow of photo editing apps where you use two or three, it's already slightly jarring to switch apps, why would you want a system dialog in the middle of that flow for each call?
It really does make a lot more sense for some application that has a protected resource it allows custom URL handlers to activate, to place protection in front of that to be confirmed by the user - Apple does it with the call mechanism, any app that makes a call does prompt the user to confirm a call is desired. So Skype should in fact follow suit, but we should harm the flow of data between other applications in the system just because one app developer is a bit weaker on security.
Can you really call pay numbers via skype anyway? I would have thought that would cause skype to verify you really wanted to make a paid call, regardless of the number coming in via an outside source or the user typing it in... if you can't make a call on skype that costs anything, then securing it seems kind of moot since there'd be little point in an attack.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
URL handlers handle URLs. Geeks are shocked.
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.
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.
What part of "shall not be infringed" is so hard to understand?
If you require all URL schemes novel to the system to be validated by the user before they launch the other application, then you just end up with the "Are you sure you want to do that?" problem we all loved on Vista. Some application-defined URL schemes trigger Really Big Things (like Skype calls), and some just launch the app, it's up to the developer who decided to invented the scheme to actually describe what the scheme does. It's obviously impossible for the host OS to test an arbitrary URL to see if it "does something bad" or not, since that would require the OS solving the halting problem on the target app for the given input.
Of course you could point out that this is a side-effect of the fact that URLs are pretty much the ONLY way to do application-level IPC on iOS. Since URLs are highly containable, don't let apps share memory, are rigorously parseable, etc. they present a very thin vector for making Bad Things Happen, compared to anything else.
Don't blame me, I voted for Baltar.
No I don't. In fact, I just want a web browser that's a web browser, and is completely lacking the ability to run arbitrary programs on the host machine.
And that's what you have. The web browser can only launch apps where the app itself defines EXACTLY the URL schemes that it accepts, the app can only be launched if you use a link of the form the application expects - and then the application will be launched into a method explicitly built to handle that launch path.
The URL scheme is a great way for applications to transfer data between themselves, as in the example I gave where a photo can be transferred between a few different photo editing applications. We have only one instance here where THEORETICALLY it could be a problem that a web link can trigger a skype call, even though no-one has yet laid out the path where that costs the user any money without interdiction (does the Skype app really let you call pay numbers that are entered even by hand? That seems like an issue by itself).
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I really fail to see how it is Apples fault that a third part App does something.
The whole point of the "walled garden" approach - its ultimate benefit - is that apps that "do something nasty" are not admitted, and those which are, are forced to behave.
That said, TFS really makes it sound it much more scary than it really is - if it could somehow launch Skype in background and make a call, that would be a security issue. This? Skype actually pops up and starts dialing, so the user can break the call right away. And the user will be watching, because you have to have him there to trigger your "exploit" by navigating to the page with the iframe.
I wonder, will it work with a JS timer reloading iframe to the required URL while the phone is locked? It's about the only way I see of actually exploiting this... have the user navigate to some seemingly legit page & stay there, and then have it trigger a bit later. But I very much doubt it would work - does JavaScript continue to execute in Safari when you switch away from it or lock the phone?
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.
Actually, it can't make real phone calls, if you try to make a call with a URL via the phone app, it does the right thing and asks the user first. This is a vulnerability in the Skype app, which should not be initiating potentially expensive actions without prompting the user first under any circumstances.
Imagine a similar case where an app allows other apps to trigger a purchase within it using some proprietary URL scheme, how would Apple sensibly prompt the user when they don't even know what the scheme does and it could change at any time? Users want to be told:
'This action will do x, do you wish to proceed?'
not
'Should the URL sheme://foobar/%202890%56745 be opened in application x'
That leaves you open to all sorts of social engineering attempts with obfuscated URLs for a start.
It's up to the application to decide if actions should happen without prompting the user or if the user should be asked first, and in this particular case I think Apple are completely correct to say that responsibility lies with Skype.
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.
Carol vs. Ghost