Impersonating iOS Password Prompts

Comments

Jeffrey Friedl • October 12, 2017 7:23 AM

I’ve long wondered about this on iOS and OSX, and thought that as part of the account-creation process they take a photo and store it securely, always showing that for system dialogs. Since only the system would have access to those pixels, you could trust any dialog that showed them as part of the prompt.

Catherine Punjani • October 12, 2017 7:27 AM

My Cousin is always in trouble. Phishing is probably just one of the ways he ‘gets his revenge’ on everyone & everything when he’s angry. It’s unfortunate that not everyone reads or Subscribes to your Website! False dialog boxes? Nothing new!

Clive Robinson • October 12, 2017 7:33 AM

Not being nasty but many users are just like Pavlov’s dogs were supppsed to be…

I’m not realy sure there is a solution for “fixing the user” or for that matter “fixing the technology”.

The thing is it’s a question of “learned trust” the user sees the same prompt each time and just does it, they don’t see where the prompt has come from. Most humans are born to trust, it’s only experience that teaches them otherwise. Thus if they do not get immediate bad feedback or obviously attributable bad feedback later, they are none the wiser.

Tatütata • October 12, 2017 8:26 AM

Yet another variation on phishing attacks.

Simulated login dialogues go back to mainframe computers, but back then it was more something of a juvenile prank than a security risk. In the same vein, it was possible on certain DEC systems to send messages from one terminal to another. With the appropriate VT52 control sequences you could provoke cussing by the user on terminal #0, by simulating the bootstrap console dialogue. That !@#!@ computer crashed again.

Deimos • October 12, 2017 8:43 AM

This question seems fundamental: How can a user be assured that a prompt for credentials can be trusted?

The PKI addresses this issue on the web. Local use of one-time passwords could mitigate the risk to a degree. But what about a prompt for a “master” password like that of an Apple keychain or a password manager? Really the only thing that a user currently has to guide them is the action that elicited the prompt, and users might have no idea what the connection between their action and the prompt is.

Can’t we do better than that?

(And don’t folks feel strange entering their Facebook or Google credentials into non-Facebook/non-Google web sites?)

Mose • October 12, 2017 10:35 AM

Microsoft solved this in the nineties with CTRL ALT DELETE. It made the combination always go to the operating system, and trained users accordingly. On iOS, the home button is sacrosanct. Make the real dialogs require a click of the home button in a future iOS version. Show the new dialog during the post-update “Hello” wizard, and hit the user at least thrice in the week following the upgrade with the new dialog.

Iggy • October 12, 2017 11:12 AM

As Heinlein said, there is no free lunch. I add no apps to my cell phones. I insist that my phone be a phone first and never a basket full of goo-gahs.

We’re trained to blindly comply. Conditioned, intimidated, and persuaded into complying, in the interest of convenience. The device and app makers learned early to sell us the illusion of sparing us troubling our pretty little heads over such things as taking the time to care for our privacy and security. Pish posh, let such dark and uncomfortable truths no longer be on our individual radar scopes, they–Apple, Google, Microsoft, Android, etc, etc–will slaughter our livestock for our dining pleasure so we need not give it a second thought.

Only… now we wear the ear tags, called the IMEI. Subdue that niggling nag in the gut, meekly comply. Dare to object, to hold back, to question and be served a quick rebuke of “look, do you want to use the phone or not?” Either or, in or out, no in between. Because now it’s gonna be very hard to pass a law that allows each individual to negotiate* the Terms of Use, better called the Terms of Disenfranchisement. In the interest of mass sales at break neck pace, Apple and Alphabet argue very successfully, we’ll put the docile on the hook with a simple “don’t agree? then don’t use, but we’ll keep your money, you keep the device.” And while the bulk of humanity stampedes to use-use-use, unless you do too, you are left in the dust of obsolescence and the Courts just blankly stare at you.

*At a minimum, build in opt-outs throughout the TOS where the buyer can at least customize their compliance.

Don’t worry about the customer–you and me–being now always wrong. No, no, we are not the customer… we are the livestock.

Brian Carnell • October 12, 2017 11:12 AM

My experience buying an iPad recently after not using one for several years was very confusing on this point.

