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:
  • 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 shutdown -p now (807394) on Monday November 08, 2010 @11:09PM (#34169580) Journal

    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?

  • by Anonymous Coward on Tuesday November 09, 2010 @12:08AM (#34170004)

    Apple should do something -- it has been shown that it is up to the OS maker to handle security, as application makers really can't be trusted with much, if anything. Perhaps have a mechanism with an install manifest that if an app wants to do background tasks, the security is vetted, or the app stays in its cell. This way, unless Apple explicitly approves the app with the functionality, it just won't have the ability to do this. To boot, if an app maker fails to clean up their act, it gives Apple more grounds to yank their app and show them the door.

    Take a look at the Windows platform -- there are applications made that don't even support ASLR or DEP, hamstringing Microsoft's attempt at security. Because there is no ROI gotten by making an app play well with others, or even with itself, an app maker really has little to no financial interest in security.

    Application makers fail at security. It is up to the OS maker to wall them off, or else the entire platform suffers.

    Look at Android and the numerous privacy violations reported to /. by apps reportedly slurping SMS and contact data and uploading it to the blackhat's site. There is a reason that Android is starting to get a black eye when it comes to security, and that is because Google assumed that app makers actually didn't choose to shit where they sleep. Google needs an active app approval process, or the platform will be abandoned for one that does.

  • by tlhIngan (30335) <slashdot@wSLACKWAREorf.net minus distro> on Tuesday November 09, 2010 @01:33AM (#34170458)

    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?

    Already happened. With Firefox, at that, years ago.

    http://secunia.com/advisories/25984 [secunia.com]

    Firefox registered a "firefoxurl://" handler, which can call Firefox with arbitrary command line arguments, including malicious javascript.

    Apple can't validate every URL that passes through - if they had a magic library that could ensure every URL is completely valid in every context from now to forever, they would have that patented and licensed to everyone. So in the end, the application handling the URL must validate its arguments.

    The question is - does this affect the PC clients as well? Does Skype on Windows also have the same problem? Or does it not register any URL handlers so you can't just click a Skype link?

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

COMPASS [for the CDC-6000 series] is the sort of assembler one expects from a corporation whose president codes in octal. -- J.N. Gray

Working...