> 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.
(Of course, no question that for us hackers this would be a very useful improvement!)
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.
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.
alias sudo='sudo ./somethingbad; sudo'
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.
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).
Some of us don't want to use TouchID so, no, it shouldn't.
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.
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...
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.
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.
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.
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.
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...
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.
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 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.
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.
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.
\sudo <command>
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.
If the attacker was able to backdoor the system, isn't also possible they could install a modified shell that no-ops \?
Isn't it exactly what happens on windows anyway?
[1] e.g. https://github.com/ONsec-Lab/scripts/tree/master/pam_steal
Still might fool some users who aren't paying attention but seems like it would be a simple start.
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
"feel" being the operative word here - am I safer? Who knows?
So why does iCloud(?) randomly ask for credentials?
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.
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 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 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.
"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.
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.
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...
> 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
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).
As a German (we don't do this), I also didn't like that when I saw it the first time.
[1] http://www.thepunctuationguide.com/british-versus-american-s...
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...
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.
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.
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.
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.
watch.user: https://github.com/KrauseFx/watch.user
I must be missing something since no-one seems to be suggesting this.
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.
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.
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.
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.
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.
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.
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.
It highlights the same exact security issue. The solution is simple: only ask for passwords in the SETTINGS app. Have the alert route users there.
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.
https://medium.com/@jakemor/how-someone-can-steal-your-iclou...
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
legit -> "bill@apple.com." not-legit -> "bill@apple.com"
But you're right, it's a terrifically difficult sentence to read.
`"email@email.com."` <- note the trailing period inside the quotation markers.
He's saying he knows it looks weird, but you have to get that detail right to look exactly like the system dialog
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.
One way to get the email:
At the start of the phishing app, ask the user to enter in their AppleID, then store it.
Sometime later, present the user asking for their AppleID password.
/s
Apple really pushes you to do this in iCloud. For the better.
I don’t get how this is an iOS problem, he basically just taught you what phishing is and happened to use iOS as the example...
