Forgot your password?
typodupeerror
Communications Iphone Security Apple

Malicious Websites Can Initiate Skype Calls On iOS 177

Posted by Soulskill
from the buck-passing dept.
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."
This discussion has been archived. No new comments can be posted.

Malicious Websites Can Initiate Skype Calls On iOS

Comments Filter:
  • <iframe src=”terminal:echo h4x0r3d | wall"></iframe>
  • by WrongSizeGlass (838941) on Monday November 08, 2010 @09:09PM (#34168752)
    [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.
    • by Bigjeff5 (1143585) on Monday November 08, 2010 @09:39PM (#34168974)

      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.

      • by jo_ham (604554) <joham999 AT gmail DOT com> on Monday November 08, 2010 @09:51PM (#34169046)

        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: (Score:3, Insightful)

        by tbird81 (946205)

        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

    • by beelsebob (529313)

      Way to jump on the modpoint bandwaggon. If on any other OS an application could end up charging you money by responding to a certain URL type you would place the blame firmly on that application. The OS does not know what's going to cost you money, nor does it know what the application is going to do with the URL it receives, only that it's registered to receive it.

      You could claim that apple's app store testing process should catch this, and it's plausible that (for example) Tesco might refuse to sell sof

    • by Bogtha (906264)

      [disclaimer: iOS developer]

      Apple are right, the responsibility is on the app developers. The data passed in through a URL is untrusted data. It's not just websites that you surf to that can send data to your app this way, other apps can too. That's its designed purpose; to "secure" this functionality on Apple's end would essentially be to remove it.

      Applications that tell the system that they handle a URL and then blindly trust data they receive through that mechanism are essentially the same as web

    • by Wovel (964431)

      You are obviously confused, obviously never written an application for anything, and certainly never written an iOS app. Application developers have the ability to create confirmation dialogues and the responsibility to do so. From the nature of the ignorance displayed in your post I would assume you have never used an iPhone and certainly never used an iPhone Skype app. Your false outrage is more annoying than cute.

      Apple's only realistic solution would be to reject apps that do not use confirmation dial

  • Uhm... (Score:4, Informative)

    by larpon (974081) on Monday November 08, 2010 @09:09PM (#34168756)
    Anyone using the Skype public API can make apps that call someone.
    Kopete IM for KDE is the first that pops to my mind.
    • Sweet! Make one that calls half of the people "assholes" and the other half "geniuses." That'll leave them scratching their eyes and heads.

    • What is your point?

      This is about websites, not about programs you've installed yourself. Did you read the headline?

      • But you installed Skype. This is a stupid issue, since Apple doesn't know how to validate the data passed via the handler... it's up to the app launched from a (possibly untrusted) source to check it all. Most apps do this, and I would've done it out of habit.

        It's a Skype bug that's easy to fix. I'm sure they'll have a patch out in the week.

        • by Culture20 (968837)

          But you installed Skype.

          knowing that skype could call from visiting webpages in safari? It's not called "skype mobile safari plugin app"

          This is a stupid issue, since Apple doesn't know how to validate the data passed via the handler... it's up to the app launched from a (possibly untrusted) source to check it all.

          I agree, but only about the stupid issue part. It should be up to the human, the owner of the phone, to check it. But apple wants to remove thinking from their users (spelling correction, not spelling checking).

  • 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:

    1. Skype is competing with their FaceTime and Phone/SMS interfaces.
    2. If Apple were to implement generic protocol handler inderdiction/approvals, this opens up a huge can of worms and it Apple begins to own the problem (more than they currently do).

    I see where Apple doesn't want to do the right thing, and ultimately, it's still Skype's fault that they do

    • by Bigjeff5 (1143585) on Monday November 08, 2010 @09:42PM (#34168990)

      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.

      • by mini me (132455)

        Not all URL handlers point to resources that can be exploited. Apple is right here, it is up to the app developer to determine what the user should have to confirm and what they should not have to.

      • Re: (Score:2, Informative)

        by atchijov (527688)
        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 ba
      • by wkcole (644783) on Monday November 08, 2010 @11:56PM (#34169932)

        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.

        • by dzfoo (772245) on Tuesday November 09, 2010 @07:32AM (#34171876)

          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.

          • by Wovel (964431)

            No I think he was suggesting that the URL handlers allow the custom confirmation to be launched inside of Safari before even launching the app (like the standard phone number handler in iOS).

            • by dzfoo (772245)

              But there's no way for it to know what the handler is going to do prior to calling it! It's like asking Safari to solve the Halting Problem when seeing a URL protocol scheme.

              You are predicating this solution on the assumption that the scheme "skype" means "make a VoIP phone call", but it doesn't mean that at all. It literally just means "this scheme is handled by the application Skype, for it knows what to do with it." It could mean "make a VoIP call," but it just as well could mean "write to log file,"

          • by Culture20 (968837)
            If I got a prompt from safari telling that a website wanted to open skype, I'd say "WTF?! Hell no!", then thank appl for protecting me from random stupid website. As it stand now, I have no idea which of my apps might have "backdoor" URL handlers. Will the NPR app open if I visit npr's website? Will Super amazing fart soundboard open and make fart noises when safari sees a google ad? The dual prompt may not be the apple way, but it is the right way. If I'm reading a webpage, I'd like some notification t
          • by wkcole (644783)

            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.

            A quarter century of experience with Apple's HIG has taught me that "know and love" is not really a suitable phrase. That implies something like a monogamous spousal relationship, while the reality for Apple customers and developers is more like being regulars at the Moonlight Bunny Ranch...

            What I'm suggesting is that currently apps have a responsibility to do their own authz dialogs because nothing else does. Ultimately an app that does potentially risky/costly things depending on the specifics of the p

            • by dzfoo (772245)

              What I'm suggesting is that currently apps have a responsibility to do their own authz dialogs because nothing else does. Ultimately an app that does potentially risky/costly things depending on the specifics of the passed URL will always have to do that unless Apple creates a means of registering a parser to translate an URL to the text of an authz request. Because apps are written and used by populations large enough to each follow Sturgeon's Law, the right thing for Apple to do given the established arch

      • ANY app can be opened this way.

        If you've registered a URL schema to the OS, and the OS calls up your app when it sees that URL schema... how's that different from any other OS (w/ the associated software suite), like Windows and Linux?

        The OS could help by telling your app things like "this URL comes from an Internet URL on Safari".. but it's by no means the OS's fault. It's just doing what it's supposed to do, an intermediary.

      • by Wovel (964431)

        "ANY" app wil not have a URL handler.

        Of the few that do, very few of those do anything that would require confirmation. The documentation for App developers clearly tells them to validate input, etc. when launching their app from a URL handler.

        You are obviously confused about what a URL handler even is.. Cure that you got modded insightful though.

    • by Angostura (703910)

      If only Skype actually allowed video calling from an iPhone, yes they would be competing with Facetime. Sadly, they don't.

      • by marsu_k (701360)
        You are certain that it is Skype placing this restriction and not Apple? My N900 can make Skype (and GTalk) video calls just fine.
  • by bradgoodman (964302) on Monday November 08, 2010 @09:32PM (#34168928) Homepage
    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?
    • by je ne sais quoi (987177) on Monday November 08, 2010 @09:44PM (#34169002)
      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: (Score:2, Informative)

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

    • file:///bin/ls on linux asks me to save the file. Firefox here doesn't understand ssh though that may be implementation specific.

      • by gman003 (1693318)
        file://c:/cygwin/bin/xterm.exe also prompts to save file (with a warning the .exe's are potentially dangerous), on Vista, using Chrome. Looks like even Windows is smart enough to not blindly execute URLs.
        • Re: (Score:3, Informative)

          by XMode (252740)

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

        • by Wovel (964431)

          You are wrong on every level and totally confused. I for one am shocked this was not modded insightful.

      • by blueg3 (192743)

        Why on earth would the file: protocol have the meaning "maybe execute this file"?

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

          • Re: (Score:3, Informative)

            by enoz (1181117)

            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: (Score:3, Insightful)

      by emt377 (610337)
      "Kind of"? Clearly the helper app has to do any validation and authentication since it has domain specific knowledge. How would the browser know to confirm, say "do you wish to call 1-900-xxx, this will incur a charge?" or "Upgrade CrapWare from 1.x to 2.3 for $19.99?" All the browser can ask is "really run helper App A?" Which may not mean anything to a user and they have no idea whether they want to or not. The fact that anyone can create a link or content that causes Skype.app to make a call really
      • What is clear is that I don't expect my web browser to launch external programs without my consent. Even starting an email client for mailto: urls annoys me. Displaying a dialog before running an url handler needs to be the default behaviour. I suppose you might want to give the user the option to opt-out of the dialog for an individual protocol on a per-domain basis, although I don't see what the big deal is with quickly displaying a confirmation dialog when I'm leaving the browser.

        And while Skype does hav

        • by Phroggy (441)

          I'm just irritated that Internet Config went away with the switch to Mac OS X. Such a simple, powerful idea! It would show you (among other things) a list of protocols, and what helper applications were associated with them, and allow the user to easily make changes. It was one of those little gems that was such a good idea that applications started almost universally supporting it even before Apple got on board. Then Apple made their own UI and shipped it with the OS, and life was good... until Mac OS

          • I have literally no idea how to view and change url handlers in Gnome, either. I suppose it's a weird mix between Firefox settings, Gnome settings and maybe some other stuff thrown in for good measure.

            There is a "Preferred Applications" preferences panel, which handles the frankly bizarre mix of default web browser, mail app, multimedia player, terminal app (?!) and two accessibility apps. I guess this strange mix of protocol handlers and handlers of other stuff is one of those things that is convenient for

        • by Altus (1034)

          See, I woudl find it a pain in the ass if my os made me click through a dialog every time I clicked on a mailto link. I just want the browser to get the hell out of my way and let me send some mail.

    • by blueg3 (192743)

      Well, on Firefox on Linux, an application that is registered as the URL handler (e.g., for callto:) is automatically launched when you click on an appropriate URL. No idea about iframes and other trickery. No idea how Skype on Linux works (if it confirms calls), but it's certainly up to the application.

      • Re: (Score:3, Informative)

        by moonbender (547943)

        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.

    • by jrumney (197329) on Monday November 08, 2010 @10:54PM (#34169488) Homepage

      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.

      • Protect users from what? They made a choice to install an app (Skype), and the app already has access to the system. Anything malicious it can do, it can do without registering an url handler.
        The Android method you're mentioning is valid, too. But with the "It just works" mantra from Apple, I wouldn't expect to be asked "are you sure you want to use skype for 'skype:*' ?"

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

    • Re: (Score:3, Interesting)

      by tlhIngan (30335)

      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 mach

  • 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!

  • by SuperKendall (25149) on Monday November 08, 2010 @10:09PM (#34169136)

    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.

    • by 0123456 (636235)

      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.

      • 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 applic

  • This just in (Score:5, Insightful)

    by blueg3 (192743) on Monday November 08, 2010 @10:14PM (#34169170)

    URL handlers handle URLs. Geeks are shocked.

I don't want to achieve immortality through my work. I want to achieve immortality through not dying. -- Woody Allen

Working...