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?
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.
iPhone is also a trademark of Cisco. I think Apple probably has it covered.
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
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.
Is this a private family duff up...or can we all join in?
A closed mouth gathers no foot.
Of course there is no exploit.. Neato try though.
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
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.
They are not saying you should warn for every link. Only that you should warn if you are going to do some that um requires a warning...Just opening the itms to display an app is not a dangerous activity, it would be beyond annoying to prompt for that.