The request to enter either a device or Apple ID creds seemed inconsistent. For example, I was surprised that after using the device for a few weeks and wanting to install a free application that the device asked me for my Apple ID.

Similarly, I’m constantly asked to approve minor changes by entering the device password, but several apps let me open non-secure FTP servers to the device with just a toggle and no request for additional authorization.

juvenile prank • October 12, 2017 11:25 AM

I remember back in 1985, the DOS 3.1 command prompt could be modified to display (for example) directory you were currently in, or date/time, etc. In a juvenile prank I enjoyed then and still enjoy reminiscing about today, I changed the prompt on our laboratory data-acquisition computer to

C:\Enter password>

just to tweak the tailfeathers of my boss (sorry, David!). Needless to say (to this audience) there was no password.

I never explored the hacking possibilities, though. My inclinations were elsewhere.

mostly harmful • October 12, 2017 11:38 AM

My passwords are my keys.

When I want to get into my house, I go the front door and get out my housekey.

When I want access to my toolbox, or a car, I walk over to where it is, and get out the appropriate key.

It is never a surprise requirement. It is a known-in-advance, sufficient and necessary, condition for access to certain resources.

I use my keys to control my environment, not the other way around. And only certain parts of it. I know I need them, only and always, in specific contexts. The time is always of my choosing: when I choose to use the resource.

The day somebody accosts me and demands my keys in a context unforeseen, not of my choosing, I know I am either being robbed, or have entered a “Papers, please” police state scenario.

In a unix terminal environment, this physical analogy seems rather apt.

The problems arise, maybe, when one begins to imagine that “pop-up windows” are appropriate places to insert keys, instead of the rectangular openings found at the top of toasters. Perhaps the very name of the widget indicates the root of the problem.

Problems “pop up”. Locks stay where they are, and await your approach.

Rick Lobrecht • October 12, 2017 11:44 AM

Windows has a good solution for this if User Access Control (UAC) is turned on (and it really should be). Any prompt for administrative credentials, or administrative privileges, is requested in a secure shell that is visually distinct from your user applications. Assuming this idea isn’t patented, something similar could be done in MacOS or iOS.

mostly harmful • October 12, 2017 11:50 AM

The problems arise, maybe, when one begins to imagine that “pop-up windows” are appropriate places to insert keys, instead of the rectangular openings found at the top of toasters.

I phrased this poorly. Do not ever insert your keys, or anything else metallic, into an electric toaster. Death or serious injury may be the result!

I only meant that “pop-up window” would be a good name for the orifice found at the top of a vertical-style toaster.

Jeremy • October 12, 2017 2:05 PM

@Deimos “And don’t folks feel strange entering their Facebook or Google credentials into non-Facebook/non-Google web sites?”

I’m…reasonably sure that you should NEVER be doing that.

If a site wants you to log in via (say) Google, it should redirect your browser to Google for the log-in process, and then Google should tell them who you are. You should NOT be entering your Google password into the original web site.

Techno • October 12, 2017 2:51 PM

In order to show me the fake password prompt, the app has to be already on my iPhone and running. The damage is done!
It’s like worrying that someone you already let in your home and is sleeping on your bed can cut your throat. D’uh!

Aph • October 12, 2017 3:50 PM

One thing that has always annoyed me about these prompts is that in addition to them coming up randomly, there is no way for me to dismiss the prompt and know where to enter the data later by following a recommended pathway.

E.g. if it’s an icloud prompt,it should say “Go to Settings::iCloud to enter the password later” or something like that.

This would also help users who use a password manager with a complex password, as it’s rare that the AppleID password would randomly be on the clipboard, and the prompts are often made when it’s not convenient to bring up a secondary device to get and retype the error-prone gobbledegook.

Mike Gualtieri • October 12, 2017 11:30 PM

It’s also trivial to create a replica of the login modal using HTML/CSS, which means the phishing vector can be initiated from a mobile browser. I posted a brief blurb yesterday after I came across the same post. Doing a little digging I found that variations of the flaw have been used in phishing scams previously. The sensible solution is to eliminate the popup modal and handle logins within the iOS settings.

