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 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 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.
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.
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.
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.
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).
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 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'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.
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.
>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.
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.
> 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.
>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
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.
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.
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).
>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.
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.
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.
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.
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)?
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.
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.
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...
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.
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.
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.
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).
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.
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].
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.
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.
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.
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.).
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.
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.
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.
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.
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.
>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.
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.
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.
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.
> 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.
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.
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.
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
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.
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?
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 ..
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.
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.
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.
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).
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.
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.
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.
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.
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).
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.
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).
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.
> 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).
> 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.
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.
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.
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.
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?
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.
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.
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!
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.
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."
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.
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...
324 comments
[ 4.2 ms ] story [ 119 ms ] thread"feel" being the operative word here - am I safer? Who knows?
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.
/rant
For those interested: https://support.apple.com/en-us/HT201084
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.
We ended up turning it off because sharing apps wasn't worth the "Hey, can you buy this app for me?" coordination.
And then there was all manner of nonsense after we turned it off, too.
I assume there are other weird bugs in family sharing.
So why does iCloud(?) randomly ask for credentials?
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.
Blog post with screenshots: http://enigma0x3.net/2015/01/21/phishing-for-credentials-if-...
There's probably some browser based equivalent somewhere too.
Unfortunately operating system developers are not considering this attack. But they certainly can defend if they want.
https://en.wikipedia.org/wiki/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.
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.
That makes their threat a moot point...
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.
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.
Wait.... What?
Nice job decoding that.
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
30 or so years later I bought a huge stack of DEC microfiche on eBay so I could still do it if I wanted. I don't have equipment to read it though.
Depending on configuration, this can be prevented with noexec mount, selinux or SMACK. Grsecurity and RSBAC can prevent unwanted exec.
Systems like apparmor, or grsecurity MAC, TOMOYO or YAMA do not work against executing wrong executables.
IMA (signing and verifying files) can work too.
All bets are off in case there is a local root exploit in kernel or any setuid app.
Not sure how distributions tend to configure it by default.
If you want to test it then this will set Ctrl-Alt-Esc as your SAK:
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).
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":
http://www.mp3car.com/forum/mp3car-technical-software/softwa...
Anyway there are other ways, here is one:
http://www.oblita.com/interception.html
about midpage there is a sample to "intercept and block" the sequence.
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.
Some of us don't want to use TouchID so, no, it shouldn't.
If your fingerprint gets compromised, you CANT change your finger (erm... probably. I dunno of any easy way in any case)
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.
That's not really any less nonsensical.
Do you just not use the home button?
Biometrics have value for identity verification (username) when used in conjunction with a password
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.
If you have access to the hardware, that's a whole different attack vector.
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.
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...
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 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).
to avoid the OS restrictions on which keyboard app is used for passwords.
> you aren't going to be able to render a keyboard on the screen (on iOS anyway).
Are you saying it is impossible to render the pixels and accept screen touches in a way that it acts and looks like a "real" keyboard app?
It's not a sidetrack, because that's what the actual article is about.
I didn't have a specific scenario in mind.
But to address your question ...
Say a user is reassured because he knows that only approved keyboard apps can accept passwords.
This malware app pops up a password prompt AND some images and input buttons that looks very much like a 'proper' keyboard.
The user enters his password.
Game over.
“Does your phone have a calculator? Mine’s in my bag and I need to add these values real quick.”
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.
If I ever get a job in that sphere, I'll let you know.
Perhaps I might phrase it slightly differently depending on who it was but the sentiment would be exactly the same[1] - a blanket refusal.
[1] Nowadays - back when I was on the Nokias or SE phones, sure, use my phone as a calculator, go nuts.
No one has touched my phone while it was unlocked since middle school.
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).
They have your lock screen password but not your iTunes password.
You thought they were a friend and let them borrow your unlocked phone.
Even for a security conscience person there are plenty of situations where someone could get your unlocked phone.
And most people aren’t security conscience. It’s to protect them, not you.
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.
Remember [1]? Imagine an exploit not targeting safari, but somehow vulnerable via an app, a la [2].
[1] https://citizenlab.ca/2016/08/million-dollar-dissident-iphon...
[2] http://iphone.appleinsider.com/articles/16/08/29/apple-brief...
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.
It’s bad that LinkedIn has such a reputation that I automatically assume they likely did just as you alluded that they might’ve done.
They were pioneers in the field!
Maybe Apple should require authentication to grant those permissions.... Of course, then we're back to the problem of password fatigue.
This would be similar to measures companies say in emails, "we never ask for your password, always visit our site directly," etc.
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 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.
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.
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.
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.
Sincerely, Greg ...
Although I’m skeptical that users will really be alerted by the absence of a thing. The users I work with wouldn’t. But I would prefer it.
The inability to use the home button on the dialogues has become second nature to me out of healthy distrust/ paranoia.
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.
[1] e.g. https://github.com/ONsec-Lab/scripts/tree/master/pam_steal
If you can write to pam.d/common-auth - you might be able to add a kernel module, or change boot to start the whole os install in a vm...
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.
But I suppose any application can write to the current user's .bashrc file right? Then it can also set the alias whenever the user opens a terminal.
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.
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.
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.
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.
https://blogs.msdn.microsoft.com/oldnewthing/20160816-00/?p=...
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.
Isn't it exactly what happens on windows anyway?
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.
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.
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.
Still might fool some users who aren't paying attention but seems like it would be a simple start.
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.
If the attacker was able to backdoor the system, isn't also possible they could install a modified shell that no-ops \?
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.
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:
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?
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.
watch.user: https://github.com/KrauseFx/watch.user
> 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).
You must lead a very sheltered existence then ;-)
Enjoy your bank logins https://twitter.com/lukew/status/908729507086950400
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.
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.
"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.
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.
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.
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.
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.
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).
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.
[1] https://en.wikipedia.org/wiki/Fully_qualified_domain_name#Sy...
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.
So I don't remember weird, unexpected password prompts, but I just changed my password anyway.
The advice on recognizing legitimate popups is pretty good.
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.
1) Have there in fact been any known phishing attacks in Apple's App Store using this method?
2) Wouldn't Apple's app review usually notice something like this before allowing it into the store?
no attacks are known. But that doesn't mean a thing. It's very easy to do this, so you'd have to assume that it is being done.
> 2) Wouldn't Apple's app review usually notice something like this before allowing it into the store?
no. As the article says, this kind of functionality is incredibly easy to hide.
What does Apple review when approving apps?
System security related prompts have worked essentually as you describe on Windows since 2001.
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.
Not that a user should have to know "only enter your password into the black keyboard", which can also be faked mind.
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.
Perhaps in a future Apple can make you press the home button as part of the verification, so it’s kind of implicit.
I think this is the best solution so far!
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...