When the iPhone X notch was first announced I thought it would be a fantastic security UI opportunity: What if the top of the screen was only writable by the system? It would normally be black or show the time, but whenever there is a password dialog, it turns green with a security lock. This is something I've wanted on all computers for a while: fundamentally, any computer where you can get access to the whole screen's buffer means you can fake a logged out screen asking you to log in, or any other number of phishing attacks. The only way to prevent this is to have a separate secure screen buffer for a special part of the screen that the user can use to visually verify the security of an operation. The notch provided an awesome opportunity for the because: 1) it was NEW screen real estate, it wouldn't feel like you were acquiescing existing screen space for this security need and 2) it looks absolutely horrible when integrated into apps anyways, so why not use it minimally for good reason instead?
This already exists on Windows (via require Ctrl-Alt-Del) and to a lesser degree on Android (by always being able to show the action bar in fullscreen).
> This is something I've wanted on all computers for a while: fundamentally, any computer where you can get access to the whole screen's buffer means you can fake a logged out screen asking you to log in, or any other number of phishing attacks.
In Windows, I can render the whole screen, so I can put up a fake login dialog. To some extent, Windows users are used to requiring a ctrl-alt-delete before being prompted for a password, but there's no reason why I can't put up a static image of what the screen looks like during a password request. Having a portion of the screen which an application is forbidden from accessing would solve this, but the requirement for full-screen applications that want to write every user-visible pixel means that there's fundamentally no way to prevent this attack.
Ctrl-Alt-Delete on windows is a privileged hotkey that goes directly to the kernel. A phishing program can't intercept it once it has been pressed. If you know that Ctrl-Alt-Delete has been pressed, you are already privileged as the kernel and would be able to compromise a hypothetical protected screen buffer anyways.
The Windows login screen here doesn't allow you to type in the password until you press the magical keys that only the kernel can access. This significantly increases security, since any phishing program that puts up a fake static image doesn't know when to present the login dialog.
Programs can detect Ctrl alt del somehow, because RDP clients do it. But they can't intercept it.
But a phishing program can just show the enter password screen, without the ctrl alt del prompt. Few users understand the security need to press ctrl alt del. And in newer Windows, it doesn't seem to prompt unless you enable it via GP.
There are two vectors here; the one that the post was talking about is the fact that as long as an application controls the screen, they can show whatever they want -- for example, an app (or a full-screen web site) could render a pixel-perfect version of this:
And the user would say "oh, another stupid UAC prompt", enter their password, and that would be that -- UAC doesn't stop and say "press ctrl-alt-delete to enter your password". If it did, then that would significantly decrease the risk here.
They can detect it, VMWARE for example detects it as well and tells you that you should use ctrl+alt+insert.
Applications cannot fake ctrl+alt+del.
That said you can integrate with the windows login and extend it to show w/e you want I've written a client for a smart card for GINA a long long time ago.
Not initially, but just as users can be 'trained' to automatically enter in their password when they see a popup, they can eventually be trained to expect a new UI element to indicate it's secure.
Seems like in browsers, the lock icon and (for EV certs) company name in the location bar has been a plus, so there's certainly precedent for this sort of thing.
Yes indeed. I'm always a little anxious when an installer (or something) prompts me for an administrator password, and some secure channel indicating that it's really the OS that's asking for it would help to assuage my fears.
What does prevent the developer from making this new screen buffer blank/black and making the top of app's screen look exactly like that shape and style? The user won't see the difference except small top margin.
Am I missing something here? Isn't the notch already taken up by FaceID sensors/front-facing camera? It isn't really "extra screen real estate".
I do like the idea of a separate indicator for system-wide security events though. Perhaps an LED indicator although that doesn't seem very Apple-like.
I worked in dumb phone standards 12 years ago (GlobalPlatform) and it was actually in the standards to tell the user "you are in the secure zone". Well, OEMS in the western world were not really willing to implement it, funny it comes back now.
This is related to an issue called root-phishing or superuser-phishing. You can do this with the Windows admin password prompt, the MacOS prompt, or with Linux sudo, as long as you can run code from a user account or edit a single file.
alias sudo='sudo ./somethingbad; sudo'
I'm surprised you don't hear about this that often. There is no perfect solution, since any visual feedback the operating system can do to make their prompt "official-looking" is possible by an application as well, unless the operating system can display information the user would recognize that it not accessible by the application. A perfect solution on iOS is to "minimize" the application so that the home screen is shown and then show the password prompt. The user would immediately recognize the wallpaper and icons to be theirs, which are two pieces of information unavailable to the application. However, the application could still fool the user by displaying the box over the application anyway.
There are many solutions. First is requiring un-catchable keyboard shortcut to enter the password. Something like "ctrl-alt-delete" for Windows (I'm not sure if it's un-catchable, but you got an idea) or even better some unused key like pause/break. User will be trained to press this shortcut and app can't replicate it, so user won't be tricked. Second is using fingerprint. iOS should just use fingerprint always instead of asking the password (an exception is first boot or failed fingerprint). Now the case of failed fingerprint might be exploited, but I think it could be solved too. Require pressing of "home" button to acknowledge fingerprint. If fingerprint is real, OS will ignore this press. If fingerprint is fake, OS will just close an app.
Unfortunately operating system developers are not considering this attack. But they certainly can defend if they want.
I think the idea behind ctrl-alt-delete is that it generates a non-maskable interrupt that can't be hooked from user-mode. In days past, this sort of thing was called a secure attention key.
And you're right, this needs to be a default part of any login handler. Why don't we use it when logging into a Linux console? The login prompt could easily be spoofed by a user-mode program.
>The login prompt could easily be spoofed by a user-mode program.
On the VT100 terminals in the computer lab in college (back in the early 90s) someone was doing this. A shell script to harness logins, print it was unsuccessful and log out. .
There was a key at the top of the vt-100 keyboard that would reset it. The "key" part was often pried off (accidental pressing was bad), but you could still press the nub left behind.
In my misspent youth I wrote a login trojan for VAX/VMS. It circumvented the "break" key trick that you are alluding to above. I had to drop down to Bliss-32 and use the $QIO syscall but it can be done. Once I had captured the sysadmin password and logged in once to prove my achievement I never ran it again. Learned many interesting things though. My task was made easier because DEC published the source code for the OS, albeit as Microfiche. I was therefore able to study the terminal handler code and figure out how to make a trojan that perfectly emulated the regular login behavior including all its timeouts and responses to various control keys.
Oh, and the VAX-11/780 I had hacked into crashed due to a memory board fault in the minute after I had logged in with my snagged admin password. I spent the remainder of the weekend sweating that I had broken the VAX since I had no idea what had happened. I had just given myself all 32 of the VMS account privileges when it went down.
My guess would be that you did using the microfiche reader at your university or at a library. Before digitization, such devices were fairly common wherever people had a lot of text to archive.
(Aside: https://en.wikipedia.org/wiki/Microform even has a photo of a “DuKane brand microfiche reader with source code printed on the films.”. I couldn’t read enough of the text on the envelope to decide whether that is true from the photograph
The Linux console does support a secure attention key that can't be trapped and will kill any process which has /dev/console open. root can configure it with /sbin/loadkeys.
Not sure how distributions tend to configure it by default.
Altering the user's environment is a vector around security. I hadn't considered the sudo angle before, but there's a tradition of invoking binaries from their full path to mitigate the problem. So instead of sudo on its own, you would use /usr/sbin/sudo, and make sure your PATH variable never contains the current directory. Better mitigations disallow executables in users' home folders.
> I think the idea behind ctrl-alt-delete is that it generates a non-maskable interrupt that can't be hooked from user-mode.
Keyloggers can still enter the winlogon session and log all keystrokes there, they need to run as a SYSTEM service, but it's very possible to do.
I'm surprised this isn't better documented, but it's pretty much as simple as copying the token from the existing Winlogon process, adjusting the privileges appropriately and calling CreateProcessAsUser() with lpDesktop set to Winsta0\Winlogon.
True, the scenario in which ctrl+alt+del would help is one in which only a limited account had been compromised, but the SYSTEM level winlogon keylogger allows you to do things like turn local admin into network admin and it certainly doesn't require kernel mode access. I was more commenting on the requirement of kernel mode access or hijacking of special interrupts than on the usefulness in general.
You're right about CTRL-ALT-Delete, the problem is that users are terrible at remembering to do so without being prompted. I created a Windows XP phish-login box back in the day, that simply took you right to the login box without prompting for the key-combination, and nobody found it (and happily entered their credentials).
Any system that relies on humans to do the right thing is doomed to failure. Even something as trivial as hitting three keys each and every time they login; part of the problem with it is that it is so inconsistent (i.e. different Windows machines either do or do not prompt for the key-combination based on their configuration, so users have a mental model of skipping it).
So you're saying you're worried about apple pushing a malicious iOS update because they want your fingerprint?
If yes, this feels utterly nonsensical. They would be able to grab your fingerprint from the sensor anyway, whether you are actively using it or not...
Alternatively you might be spreading some weird conspiracy theory that instead of securely storing a "hash" of the fingerprint on a HSM, current touchid implementations are secretly sharing your fingerprints with Apple.
What argument? It’s utterly ridiculous that you would assume Apple to be incapable of collecting your fingerprint data simply because you didn’t enable TouchID in their software.
It's not your fingerprint that's the issue, it's the data that represents your fingerprint. If that data gets compromised then it's nigh impossible to change your fingerprint. However, I believe there are ways to make this very significantly difficult, and I believe Apple has achieved this level of difficulty by placing the fingerprint data in the secure enclave.
This was actually the idea behind using ctrl+alt+del for login. Originally MS wanted a dedicated key for this, but IBM declined (or so the story goes), so they settled for ctrl+alt+del instead.
I think this is a misunderstanding. Microsoft didn’t ask IBM something for logging users in in the DOS days. They wanted a way to reset via the keyboard. IBM provided that with Crtl-Alt-Del.
Windows didn’t use this for anything until NT in the early 90s, and it was their choice to do so. Nothing to do with IBM.
When people ask Gates about Ctrl-Alt-Del they’re obviously asking about why it was chosen for a login sequence, but I believe Gates conveniently answers a different question to make it seem like IBM had something to do with that choice.
Fingerprint (and other "bio" features like eye retina) scans come with their own problems.
For example, how do you handle compromise (I suspect fingerprint mills / printers are not ubiquitous just because there is no demand for fake fingerprints; technologically they should be easy to make). Also, do you really want a unique match every time you log in from different devices (e.g., work and home); etc., etc.
Sorry, fingerprint solution may be worse than the disease it is trying to cure.
>Something like "ctrl-alt-delete" for Windows (I'm not sure if it's un-catchable, but you got an idea) or even better some unused key like pause/break.
I think that even that is catchable (if needed), at least on old Windows XP Embedded, if you used minlogon (which happened very often) you lost ctrl+alt+del access to Task Manager, but there was a third-party service to restore the "hook":
but does it suppress the real thing? otherwise the user is going to see the (real) windows security dialog, followed by your fake one after they exited the real one.
but that requires a kernel mode component, and if you have kernel access all bets are off. for instance, you can directly patch out the login screen (which is in userspace) to steal the password for you.
Sure, but I bet that some clever folks may well "disguise" such a kernel component into (say) an update or a new install in such a way that the user is tricked as well to allow it.
No idea anyway (since the topic is on iOS) how that OS would behave and what could be the equivalent of a Ctrl+Alt+Del key sequence on a keyboardless device such as a iPhone or iPad.
Back on XP I recall C-A-D not showing the task manager on malware-infested machines. Not sure if that's changed since then (is the full-screen c-a-d in 7/8/10 related)?
That's slightly different though, in order to do this you need to have shell access on the target's computer. TFA is about displaying a password dialog from an unprivileged app or website.
The equivalent scenario with sudo would be to have a website display a mock terminal asking for sudo password, although that would be a lot harder to do inconspicuously because I don't expect terminal windows to pop out of the blue. It's also the reason why browser notify you when a page wants to go fullscreen.
I think the right solution to this problem is simply not to have privileged system UI elements drawn in a way that can be mimicked by a regular app or website. LastPass made a similar mistake: https://github.com/cxxr/lostpass
I don't have an iphone so I'm not sure what would be the right way to deal with that. AFAIK apps can draw to the entire screen surface so it sounds tricky to avoid.
Maybe the actual password dialogue could contain some kind of visual code, like the one on paper money. Then the OS could detect when a fake password input is shown to the user, just like copy machines detect it when you put a bank note in the scanner.
I don't think running a native application on a desktop is similar to running a sandboxed app on iOS. The security implication is wildly different IMO. I think a webapp is a more apt comparison.
I wrote this email to sjobs@apple.com back in 2011. Never heard back :-/
Dear Steve,
There's one thing that's always bothered me about MacOS security.
When a MacOS dialog pops up (e.g. to ask you for your password),
there'sno way to tell for sure that it's MacOS that owns the dialog. A
similar problem exists on the iPhone when I am asked for my iTunes password.
I wanted to write and suggest an easy fix, that would make the next
version of MacOS and iOS much more secure. Why not have the users set a
personal phrase, that MacOS will store and show them in every native
MacOS dialog, to prove that it's really coming from MacOS? Of course,
you'd have to prevent apps from screen-capturing that portion of the
screen for the entire time the dialog is up, and capturing the
keystrokes that are being sent to the dialog, but that shouldn't be too
much of a problem. You can do something similar for the iPhone.
I really hope this finds its way into MacOS. After MacOS X came out
I switched from the PC and haven't looked back. It's awesome.
I guess since writing that email, I would have preferred the option of taking a photo (and not storing it anywhere except here). You get used to system dialogs "looking like this" with the photo. If something is wrong, most humans pick it up easily. Only for blind users do you need the text.
With the hundreds of password dialogs that you get in iOS for various reasons, I think people would catch on pretty quickly to a new secure variant.
Yeah, some people wouldn't, but that isn't a reason to leave it with the terrible implementation they have now. This has annoyed me since forever on iOS.
It is crazy to me that this is an issue on iOS or Android, there is so much they can do to actually make it secure.
For one, on iOS, just "fading out" the app view over the users homescreen wallpaper. There is no way an app can do this, and it is a simple visual indication that the request is coming from the OS. Problem solved.
Also something I don't understand - the OS knows where the request is coming from, yet they don't show an app icon in that view? Why not?
This has been a problem for years with such simple solutions, yet nobody has touched it.
> "fading out" the app view over the users homescreen wallpaper
This is done sometimes, but has only limited success. Most users will click the "your computer is infected, click here to upgrade!" fake windows presented by webpage JS on a PC. You really think an app-fade effect will help enough to make a difference? It would help a bit, but not much.
> they don't show an app icon in that view? Why not?
Because then malicious/spammy applications would present fake alerts, which were non-badged normal popups, and add false badges. I guess you could badge everything, and push the problem onto apps whose icons look similar enough to other apps when shrunk down to whatever size your badge is. Either way, it still ends up in the same boat: probably a little bit helpful, but not much.
I'm specifically referring to iOS with the window fade. Of course the issue with it is that the user would have to notice the lack-of the effect on the fake popups (or apps trying to fake the users app icons/wallpaper)
My point is that literally anything would be better than a generic UIAlertController with a password field that exists today, I can fake one in literally ten seconds and have it be remotely triggered by a key on a server to pass through app review. Anything added would enhance security for users.
I believe GP was saying that if there were a fade, it would take you "literally eleven seconds" to fake, and users would be no more likely to nice its presence or absence than they do phishing attempts on desktop computers.
A solution is to only ask for the password when absolutely necessary. I still don't understand why I need to enter a password (or use touchID) to download a free app. Shouldn't it be enough to login when I want to buy something for the first time in-app? AFAIK that's how android handles it.
You need to enter your password when downloading a free app so that if someone finds your phone they can’t install a malicious hacking or key logging app on to your phone. Installing apps is a security risk, not just a financial issue.
If someone finds my phone, it'll be locked and they won't be able to install anything. If they can unlock the phone then it's already game over for me.
I get that prompting for an iCloud password again adds an extra step, but if someone has your unlocked phone they probably have enough (email, SMS, phone) to take over your iCloud account anyway.
> You’re using the phone and set it down, it hasn’t auto locked yet.
I'm not even security conscious, and always lock my phone before setting it down. I think it started because turning off the screen as soon as you're done saved significant battery life on the phones prior to them knowing if they were laying flat.
Easy to say when defending your point on Hacker News. We're already talking about security, and about someone with malicious intent having access to your phone. In the context of this conversation, you're already in simulated high security mental mode.
It's completely different when you're relaxed (maybe having some fun), and the person asking for your phone is someone you know.
In a relaxed social environment, you will probably not be that rude to someone you know.
And I've never given my wife a single password or passcode or PIN. But she can still use my damn phone or computer if she wants, as can my friends. Worst case scenario, I get a 55 gallon drum of lube ordered on my Amazon account.
For me, the principle is I never divulge credentials, but I trust people I know. Therefore I see no conflict with adding my wife's fingerprint to TouchID, for example. (though it's not worth the effort of re-enrolling her every time I get a new device or a new screen or reinstall from scratch, so that's long lost).
If someone has access to my unlocked phone, there are worse things they can do than installing a malicious app. First of all, apps are generally tested before they appear in the store. I don't think attackers would install an app if they can just steal the data directly.
If the data they want is a recording of your next client meeting, installing an app (possibly one that exploits a not-yet well-known bug, say a root exploit that only works from an app) might be one way to do it.
Remember [1]? Imagine an exploit not targeting safari, but somehow vulnerable via an app, a la [2].
Keyboard apps explicitly have to ask for “full access” and you need to opt-in. Also, apps can block 3rd party keyboards, not sure how many secure / banking apps do that though.
What's stopping an app from imitating the keyboard?
Fundamentally, we're talking about imbuing meaning to patterns of light on a screen. And apps can write on any part of the screen. I suspect the only way to battle this is to have a separate screen which is controllable only from the system.
And even many people will fall for password prompts in the main screen.
> What's stopping an app from imitating the keyboard?
What is the end goal of that? If you have control of the screen (aka are the foreground app), why would you need to emulate the keyboard? If you aren't the foreground app, then you aren't going to be able to render a keyboard on the screen (on iOS anyway).
Dude. Stop and think for a moment. If I am able to render anything on the screen at all, it means I’m the foreground app on iOS. I don’t need to fake being a keyboard, because I can use the real thing Apple provides. So no, I’m not saying it’s impossible if I can render anything at all, what I’m saying is that outside being the foreground app, rendering anything on screen is impossible outside very tightly controlled interfaces (like custom keyboards that this thread was about before you side tracked it).
So if you really were talking about the foreground app and not just covering now, then why does one need to make a fake keyboard!? That makes no sense at all.
For example let's say you handed your phone to your kid, they downloaded a free app, gave that app your entire contact list, and then that app spammed everyone you know? For the sake of example let's call that app LinkedIn.
There's a toggle (in Settings > App Store, iirc) to ask for auth only on non-free (as in beer) apps/IAPs.
Edit: apparently there's no toggle if you have Touch ID enabled. You have to disable it for the App Store for this to work, but I think Touch ID is fast enough anyway...
What if the phone/iPad belongs to your kid and you don't want her to be installing apps without vetting them beforehand? That's a legitimate reason to ask for prompts. Should be a setting though (if it's not already)
One solution would be for an OS to never have such a popup that requested credentials to be entered right there. Instead, the popup should just say "Visit System Settings to enter your account password to download whatever."
This would be similar to measures companies say in emails, "we never ask for your password, always visit our site directly," etc.
What’s annoying about the iTunes login is they expect you to know your password. I use a password manager, I’m not about to memorize my iTunes pass. Naturally those logins windows don’t work with password managers either.
Better solution would be not having login windows at all and make it all in the app and do a sort of oauth type flow if the system needs to share it.
The single biggest point of confusion for newcomers to iOS in my experience is the dichotomy between the iTunes password and the device pass code and internalizing which is needed when.
The iTunes password is needed so rarely these days that most people really struggle to even remember setting it.
IMO, the iTunes password should be eliminated entirely. But I have no idea how to handle the activation lock situation if no authenticated device is on hand.
> IMO, the iTunes password should be eliminated entirely.
Whoa whoa whoa - hold on there. Your ‘iTunes password’ protects purchases in the App Store and iTunes media stores, access to the iCloud website, your iCloud email, iMessages, app data such as notes and contacts, third party app data, and freaking backups of your entire device.
What exactly would you suggest Apple do to eliminate that account? You might as well say that google should eliminate their gmail passwords, or that Dropbox should eliminate the account password.
Some of those could be handled by the device password (although apple might have dug themselves a hole with touch I'd there) - the other with an one time password generator whose secret was available to trusted ios devices? For Apple services, that might even be simplified to a callback system; mail app on desktop shows a token "bushy eyebrows", ios auth app display the token "busy eyebrows" and a login/cancel prompt. The actual auth can be done in a challenge - response fashion between the service and the ios device. Another use for the Apple watch...
Lots of tools and apps require knowing passwords; my password manager just lets me press "Copy" when I open it to a particular login, and then I paste it into the iTunes prompt or elsewhere. A little extra hassle but I don't need to remember the password.
Thats what I do, but when you have a modal window like the one in the article, you cant get back to it if you hit cancel to open your password manager. I guess you could copy your password and hope it pops back up...
My personal password strategy requires that I do, in fact, have to recall from memory a small number of secure passwords (device access passwords, ssh key passwords, password manager password and one web service password (iCloud)).
My memorized password count is less than 10 and they're all long and secure (and completely different from one another). It's unfortunate that iCloud is on that list, but it's the only one that shouldn't really belong there, so I'm okay with it.
>You can do this with the Windows admin password prompt
doesn't work when UAC is enabled. Even if you were able to phish the administrator password, trying to login as the administrator using that password (such as by using runas), you'll still end up with a restricted access token. You still need to somehow click "yes" on UAC to get administrative access, which is no small feat because that prompt is on the secure desktop.
UAC came out over 10 years ago! In any case, NT is structured quite differently than the typical UNIX variants. When you log in, NT creates two access tokens for you. One with all your privileges, and one with admin rights masked out. When a process is launched it uses the non-admin one by default, even if you are the admin user.
When a thread requires admin privileges, NT will first check if your unmasked token already has those rights, in which case, it will prompt you (UAC) for permission to use the token. This is unlike traditional UNIX where the 'effective user' changes to root on a global level, not just per-thread. So you get 10 minutes (or w/e) as root to do your thing.
you might be able to work around it if RDP is enabled, by using the credentials to start a RDP session, then clicking the UAC prompt from within the RDP session. problem is, RDP isn't enabled by default, and you need admin permissions to enable it.
Which is funny because disabling UAC is one of the first things I (and many many others) have done since Windows 7 to make using Windows a little more tolerable.
I could understand disabling UAC on Vista, but I find it perfectly sensible since Win7. Also blame ancient programs which request administrator access without reason.
funny thing is, the thing that made it "sensible" since win7 also makes it insecure. if you care about security, it's prompt for everything or nothing.
I really like the solution that includes the iOS background — the os password dialogues should adopt this approach immediately. Zoom out to a view that includes springboard and your background image, and maybe include a preview of the app in a little window that the user can tap to return to the app rather than a non-contextual “cancel” button if the password prompt is related to the app context for some reason.
I've seen this at banks that do something similar (and it's probably for this reason). They include a user-selected picture at logon, so if you see the wrong picture, you know that their logon page is being spoofed.
I have no idea of the feasibility of locking down some piece of user data such that the OS can display it for privileged access, but random apps cannot, but this seems like a reasonable solution. Include some user selected word or picture in the title bar of the settings dialog so that users know its the real one.
Those pictures are indeed useless when used by banks, since they do nothing against MITM. But for the attack described in the OP they would actually be a reasonable defense, since this sort of indiscriminate low-privilege phishing can't intercept requests between the user and the system in order to determine the secret image.
I think the best way to resolve this is a hardware button that the user has to press.
So the dialog pops up and says "please press button then enter your password". User needs to press the button for the textbox to appear. This hardware button auto-closes whatever the active application if the active application is not the system dialog.
This way you have a hardware control verifying the dialog isn't a phishing attack.
Of course, attackers could mimic the dialog after the button had been pressed if it were a genuine dialog. But as long as you can train your users into only entering their password after they've pressed the button then hopefully most might realise something was amiss if requested for a password without the button press.
>A perfect solution on iOS is to "minimize" the application so that the home screen is shown and then show the password prompt.
IIRC, this is similar to what happens in Windows since Vista. When you need to input your root password, all applications are minimized and you only see a dim wallpaper and the password prompt.
Ya there are some solutions, like you can prefix a '\' before a command to make sure you are running the real command and not a alias, so in your example running:
\sudo <command>
would defeat your attack. But few are in the practice of doing that.
Because there's no point. If I'm able to manipulate your shell environment to set aliases, I can also change your search path so that \sudo picks up the program I want. And no, you can't defeat that by only running /usr/bin/sudo because there are a million other nasty things to do once an attacker has reached this level of control.
I'm sure there are plenty of tricks. I could be wrong, but I think the \ is a shell builtin thing, so I don't think creating a \sudo or the like would work. You could set the PATH and put a fake sudo in a secret directory in there that precedes the /usr/bin/sudo though, so that would be a problem.
untested, but I think you could possibly bypass it with a malicious .inputrc binding for <enter>, although making it conditional such that it only removed a leading \ could be tricky.
In Bash there might also be a way to do something cunning with a 'trap DEBUG' hook to modify the command between submission and it actually being run.
Or you could just exec into a terminal multiplexer like screen[1] to intercept & rewrite/suppress both commands and output.
Edit: It's much easier than that.
The function:
echo () { command echo "hax" $@; }
will still be called by '\echo test' (The 'command' prefix stops it becoming a forkbomb :)
[1] or maybe just hijack stdin/out FDs from the shell?
There's already something in iOS to handle this: The overlay for apple pay. It slides up from the bottom and is easily distinguishable from the app you're using. If they had something similar for the iTunes password it would work really well
> A perfect solution on iOS is to "minimize" the application so that the home screen is shown and then show the password prompt. The user would immediately recognize the wallpaper and icons to be theirs, which are two pieces of information unavailable to the application. However, the application could still fool the user by displaying the box over the application anyway.
I think you don't hear about the sudo variant because it's almost never used (though I'll be honest, I never considered impersonating sudo, going to have to add that to my bag of red team tricks).
I think impersonating UI's is pretty common though, tons of ads/malware made themselves to look like windows alerts.
There's little reason to actually impersonate sudo, IMO. Just add a malicious PAM module[1] and log the credentials entered for the real sudo (as well as password-based logon, etc.).
MacOS with the new TouchID is pretty bad on this as well. I thought all user password prompts would be replaced with Touch ID but it's very much hit and miss and varies greatly.
Back in the day, we used to train operators to use 'type sudo' before every use of the sudo command, to be sure they weren't surreptitiously using an alias ..
One solution that seems obvious to me is - the OS itself can detect fake popups such as this. It can even be a fast neural net that checks the screen, say, once a second.
It must be an image comparison, and it's can be a simple 1-to-1, because all it takes is one modified pixel to break that. That's why it has to be some sort of an image recognition technology.
For a while iOS would just seemingly randomly ask me to enter my icloud password. I’m so used to this that without reading this article I would have literally fall for this every single time.
I have a joke with my family that I am forced to enter iTunes password on at least one iOS device - daily. We share one iTunes account, and when you enter the password on one device, all the others prompt for a password when unlocked. It's mildly frustrating when you have kids, and multiple iOS devices.
The scenario goes like this: One of my kids' Messages app stops working (thanks Apple!). I am forced to turn off/on Messages, and during the process Apple asks for my password. Then, when I attempt to use my other iOS devices, I am prompted for the same password ... on ... every ... device. Then, about 20% of the time the password does not "take" and I am forced to ignore and attempt at a later time.
I'm sure there is a better way, but it would probably require a "weekends worth" of time to convert my entire iOS empire. When we started with Apple, "family sharing" and "ask to buy" wasn't a thing (so I'm not locked into the shared model) but I will definitely check it out - I didn't know I could create an Apple ID for my child AND share apps among all family members.
I set up Family Sharing this weekend and you are correct for a family of five it is like a half day effort including figuring out unique usernames, being asked to use the same secret questions and then fixing the settings on each iOS device. If you have a toddler hanging on you and a curious 9 old, it is exhausting. Still it seems worth it as with each iOS update iMessages is re-enabled, which would lead to embarrassment if my vigilance wavers. Also, I like the idea of the kids having their own iCloud sync/backups.
There's one annoying omission from family sharing: no IAP are included. And almost every kids game has one. Not talking freemium but just ones with one free level that gets kids hooked.
I believe that is set by the app creator so that users wouldn't try to load the same subscription under multiple accounts. I'm speaking of the general app purchases, and family subscriptions we haven't had an issue with.
Family Sharing has its own annoying issues. A spent one entire Saturday trying to work through everything just so my son could way Frozen on his iPad. This was the most frustrating experience I've had in a long time. You'd think it would be easy, but it wasn't.
In the end, I just let him watch it on my device and he was happy. Myself? I'm of the opinion that whoever design Apple Family Sharing should be ashamed. It's a horribly convoluted system that was either a) never tested by a real family (or they were completely ignored) or b) designed to be horrible on purpose.
The Apple's way of implementing authentication into the various services caused me a lot of frustration. All this constant password reassurances combined with the necessity of complex passwords that is difficult to type in on an iOS device and the previously very persistent enforcement of constant user agreement updates made me use the least possible services.
It was far from a pleasant user experience.
I might have missed several things, interestingly looking non-essential programs or cool iCloud features that I gave up to avoid these annoyances, but that is it now. I will never know.
It is still enough to 'click' those remaining stupid messages away that block you from using the device, like click away warning about the accuracy of local positioning when I want to make a photo on a situation that goes away in 3 seconds (so eventually no point of warning me about metadata of a photo not happening), it is absolutely wrong obstructing the user more, repeatedly, in using its device.
I guess I accepted not to use the iPhone that much as its potentials would allow. I don't trust it (firstly just about its usability, now about its security as well).
I’m not sure if something is screwed up with your account or your devices or what, but I do t have that wacky experience amongst all my devices that share an account (~7-8 of them).
I agree, the ongoing and erratic basis that my devices ask me to sign in to iCloud is a serious flaw. I already find iCloud a completely opaque mess of services that I don't understand, and this doesn't help. The only saving grace is that cancelling out of these requests usually has no obvious downside.
I had the same issue, but I was so paranoid that I would always cancel out and not put in my password. I'm 95% sure it was legit, but randomly asking my password for seemingly no reason made me paranoid.
Yeah, If i get a password prompt and I didn't do anything to "initiate" it, then i'm not typing my password in. I've never had anything fail using this behavior so I feel I'm safe.
"feel" being the operative word here - am I safer? Who knows?
I've experienced this as well. I seem to be able to just cancel out of it but I'd like to know what's triggering it. It would be nice if the password box had some text to explain the context of the request.
So why does iCloud(?) randomly ask for credentials?
Me too. For a while it was truly awful on my Mac as well, constantly requiring a login. Signing out from all my devices and logging in again finally put it to bed, but it's seriously concerning when you consider how much sensitive info is carried by iCloud.
Once an OS trains it’s users to enter their password without thinking about it, because of random (seeming) password prompts, they’re already fucked. Apple screwed this up on iOS years ago.
This is the key here; immunity to phishing is something you have to fight for. Even if Apply changes to no longer prompt like this, or to make the "official" prompt significantly different, the damage has already been done. 75.3% of users will see the "old-fashioned" prompt and just assume it's kosher because some subcomponent hasn't updated or something and that's game over.
It was a mistake to ever have these prompts -- the most they should have said is "go to the settings app and re-enter this information" or something similar. Now we're stuck relying on Apple's App Store screening to shield people from this vector. I'll continue my policy of always ignoring these popups, so hopefully I'll be safe.
Yup. And if you develop apps and test in-app purchases in their iTunes sandbox, you will get these CONSTANTLY. Like, every time you change what network your device is connected to.
Yes. I hate testing in-app purchases, I will never do it on a device I actually use because it becomes a nightmare, especially if it is a recurring subscription. Endless password prompts.
In fairness, this isn't unique to Apple devices. Most people I know turn off Windows UAC controls for exactly this reason. I'm sure the same is true of Android or any other devices too.
I think OAuth and single sign on is great but I always thought OAuth had a similar issue to this. You're on a random website, you click to login via e.g. Google and then enter your Google password into the login dialog that appears. It's asking wayyy too much from regular users to be able to tell if this is safe or not. I'm really surprised there haven't been more phishing attempts where a fake login is shown which saves your password.
It's an even worse issue in e.g. Android apps that use Google or Facebook for logins as you can't tell what domain is serving the login prompt like you can in a desktop browser.
One uses the normal OAuth flow and mis-represents a valid application identity in order to get the user to grant permissions normally. The other flow, that the grandparent refers to, redirects users to a phishing domain and steals credentials.
I'm almost ok in a web browser, at least there is a reasonable way of being 80% sure it's safe, but the webview version is my pet peeve... not even a power user could be able to tell...
> I'm almost ok in a web browser, at least there is a reasonable way of being 80% sure it's safe, but the webview version is my pet peeve
I use a password manager on desktop so when it fills in the password for me I'm confident I'm safe. Asking regular users to be sure a real browser pop-up is being shown and the expected domain is shown is asking too much though in my opinion.
I constantly have to verify my iCloud password, despite having 2FA and Touch ID enabled. At least once a week on at least one of my three iOS devices. It's such a constant chore I would probably fall for this phishing attack.
I believe it is because my email address is a relatively common firstname@gmail.com, and people are trying to recover or guess the password. Perhaps there's some misguided attempt on Apple's side to increase the security if there's lots of failed attempts. I also get constant Facebook recovery attempts (at least they have a "Didn't request this change?" link), mortgage emails, bills, appointments, intra-family email threads, etc. I don't think they're malicious, tons of people are just fundamentally unable to type their email address correctly into a field.
Why not ask users to set a unique phrase to identify themselves when you set up the OS? If this phrase isn't in the box that asks for a master password, you know it's phishing. Hell, just put that IN the copy on the master password box.
"If the words below do not match your unique phrase, do not enter your password."
If I see "Green eggs and ham", I know it's safe to put in my password.
Yahoo used that, except with an image, not a phrase. And then one day yahoo.com didn't show that image anymore.
What do I do then, as a user?
At this time, I didn't care much about my yahoo account, so I simply didn't log in anymore; but in general, this solution leaves the user alone. You need to give them a potential remedy when that happens.
Huh? How? Those users would be entering in their passwords in the dialogs today.
Adding a visual indication of a secure dialog can at least help the power users, while not changing anything for the ones that don't know the difference.
EDIT: Oh sorry, I seen what you are saying now - entering password into the phrase field. Instead, just make it an image that the user selects, or even creates.
"You didn't notice one of the dozen popups asking for credentials lacked your magical hidden phase YOUR FAULT!"
If Apple were going to explore a strategy to fix this, they would likely be better off redirecting the user out of the app before asking for credentials, or prompting them in notifications/home screen only.
Even better, add an indicator light to the hardware that shows the OS is asking and not an app (although this suffers from the same problem that users need to notice something is absent).
Perhaps when you put your finger on the home button it would read your fingerprint and authenticate you like that and the user wouldn't have to enter their password into a box that might steal it..
I can spend thousands using just my fingerprint, but authorising my Apple ID so I can buy a 99p app or login into iMessage requires my Apple ID password...
To the author: the double quote characters in your phishing dialog are straight ASCII " but the quotes in the official dialog are Unicode open/close double quote characters.
There are so many random popups in iOS to authenticate to itunes, app store, facetime, icloud, etc that I am amazed widespread phishing strategies don't already target them
Yes. This is the most horrible UX I have ever seen, especially from a company as security-sensitive as Apple is. In my experience, none of the mitigations given by the article are actually helping in some of the cases:
> Hit the home button, and see if the app quits:
if the prompt was caused by some in-app purchase related framework having to re-check something, then the app will quit and the prompt will go away.
> Don't enter your credentials into a popup, instead, dismiss it, and open the Settings app manually
if the prompt was related to that in-app purchase, the prompt will not re-appear inside of the Settings app. If it's because of something else (no idea what - nothing tells you), then it's still asynchronous and might or might not appear after a random delay.
Anyways. Overall, Apple is slowly getting better at this, reducing the amount of magic prompts, though during the beta period and after updates, it might still happen here and then.
Apple, if you're listening: You need to fix this. Centralise this in Settings and prompt users to go there. And do everything in your power to not having to re-prompt the user.
Every time I'm seeing this prompt, I'm wondering where I'm being phished or not, especially the really bad one that's not listing the Apple ID (my apple-id is using an apple id specific email address I'm not using anywhere else, so if I'm seeing the address, it's very, very likely legit).
> But, but, but, why is the . symbol within the ", is this all fake?
Fun fact for those who (like me) didn't know for a long time... technically "gmail.com." is actually the domain name for Gmail. It's called the fully qualified domain name (FQDN), akin to an absolute domain name (as opposed to relative to the current subnet).
Indeed, and I was not trying to suggest the punctuation was due to them intentionally trying to write an FQDN. I was just mentioning a fun fact that the notation reminded me of.
> Do you have a source for this? I've not heard this before. The Wikipedia article on FQDN doesn't mention it.
Actually it's right there in the Wikipedia article [1]...
The DNS root is unnamed, expressed as the empty label terminated by the dot. This is most notable in DNS zone files in which a fully qualified domain name must be specified with a trailing dot. For example, somehost.example.com. explicitly specifies an absolute domain name that ends with the empty top level domain label.
This is also an issue with in app web browsers. AFAIK an in app broswer's data can one way or another be completely accessed by the app containing the browser.
as an example, Tinder requires Facebook login. To do this it launches a WebView. it could be faking that view to get your Facebook credientials. it could also just get them direct from the WebView .
I know tons of apps depend on WebViews but I kind of wish there was a solution . maybe Apple only allowing the WebView to access certain domains and no 3rd party domains and then requiring the app to actually launch safari not use a WebView. Of course I suppose that doesn't help as the app can still display a fake Facebook login.
Facebook changed their SDK login behaviour to open the Facebook app, or Safari if it's not installed. If you see an in-app webview login for Facebook, you are being phished. However, 99% of users wouldn't know to check for this.
Dialogs owned by the OS should probably pull the drawer down and display in there. The simplest way is not allowing the application to access some sacred part of the UI, and putting system stuff there. Same thing web browsers do.
A phishing dialog could fake the drawer. Apps can and do regularly use the full screen which is something web pages don't do and which will require extra user confirmation for precisely this reason.
Denying apps full screen access is very detrimental to the overall UX so that's not going to happen.
The other solution is to have apple never prompt for that password aside of during the initial setup process after installing an update.
Then you could at least give the advice to never enter your Apple ID-Password anywhere unless you've just re-installed the OS.
There are other visual solutions: show the app switcher, or go to the home screen and return when the modal is dismissed. I agree apps can fake some things, but it's not an unsolvable problem.
Show the app switcher is a good idea. It could make sense visually and would have information that the phishing app couldn't get (the surfaces of other apps).
I guess lucky for me I always enter my password in the Settings app directly, because I don’t know my password and the iPhone won’t let me go to a password manager when it gives me this popup without warning.
Only password outside of my password manager is the Apple one. Exactly because I need it so often that it would be really big issue for me if I have to loose 30 seconds every time I want to enter it.
Isn't this one of the oldest tricks in the book? the following story is completely made up...
When I was in college me and a friend re-made the win2000 login sequence in visual basic to play pranks on people. After typing username and password it pretended to load and then just quit itself so the desktop would show so it looked like everything was fine. We'd then go in and do the classic "take a screenshot of your desktop, set it as you wallpaper and hide the icons".
Could apple just make a dialog style unique to OS level prompts? not foolproof, but you can't customise os blocking dialogs from apps so you couldn't replicate the behaviour if you tried to fake it.
If you had enough access to run your Visual Basic program, didn't you already have enough access to change the wallpaper and hide the icons even without the victim's password?
We logged into the machine, ran the app, leave the computer, person A would go up and "log in", except everything wouldn't be right as it's not their account, so they just logged out and back in for real. All of the details were saved on the schools networks drive for later shenanigans like the wallpaper stuff. It was very basic.
That assumes that a phisher would use the system API for creating a prompt. It's possible for them to draw a dialog that looks just like the system dialog on top of the regular application chrome. Once Apple has trained a user that it is ever okay to type this information in, the cat is really out of the bag.
Shouldn't this type of password be stored in the devices keychain, which can be unlocked with the device's auth mechanism, and provides authentication services without exposing the itunes password to app developers? That is, authenticate user on device -> verify recipient of auth info -> send auth message.
I must be missing something since no-one seems to be suggesting this.
Android already has a decent fix for this. When a Google app needs a password entered, it shows a notification. An example I run into is when Chrome wants its Sync Passphrase. I remember long ago seeing something similar when I changed my account password, but I haven't seen it recently so I don't know if they're still doing it.
At least with TouchID I think I've stopped having to ever type my iCloud password into random popups anymore.
I'm sure there are still corner cases where it would want the literal iCloud password but I don't remember the last time I saw the prompt, versus before TouchID the random password prompts were pervasive and discomforting.
As the author notes, the App Store provides a measure of defense against this. Apps that do this might get away with it at first but will eventually be discovered and banned.
Plus 2FA also protects you from this. iOS has easy-to-use 2FA and is on a good trajectory of mainstreaming it and driving adoption. I'm not sure his proposal for defeating 2FA would work:
> even with 2FA enabled accounts, what if the app asked you for your 2 step code? Most users would gladly request a 2FA-token and ask for it, and directly pipe it over to a remote server.
I wouldn't give this much credence without a proof of concept. iOS throws up a dialog when there's a pending 2FA request which consumes the code or cancels the request, so that would prevent the app UI from intercepting it.
I'm not sure how sophisticated the App Store review process is now, but it would be quite easy to grep the codebase for any UIAlertView with the word "password" or "sign in" inside it (unless it did some sort of real-time decrypting of that message).
Regardless, iOS should have a private alert view for inputting sensitive data, similar to the Touch ID prompt. If the prompt is not even relevant to the app container, it should also completely minimize the app view to prevent confusion.
The only safe solution is for the popup to have a "Settings" button. Anything else can be faked rather easily due to the fullscreen nature of iOS. Given enough time and dedication, any overlay or "feel safe" icon can be faked.
They can do review-time checks of system calls that show the popup. Look for keywords in the dialog ("password", "account", "ID" etc). At runtime, check if a password entered in a dialog matches the user's Apple account password. Suspend or remove suspicious apps from the Appstore and advise the affected users.
Have you been able to get in touch with Apple about this or were you told to just submit a radar? Do you have any sense if this is something Apple might fix sooner now that it's getting some exposure?
The real problem is that apps can get data off your device too easily. An app that phishes your password isn't actually dangerous until it uploads it to a server somewhere.
Apple should provide an API that limits an app's internet access in severe ways, preventing encryption, large uploads, etc. Unrestricted internet access should be a permission that few apps are granted.
Apps would still find clever ways to exfiltrate data but that itself would be something you could look for. Today, any app that has access to your data can upload it to anywhere without suspicion.
Making apps request internet access privileges seems like a viable idea. Don't limit encryption though - that's the opposite direction from where we want to be. It is more important to secure the connections to our devices.
You could do TLS for the app, no need for the app to do encryption itself, is what I meant. That way it's easy to inspect/restrict the data the app is capable of sending out.
This is not a new problem, and the GlobalPlatform TEE trusted UI goes a long way to address such a problem.
Though Apple does not officially support the GP TEE, the concept could be borrowed. Trusted code running inside the secure enclave combined with a hardware backed indicator for trusted user interactions driven by code in the secure enclave can help.
This is pretty much how their fingerprint sensor data is protected, via direct connection to, and control from the secure enclave so that none of the fingerprint data enters a non-secure zone.
krausefx: the warrior dev who unleashed his weapons on evils iOS app signing and app store submission processes, now trains his guns on iOS privacy gotchas :)
Thanks Felix for these works! Hopefully your work on pointing these issues get the necessary attention from Apple soon!
I have hated those alerts for iTunes passwords so much, and always entered password from Settings app. But never realized what a security nightmare it can be for those who are not iOS/Devs.
I remember seeing a research group that was working on creating an out of band password prompt for desktop computers at NC State. Basically the OS had a syscall to pause everything the kennel included and a separate module would basically dim the screen and show the password prompt over what was currently on the screen. I forget the exact details but it was neat.
I honestly don't remember which OS they used, but not this wasn't something built into any existing OS already. The point was that the code that displayed the password prompt was outside of the kernel and kernel control entirely. The UI wasn't the important part, it was that the OS never got access to the password in the first place.
I imagine if you had a password prompt LED on your device that could only be lit up by the separate chip that does password prompts, that would help create an off screen UI.
Can anyone parse this sentence? I have no idea what it's trying to say:
Nope, actually, that's how the system dialog looks like, the . is within the "string notation, so I designed the phishing dialog to also include this little, but very important design detail
He's saying on native dialogues, when it lists your Apple ID email address, it includes a full stop at the end. The address and the full stop both happen to be in double quotation marks. Many phishers would place the full stop after the quotation marks, or omit it entirely.
If you look at the dialog, there is a '.' (period) at the end of the email address, inside the quotation ("). The author replicated this, even though it seems strange.
OAuth, 2FA, a control panel to manage OAuth tokens, and decent app policies fix this problem. A user should never have to enter their password other than the first time they're setting up their phone. Very preventable.
I remember having the same idea, but I always thought the password dialog is distinct from any other dialog available to the app developers. Guess now it all looks the same :P
All apps have always had complete freedom to draw their UI in any way they want. Look and feel is completely up to the developer. There's nothing "special" about the design of system dialogs themselves, it's all just pixels.
I see your point, but it is a little bit misleading to say developers have complete freedom to draw their UI any way they want. You can still have an app rejected on UI grounds during review. Make an app with a crappy enough UI and it can be rejected citing the "Substandard User Interface" rule in the App Store guidelines. What constitutes the meaning of "Substandard" is of course whatever Apple wants it to be.
AFAIK there is no way to obtain the apple id being used, as it would work as an excellent cross-device persistent identifier. However many people would just use their email address which you could get asking them to register, connecting with facebook and other legitimate use cases.
Not sure how feasible this is, but the OS could detect when you've typed your password into a non-system prompt and present a warning or block of some sort.
I think the bigger safety against this isn't that Apple reviews apps, but that submitting an app to the store requires money up front and some way for Apple to identify the person behind the account. It's by no means foolproof, but I imagine it redirects a lot of bad actors to easier attacks.
In my opinion less annoying than the iOS password popup. I think in one OS they appeared very often (Win 7?) but by now I only see them if I want to execute as admin. And I'm glad how they're designed, it's hard to accidentally click on them.
Apple does have one mitigation I’m surprised not to see listed. The keyboard changes color when it’s a system dialog asking for your password. That’s not something an App can do to my knowledge, but I could be wrong. Any idea why it wasn’t mentioned?
Yes, I know about UIKeyboardAppearance and how apps can influence that, this isn't what I am talking about. When I say "system password" dialog, I am talking specifically about requests for my iCloud/iTunes/phone password. Unfortunately I can't seem to trigger it now, but I distinctly remember in the past the keyboard looked slightly different than the dark keyboard theme. Maybe I am wrong!
This is just a part of ios. There's a light keyboard and a dark keyboard, and apps can request to use the dark one. The reddit app, for instance, requests the dark keyboard when you're in "night mode."
I’m using the stock Apple keyboard (used to use alternatives, but not anymore) and as mentioned the keyboard significantly darkens it’s grey when it’s asking for a system password.
