Proof of concept phishing attack mimics iOS popups to steal user passwords

2»

Comments

  • Reply 21 of 23
    cgWerkscgWerks Posts: 2,952member
    macplusplus said:
    Since apps are sandboxed in iOS, there is no common authorization or authentication API in iOS. Thus an app can only ask password for its services, login to a remote server and alike. An app cannot trigger deliberately system’s authentication and authorization dialogs, those are controlled by iOS, not the app. All an app can do is to present a fake iCloud login dialog, but this so rough and naive as an attack that it would be immediately discovered by AppStore review team and the developer may be banned and even reported to law enforcement for attempt to computer crime. There is nothing sloppy in iOS security architecture, all is finely crafted.
    You may know that, but the average user doesn't. When a user gets used to dialogs popping up in various other apps they use, they might not realize that when it pops up in XYZ app, that it's not from Apple.

    Yes, such apps get banned or hopefully caught before they get released, but they don't always. I seem to remember, for example, a browser that changed development hands that was doing just such a thing a year or so ago.

    But, my point is that Apple shouldn't be popping up dialogs here and there... it should all be in one place in the settings.
  • Reply 22 of 23
    cgWerks said:
    macplusplus said:
    Since apps are sandboxed in iOS, there is no common authorization or authentication API in iOS. Thus an app can only ask password for its services, login to a remote server and alike. An app cannot trigger deliberately system’s authentication and authorization dialogs, those are controlled by iOS, not the app. All an app can do is to present a fake iCloud login dialog, but this so rough and naive as an attack that it would be immediately discovered by AppStore review team and the developer may be banned and even reported to law enforcement for attempt to computer crime. There is nothing sloppy in iOS security architecture, all is finely crafted.
    You may know that, but the average user doesn't. When a user gets used to dialogs popping up in various other apps they use, they might not realize that when it pops up in XYZ app, that it's not from Apple.

    Yes, such apps get banned or hopefully caught before they get released, but they don't always. I seem to remember, for example, a browser that changed development hands that was doing just such a thing a year or so ago.

    But, my point is that Apple shouldn't be popping up dialogs here and there... it should all be in one place in the settings.
    It is already in the Settings. But there are instances that can't be interrupted yet that may require additional password verification, so restricting password verification to only the Settings app does not hold water. You cannot give up on password verification where required. No need to maintain this discussion further, there are tried and tested, established usage patterns which disruption may do more harm than good.

    If the user mixes up what password to enter where there is nothing more to do about that, Apple imposes 2-factor authentication to support such users and to reduce such mix-ups, besides AppStore review. You don't need to write a custom browser, any javascript code on any site can display a fake password dialog. You don't have to be a developer or cracker for that either, any script kiddie may do that.

    In addition, removing all the password dialogs and restricting that to only Settings app would still not prevent any fake dialog to appear and to fool the user.
    edited October 2017
  • Reply 23 of 23
    cgWerkscgWerks Posts: 2,952member
    macplusplus said:
    It is already in the Settings. But there are instances that can't be interrupted yet that may require additional password verification, so restricting password verification to only the Settings app does not hold water. You cannot give up on password verification where required. No need to maintain this discussion further, there are tried and tested, established usage patterns which disruption may do more harm than good.

    If the user mixes up what password to enter where there is nothing more to do about that, Apple imposes 2-factor authentication to support such users and to reduce such mix-ups, besides AppStore review. You don't need to write a custom browser, any javascript code on any site can display a fake password dialog. You don't have to be a developer or cracker for that either, any script kiddie may do that.

    In addition, removing all the password dialogs and restricting that to only Settings app would still not prevent any fake dialog to appear and to fool the user.
    There's no good reason I can see that you should have to enter your Apple ID and password more than one place in the settings. After that, you just need to authorize Apple to use the already stored info. If it needs to be updated, the user should go back to that spot and fix it. (What I was experiencing was just a very buggy multi-app Apple-cloud implementation... but my concerns - here - are more on the user impact in regard to phishing.)

    Yes, while it wouldn't prevent a fake dialog.... if there's nothing to mimic, the problem is largely solved. This is similar to the problem using social media accounts to sign into random blogs to leave comments. If your Facebook credentials only work when you're at Facebook dot com, then the problem is solved. But, once XYZ site can pop up a Facebook dialog, now you have to technically understand what's going on or possibly get fooled. It's just bad UI/UX practice.
Sign In or Register to comment.