EvilKiru • October 12, 2017 11:56 PM

@Mike: You can get around the browser modal dialog attack on iDevices by double-tapping the home key and killing the browser.

I’ve also seen this type of attack in Windows web browsers. It’s easily defeated if you have multiple non-mirrored monitors, which I fortunately have on all of the computers I use, because the modal attack only applies to the monitor the browser is on. So all you have to do is click on the other monitor, Ctrl+Alt+Esc and kill the browser.

Werner • October 13, 2017 1:32 AM

A few thoughts and comments, mostly expanding on ideas from previous posters:

have a reserved visual style for “official” prompts: easy to do, but
1) how to ensure users understand what to look for ?
2) how to resist the temptation of changing that style in the next release ?
3) how to prevent apps from mimicking the style ?
add a segregated UI element to indicate that it’s an “official” prompt.
That could be part of the screen, a LED, etc.
This should simplify 3) from above, maybe leave few enough choices to
eliminate 2), only leaving 1).
go one step further and outsource the dialog to an external authentication manager.
Ideally combined with an end-to-end protocol, but in a pinch going through some trusted element in the phone (as long as that element doesn’t get compromised) would work, too.
This has of course its own set of issues, e.g., that few people have such a thing in the first place.
have a “secure attention key” that enters a mode in which only that trusted part of the system can interact with the user. So when an application needs credentials, it would prompt the user to request the “official prompt” by pressing that SAK.
Drawbacks:
1) one extra interaction step,
2) modal dialog may interfere with workflow,
3) any 3rd party authentication helpers would need an explicit API (which may not be a bad thing per se),
4) application could successfully pretend that mode is active longer than it actually is.

The main problem for all this is that such requests tend to increase in number. If it’s just used for payment operations, it may be infrequent enough for users to pay attention. If it comes up for all sorts of things (e.g., to post an evaluation of an app, games nag you to create an account for saving scores, etc.), then no mechanism is safe in the long run. Even worse, the particularly strong ones that provide a clear distinction may suffer more since it may be harder to extend them to multiple levels.

In a way, this is a convergence: while things like payment are getting easier, the number of banalities that receive similar degrees of protection (“create a fully verified account and rate our whatever before we let you continue”, “register to read (something that’s public information)”, etc.) increases. Where they meet, the user gets overloaded and the phisher triumphs.

Werner

Wael • October 13, 2017 2:17 AM

I haven’t read the essay. Too tired. This is an area that secure I/O attempted to solve with various degrees of success. The main idea is to show the user a standard screen that no software component can overlay any elements on top of it. Both input and output have to be “secure”. Other enhancements were discussed somewhere in the deep bowls of this blog, e.g. look for multi-entity© authentication (different than multi factor, and can be combined with multifactor), which invalidates stolen user’ credentials: credentials are only valid if they are entered from an authenticated device. This way, a password of “123” is not as weak as it looks. Details are somewhere here..

Wael • October 13, 2017 2:34 AM

A little off topic (if you don’t “catch my drift”)

Long time ago I used a Toshiba 2SA-49 Germanim transistor for an RF oscillator ~100MHz range. I also used a Silicon 2SC-something for other things that I forgot.

So I’ll call multi-entity authentication: 2SCA! Makes a lot of sense in my current goofy state. The “2” isn’t really needed but looks more impressive. “DSCA” also works 🙂

Not a difficult puzzle! First correct solution gets a virtual $10 (+1)

D stands for ‘Dual’

ThaumaTechnician • October 13, 2017 6:50 AM

In my case, the Apple password is long and random – I need to log into my password manager to retrieve it then I can paste it into the prompt – which I almost never do.

It’s a simple problem, with a simple fix:
Never enter your password – ANYWHERE – unless you are doing something that requires the password.

More generally, don’t respond to any security/financial/personal inquiry/download/phonecall request that you did not initiate.

Mike Gualtieri • October 13, 2017 8:28 AM

@EvilKiru you bring up a good point with the home button, although I’m sure many folks would plug in their password without any additional checks. The flaw presented in the article is also defeated with a home button press since the modal is part of the app being closed.

Comments

Leave a comment Cancel reply