Slashdot Mirror
Security Researcher Finds a Fundamental Flaw in iOS (krausefx.com)
Felix Krause writes: Do you want a user's Apple ID password to get access to their Apple account or to try the same email/password combination on different web services? Just ask your users politely, they'll probably just hand over their credentials, as they're trained to do so. This is just a proof of concept, phishing attacks are illegal! Don't use this in any of your apps. The goal of this blog post is to close the loophole that has been there for many years, and hasn't been addressed yet. For moral reasons, I decided not to include the actual source code of the popup, however it was shockingly easy to replicate the system dialog.
Phishing attacks that are well crafted don't count as flaws.
But this isn't a flaw in IOS. It's like saying Android is insecure because of fake emails I get asking me to reset my gmail password
This is where having a visual indicator that only the OS and user know about could help? It could be an image or a phrase, but the idea is that an application couldnâ(TM)t forge the OS dialogue, because it doesnâ(TM)t have access to that info.
At the same time, there are probably still limitations arising from an app asking for permissions it shouldnâ(TM)t need. This easier to vet for anything going through the App Store and possibly signed applications, but for anything else it is still user beware.
Jumpstart the tartan drive.
There's no equivalent to an iTunes account. If I'm asked for my Google Play account password I'm very wary.
You said there was no equivalent, and then listed the equivalent.
Lots of people use their Google account, or their Facebook account, to log into various sites and services. I'm not sure how Facebook works, because I rarely use it. Google makes you type in your password once per month, so Google users are also trained to enter their password more-or-less at random, when asked. It would be dead easy to fake the password dialog.
Users trading of security for convenience, yet again. The stupid thing is that companies encourage this behavior. If some service really wants you to login again, it should ask you to go log in, not present you with some dialog to type in your password.
Enjoy life! This is not a dress rehearsal.
Am I the only one that shakes my head every time I see this term used to describe a hacker/cracker/black hat that doesn't actually do research except to unlawfully break into other peoples stuff just to brag about it?
And to stay slightly on topic, this is just social engineering, not an OS flaw. Clickbait garbage.
Did they? All they said is that they'd be wary if they were asked for their Google Play password. They did not say that the request was ever legitimate. I imagine that if I was asked for the password, the phone would switch over to the Play store app before popping up the dialog - but I also can't remember ever being asked.
I'm asked for my Apple password at least once a week, and it happens absolutely randomly. I might be doing anything, and suddenly "hey re-authenticate please!". I've absolutely been trained to not question it and just punch the password in so my phone continues to work. This is even worse than the whole "constant UAC prompt trains users to just say yes", because it has absolutely zero context. I don't know what triggered it, I don't know how not putting the password in limits me exactly, I have no way of knowing it's really the system asking for the credential, and I'm not just pressing yes, I'm inputting my golden key. Just bad design all around.
Honestly I think this does count as a fundamental flaw--but a flaw in the design of the user interface flow used to obtain credentials for iTunes (or for other applications).
It's a flaw for two reasons. First, any process which interrupts your current actions with a modal dialog is a flaw in that if you are not paying attention, you may accidentally tap the accept or cancel button without realizing what you are doing. (This is worse on a desktop environment, where a pop-up may appear while you are typing. If you are a fast touch-typest like I am, you may accidentally press 'enter' or 'space' before realizing what you're typing has gone into the dialog box that just randomly appeared.)
Second, the design is a flaw because it does not give a mechanism by which the context of the dialog box cannot be brought forward and examined for validity. That is, with the iTunes login prompt, all you are permitted to do is to enter the password or not--but you have no way to know that it indeed is coming from iTunes.
I personally would consider fixing this user interface flaw by doing three things.
First, provide a notification mechanism which is clearly visible to the user (such as a flashing bar at the top of the screen), but which does not directly interrupt the user's interaction with the device. If, for some reason a password is necessary before the user can continue his interaction with the device, I would propose a dialog box come up with stops the user interaction with an accept/cancel button but which does not ask for information.
Second, in response to the notification mechanism, I would switch to the application that is asking for the information. (This is easier now that iOS supports multiple concurrent applications and a method for going 'back' in the upper-left corner of the screen.) This gives the user the opportunity to examine the application which is asking for the information. (If this is in response for an iTunes password prompt, I would switch to the Settings app and to the iTunes password screen within settings.)
Third, I would explicitly prohibit (either by changing the OS or through the review process) modal dialogs not belonging to an application from appearing over another application. This includes built-in OS modal dialogs.
All of this is designed to force the user to examine the context in which their sensitive information is being requested, rather than blindly handing it over. Because this sort of interaction is relatively rare, forcing the user to switch to the settings page (rather than just grabbing the password on the go) is not an unreasonable price to pay here.
Itâ(TM)s not a real attack unless you can get it onto the phone. Has an app with this dialog code made it past the app review process? Can you pop it up on safari? If so, then a simple change to that one dialog box (like making it a different color to indicate secure) will fix that. If not, then nothing to see here. Just developers playing in a sandbox justifying the app review process.
How's life in the hypocrite lane?