Hacker News Reader

Comment by vbezhenar | Hacker News Reader

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.

View on HN

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.

  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)

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.

Reply on news.ycombinator.com