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."
...that Apple's products aren't all their fanboy customers hype them up to be. They have security through (still, relative) obscurity on the desktop. In mobile gadgets, where they're somewhat more common, they aren't secure -- and as shown in the quote here, Apple could care less about that. When they have the opportunity to use their walled garden to protect their customers, they don't actually do so, either -- hence proving that the walled garden is only there to protect profits, not customers.
All that greatness, *and* you have to pay over the odds to get it.
[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.
Realistically, all registered handlers should be interdicted like the call-interface.
However, I can see how it's in Apple's best interest to leave this to Skype:
I see where Apple doesn't want to do the right thing, and ultimately, it's still Skype's fault that they don't allow the user to approve call links.
Make sure everyone's vote counts: Verified Voting
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?
IOS ?
Isn't that CISCO's router OS ?
(I remember IBM having to rebrand their own (formally OS/400) own OS for IBM i systems from i/OS to IBM i5 OS because they feared a CISCO suit)..
enable
conf term
interface eth0
no shutdown
exit
write
exit
--Ivan
That's pretty neat, regardless of the obvious harm that it could cause. Set up a small server and trick people into calling you, for the lonely hacker!
Eat sleep die
... when a malware tried to initiate a Skype call from my iPhone but misspelt the skype_id ^^
Never trust a spiritual leader who cannot dance -- Mr. Miyagi
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
In reality, you want any app to be able to use a defined URL handler path without interdiction
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.
Every time I hear about a URL handler exploit I wonder who the hell ever thought that it was a good idea.
URL handlers handle URLs. Geeks are shocked.
iTunes prompt for password just popped up when I loaded safari to visit slashdot homepage. iPod touch 4g
You have added the first rational comment to this conversation. There is no security flaw here. Browsers also handle certain URLs. Those may be malicious, also. Does that make the browser insecure? No. It is doing what it was designed to do.
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
Apple has all the right in the world to say they aren't responsible for security... The Walled Garden ain't what she used to be. Jailbreak is legal. How can they be held responsible for what happens once it leaves the factory?
Disclaimer: I got No Apple Nada.
URL schemes are secure as they are. Applications have to define a scheme they will support; you cannot open just any application. Then when the app is launched it goes through a specific method built to handle parsing the specific URL that the application itself asked be used to launch. I don't see the security risk, at all.
Even in the case of Skype, what harm can an attacker really do? The worst I could see would be calling an expensive pay number. But wouldn't Skype have a built-in warning around that generally no matter how such a number was called? Shouldn't it? That's why protection of something that can cost real money would seem to be in the domain of the application itself to protect, because Apple cannot know all the possible input paths that trigger money to be spent.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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.
Another way of looking at it: if you've got an app that accepts an URL handler, do you want a braindead OS policy of asking the user for permission every time? Especially when the OS would likely have to ask, "do you wish to open foobar://1233453987039 with Metapie?"
The only way to avoid that would be for the app to register an URL evaluator and an URL security policy, at which point you may as well just have the app make the decision. It doesn't make any sense for this to be handled at the OS level.
It's funny how, if you unwrap your new Dell PC and find the keyboard too mushy, it's Microsoft's fault, but when there's an exploit on iOS in an ecosystem where each and every app is approved and sold by Apple, then "the onus is on the third party developer".
Its not the openness they are complaining about, its the hypocrisy.
Is this a private family duff up...or can we all join in?
A closed mouth gathers no foot.
But wouldn't apple have a built-in warning around that generally no matter what app was called? Shouldn't it? That's why protection of something that can do generic stuff would seem to be in the domain of the initiating application to protect, because Apple cannot know all the possible input paths that trigger damage, so they should defer to the end user (thinking human), not Steve Jobs' Perfect Algorithm.
FTFY
Where is the hypocrisy? The only hypocrisy I see evident is people attacking apple for being too closed at the same time they claim they are too permissive.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
If they want full control of what you can run on your won hardware then they bear full responsibility for the problems.
It is simple common sense, but as we know, Apple fanboys lack this when it comes to talk about their shinny gadgets.
I like how when they are explaining why they don't allow flash, or don't allow sideloading apps, or any of their other restrictive policies it's because they are doing it for the safety and wellfare of their users. But when someone points out an OBVIOUS problem, well, we just figure the devs have got it.
With SO many restrictions on what will and will not pass muster in the app store approval process, why not just require anyone with a protocol handler to request authorization?
Pretty weak response that undermines their position on a LOT of their policies, not that anyone here is surprised to find out that their controls are really about THEIR control and not just doing what is best for the average user.
OT: I really need to remember my stupid login. :(
I don't get how Apple's position in this is defensible. The whole iOS platform is sold as a locked down walled garden that, and I quote, "just works." This specific incident demonstrates two things to us:
1.) The application approval process doesn't actually protect us as users. We've all known this for a while, and by itself it actually isn't that big a deal.
2.) Apple's bottom line is the only thing the walled garden is protecting. If an application gets through the approval process but turns out to actually have a security flaw, that shouldn't be a big deal in a controlled market environment because you can either pull the application or change the environment to mitigate the issue. That obviously is not what is happening.
So yes, for those of you who are asking, we are actually upset that the iOS platform is both too closed and too permissive. We're complaining because it is closed in all the ways that hurt the consumer and yet isn't closed in any of the ways we were told it would help us. It is the worst of both worlds.
iTunes uses the itms: url scheme. Apple does not want either Safari or iTunes to alarm their users by warning them, or making them vouch for the use of iTunes.
The same lack of warnings about url schemes exists on OS X, and there I see that Opera, Chrome, and Firefox issue warning dialogs asking you to approve the call to the handler. Only Safari play dumb and blindly calls the external app.
And suppose the url scheme handling software really was malicious? Would Apple tell their exploited users, too bad that malicious app didn't solicit your approval. Bad app!
To suggest this is the external app's responsibility is utterly foolish.