How would you know which packets were transmitted as a result of user keystrokes and which were transmitted as a result of unrelated network activity ?
The NetCAT is out of the bag: Intel chipset exploited to sniff SSH passwords as they're typed over the network
It is possible to discern someone's SSH password as they type it into a terminal over the network by exploiting an interesting side-channel vulnerability in Intel's networking technology, say infosec gurus. In short, a well-positioned eavesdropper can connect to a server powered by one of Intel's vulnerable chipsets, and …
COMMENTS
-
-
Tuesday 10th September 2019 17:16 GMT Anonymous Coward
Ports, protocols and clients. I honestly don't know how it works, but considering you know where to look and when (at the initiation), it can't be crazy hard to figure it out. Now getting to the point of all that is another story. You can be the Johnny Bench of catching data, but you still have to get on the field.
-
Tuesday 10th September 2019 17:28 GMT Brian Miller
Wireshark is my shell...
OK, the way that it works is that first of all you have to monitor ALL of the traffic from the server. That's the first (unlikely) step.
The SSH connection will go through some connection packets, trying some authentication schemes first, and finally fall back to waiting on client-side user input. The user input is sent one character in a packet at a time to the other server, so it's easy to spot. Then there comes a big blast from the server, with your message-of-the-day, etc. And then the user types a command, etc. So yeah, the password is easy to spot. And you will know the timing of the user's key stokes.
What the researchers are getting at is because the network card is so efficient, it's like they are monitoring the sound of the keystrokes on the user's own keyboard. And then you are screwed just based on the timing of your typing.
So be spastic. Make mistakes. Pause ... like William Shatner for ... no apparent ... reason.
-
-
-
Sunday 15th September 2019 17:22 GMT dajames
Re: Wireshark is my shell...
Or use more than one fnger to type the password.
Upvoted because you made me smile ... but actually I would have thought that good touch typists would give away more information more easily to this kind of side-channel timing attack because their typing rhythm will be more predictable.
-
-
-
Tuesday 10th September 2019 18:48 GMT John 104
Re: Wireshark is my shell...
They aren't monitoring sound....
They are deducing the timing between key strokes to figure out a character. The human finger takes x amount of time to travel between keys. Using this information is how the make the assumption on key stroke.
The application for this vulnerability is interesting to me. The system is already compromised at this point, so data theft or corruption is not the name of the game. With this method, it isn't obvious that the system was hacked and a user being proxied. No, the deed is done with valid credentials, making the forensic portion of this difficult for the defendant. A haxxor could use this to steal credentials, do nefarious deeds, and have it pinned on the jacked user. Want to get an executive at a rival company fired for watching kiddie porn? These sort of events affect a companies standing on the stock market (I still don't know why). You could buy low or promote your own rival company as better, etc.
-
Wednesday 11th September 2019 06:28 GMT TheMeerkat
Re: Wireshark is my shell...
How would you associate key pressed with timing? It differs from person to person, so you need to calibrate it against know I put from the person. And, most importantly, when we type password, something that we type every day multiple times, the timing would be different from normal text.
-
Wednesday 11th September 2019 07:37 GMT Charles 9
Re: Wireshark is my shell...
Physics. Most people develop a certain style of typing that can be easy to pick out. Plus, most of us are trained in touch-typing which involves certain layouts of both the fingers and keys. Because of the movements involved, it's a lot faster to press an F or a J compared to say a Q or a P. That's where the pattern recognition starts.
-
Wednesday 11th September 2019 08:27 GMT Gonzo wizard
"most of us are trained in touch-typing"
Granted that secretarial staff are trained to touch type, and that I've met the odd person who has chosen to do this training... in thirty years of software engineering and eight years of mainly pairing I've seen no evidence that even a visible minority of IT people have been trained in touch typing. Excluding IT and secretaries that minority will be all but invisible.
-
Wednesday 11th September 2019 10:09 GMT Anonymous Coward
Re: "most of us are trained in touch-typing"
Agreed. I can type as fast, if not faster, than a trained touch typist (approx 90wpm, not world beating I know, but fast nonetheless)...but I don't use typical touch typing technique. My hands are all over the place...trying to work out my typing pattern would be hard, because I don't actually have one...especially if I'm at a desk with two keyboards where I generally type one handed.
-
-
-
-
-
-
Tuesday 10th September 2019 17:21 GMT Brian Miller
Local access and you get ever so much!
So first, the attacker has to monitor all of the server's traffic, like be on a hub or a switch with port mirroring. Then the attacker floods the fsck out of the network card. Then the user sits down and types their password. And then timing analysis dictates decipherment of the characters.
Let's see, the last time I typed in a SSH password was to access my Raspberry Pi toys on my local network.
Yeah, sure, it's a vulnerability, and it can be "corrected" in the SSH client, or by being kind of spastic on the keyboard. I wonder if their timing analysis takes all of the backspacing for mistakes into account.
-
Tuesday 10th September 2019 20:26 GMT Graham Cobb
Re: Local access and you get ever so much!
No, they don't monitor the server's traffic, that is the whole point. If they could monitor the server's traffic they could see the pauses directly.
The point is that a process on the server can effectively work out the timing of packets being received (for sessions they do not own). Not very practical for this particular attack: if the server is receiving other traffic it becomes useless - and, anyway, who types in passwords if they are using SSH - anyone with assets to protect will use public keys. But the sort of thing that could become part of a larger attack toolbox and a previously unimagined side-channel attack.
-
Wednesday 11th September 2019 12:47 GMT Crypto Monad
Re: Local access and you get ever so much!
> If they could monitor the server's traffic they could see the pauses directly.
Which is a much bigger hole than this one. Even someone *listening* to your typing can attack this way.
Solution: use a password manager for all your passwords. Then you paste them in one big splurge, with no gaps. This is an easy and comprehensive solution, and of course lets you use strong random passwords too.
Using RSA/EC private key authentication for ssh helps too - but you're still going to end up typing some passwords over ssh sessions (e.g. sudo password)
-
-
-
-
Wednesday 11th September 2019 06:19 GMT tfewster
Re: NetCAT?
NetCack would have been more descriptive, less confusing and met most of the researchers "objectives" for a name.
Of course, netcat and Linux are known for being hackers tools - Is your son a computer hacker?
-
-
-
Wednesday 11th September 2019 09:28 GMT Anonymous Coward
This is a tool that takes you from host access to obtaining other credentials to then allow you to move to game over.
The problem is that you don't necessarily need the host to have been compromised, legitimate access for a third party to the host may also allow them you to capture information that allows privilege escalation via other accounts.
It goes back to a defence in-depth strategy - it's not sufficient to just control access to a remotely accessible host, you have to also control what that host is able to access.
-
Tuesday 10th September 2019 19:45 GMT Spamfast
As far as I can see, this technique can't be used to determine the password the user uses to log onto the "RDMA Server" (see diagram) via ssh.
If we're talking about the authentication of the SSH session itself over the NIC<->NIC link shown in the diagram, the password is sent all at once after the user hits return when using the normal command line openssh client. It's not sent character by character in separate TCP datagrams as you type the individual characters, so there's no typing timing information to analyze. PuTTY/WinSCP etc do the same.
If you're using pubkey encryption, your password is never sent over the network at all - you type it in to decrypt your private key on your machine ("Victim Machine" in the diagram) and the private key is used to establish your identity via a challenge/response mechanism. The private key doesn't go across the network either. (Always use pubkey if you can!)
I can only imagine this working if you're already in a ssh-connected shell or tunnelled RDP/VNC session on "RDMA Server" and have to enter your local account password when sudoing or logging in using a graphical greeter.
Or am I missng something?
-
Tuesday 10th September 2019 20:35 GMT Blazde
It leaks the timing of everything typed inside the SSH session. So yea you're correct, not the initial authentication, but leaking a password is sort of the worst-case but completely plausible scenario if you logged in and immediately change your password, tunnel elsewhere, use sudo, login to an http interface on a nearby router, etc, etc. All kinds of other useful surveillance could be done too without ever capturing a password.
Arguably the one marked 'victim machine' is really the victim's machine and the RDMA server is the victim machine? but it's just semantics.
-
-
Tuesday 10th September 2019 20:34 GMT GnuTzu
CVE Link
Come on El Reg. We love ya, but could we please get CVE links? Searching for "CVE" didn't even mention whether a CVE existed.
And, there are InfoSec people following the El Reg's Security news. We won't break if you post a link to the full CVSS score. It would be helpful to us all and educational for some. Really, it's stuff worth know--and it's stuff worth understanding.
Again, we love ya, but "(CVSS score of 2.6)" in parenthesis is a little weak and a little insulting.
-
Wednesday 11th September 2019 01:15 GMT Henry Wertz 1
old switches
My friend had some pretty old switch, when the activity lights did not light up a half second or second at a time, but flickered with activity. You could easily tell apart interactive telnet/ssh, some ftp type file transfer, some samba or nfs style mount, apart just by seeing how it flickered (ftp of course pretty well lit it up solid). They vendors quit doing that (in favor of updating maybe a time or 2 a second) because apparently the leds responded quick enough to at least read back 10mbps data off the light flickers.
Interesting though, you may not get the password directly but i'm sure that timing info can greatly reduce the search space at least.
-
Wednesday 11th September 2019 03:12 GMT carl0s
Tbh I'm surprised SSH sends password keypresses to the remote end like telnet. I would have thought the password was captured client-side and then dealt with in some secure manner.
Are they meaning they capture you logging in to another system from the side-channel-monitored system? So you are already on a remote session from machine A to machine B, typing away, and you SSH from machine B to machine C, while some code on machine B infers your keypresses from the network packets coming from machine A to machine B? That sounds like it would make sense.
-
Wednesday 11th September 2019 08:35 GMT Peter Gathercole
@carl0s
If you use password authentication with SSH (rather than keys), the password will pass, all-be-it encrypted, across the network.
Some organizations prefer this over public/private key pairs with passphrases, because it gives them some control over the frequency and strength of the password used, as it can be expired and checked at the time it is changed. If you use keys with passphrases, with bog-standard SSH, you cannot expire a passphrase, and I've not seen a passphrase strength checker in the SSH implementations I've seen.
You also have the problem if the private key leaks, even if you change the passphrase on the primary copy of the key, the stolen copies will still have the old passphrase associated with them.
I know you can (and should!) get round these weaknesses by using some form of network key repository with auto key regeneration (to allow keys to be aged), or at least using ssh-agent, or maybe even Kerberos (I've used Kerberos, but not the Kerberos support built into OpenSSH), but many organizations think that just implementing SSH is enough. I've never rocked the boat by suggesting anything better, but then again, I've not been in early enough for most of the projects I've been working on to get it accepted early enough.
-
Monday 16th September 2019 09:24 GMT -tim
Re: @carl0s
SSH can be configured to use both a key and a server based password. If your key has a password, then you might have to enter the keys password, the system password and a one time password. System passwords are an additional obstacle to a hackers when users end up putting their private key on too many systems or are otherwise negligent in protecting their keys.
-
-
Wednesday 11th September 2019 11:37 GMT Spamfast
I'm surprised SSH sends password keypresses to the remote end like telnet
When authenticating the secure shell session itself using a mechanism that requires the password to be sent to the server ("PasswordAuthentication on" or "ChallengeResponseAuthentication on" in /etc/sshd_config - which I never allow!) then the password is sent (encrypted) across the channel. But it is sent all at once, after you've entered all of it on your client and hit Enter (or clicked OK in a GUI client).
It's never sent character by character as you type it in so this exploit can't work for determining the password for the login.
Once you're logged in to an interactive session (terminal or tunnelled RDP/VNC graphical) then, yes, individual keystrokes are sent one at a time. So as has been pointed out, if you enter a password at that point you're potentially vulnerable.
-
-
Wednesday 11th September 2019 05:45 GMT JakeMS
SSH Keys
Now I don't feel so bad about having 9 different SSH keys on my computer, each with a unique password.
Luckily an SSH key password is entered entirely locally and into an SSH Agent. So, simply no (remote) password sniffing possible.
But, of course. Even with keys, if your keys are stolen it could be game over regardless.
-
Wednesday 11th September 2019 07:34 GMT ankitpati
Press Ctrl + S to Save Yourself Against this Exploit
There’s a very simple mitigation against this exploit, already built right into (almost) every terminal (and terminal emulator) since the first (physical) one: Flow Control.
Just press Ctrl + S before entering sensitive information into a terminal, and press Ctrl + Q when done.
For improved usability, avoid using this with non-sensitive information, like regular UNIX commands. Only use for passwords, and perhaps secret file/directory names on a web server.
What happens is that the terminal queues your input between those two keystrokes, and sends it all at once, obliterating any timing information. Ctrl + S and Ctrl + Q are themselves not sent over the wire.
-
-
Thursday 12th September 2019 10:51 GMT ankitpati
Re: Press Ctrl + S to Save Yourself Against this Exploit
Works fine.
Simple test:
1. Open a terminal on any Linux system. iTerm2 on macOS does not support flow control.
2. Press Ctrl + S.
3. Blindly type `sleep 5` (ignore the back-ticks, and mind the space in between).
4. Press Enter/Return.
5. Wait 10 seconds.
6. Press Ctrl + Q.
7. Observe what happens!
-
-
-
Wednesday 11th September 2019 08:01 GMT Peter Galbavy
Sorry? What? Who uses SSH without an agent on their local machine? Why is SSH (as a protocol) singled out here? Any interactive session over the network is open to this form of "attack" and if you type SSH passwords into remote machines over the network (whether already SSH wrapped ot not) you are already broken.
-
Wednesday 11th September 2019 09:05 GMT Anonymous Coward
Tip from a greybeard - swap hands.
Many years ago I decided that passwords and PINs should be typed with the non dominant hand. Mainly because the entire world is set up for rightys (and I am nominally a righty) and the contortions involved mean that you'll never manage it the same way twice - and obscure the view of anyone behind you.
Another tip is to never enter the correct password the first time ....
-
Wednesday 11th September 2019 09:45 GMT Dazed and Confused
SSH Timing attacks
Am I loosing my marbles?
I'm sure I remember reading decades ago about a proposed attack on SSH based on the timing of peoples typing. Someone presented a paper on this and the response of the SSH maintainers was to introduce a randomised packet delay to defeat the attack.
-
Wednesday 11th September 2019 10:31 GMT Blazde
Re: SSH Timing attacks
A random delay in an interactive session would get annoying before it came close to properly defeating the attack. A better option is to send a constant stream of packets at a regular interval, inserting dummies when no key has been pressed. This is the original comprehensive paper on SSH traffic analysis, and research around that time did lead to some improvements in various implementations: https://people.eecs.berkeley.edu/~daw/papers/ssh-use01.pdf
(Note that this new attack is about getting timing data from the Intel chipset, where you can't otherwise observe network traffic. Attacking SSH is just used an example of one possible use for this timing data).
-
Wednesday 11th September 2019 10:43 GMT Unicornpiss
Rhythm..
I imagine the CIA or something already can do an analysis of someone's typing rhythm to figure out passwords. I remember somewhere reading that the sound of someone typing can be used to deduce what characters are being typed too. I don't expect either method works all that well when you get someone that never learned to touch type pecking away at the keyboard, or someone that fat-fingers part of their password, hits backspace a few times, then types in the rest. Which is a technique I sometimes use if someone is annoyingly watching me when I type in mine.
If I'm understanding the article correctly, it probably doesn't work all that well when someone is using an on-screen keyboard, such as with a tablet or phone. Either way, I don't think it's going to help you much with an already secure password that includes special characters and a mix of upper and lower-case letters, as many people that can even touch type break up their rhythm to look at the keyboard for some symbols or numbers.
-
Wednesday 11th September 2019 11:34 GMT Anonymous Coward
Van Eck?
This reminds me of that method of reading the electromagnetic spectrum of a CRT monitor to copy its contents.
https://en.wikipedia.org/wiki/Van_Eck_phreaking
https://climateviewer.com/2014/01/18/nsa-tempest-attack-can-remotely-view-computer-cellphone-screen-using-radio-waves/
Half is conspiracy theory, half is true... finding which is which is the best part. Truck loads of salt.
Yeah, wikipedia sucks, but it's the starting point to search for serious info.
Don't rely on Wikipedia, but don't dismiss it either. It is better to have some information that you don't believe, than having none at all.
Filling a cache to get the timing of keystrokes is borderline James Bond.
-
Wednesday 11th September 2019 12:06 GMT Anonymous Coward
Re: Van Eck?
No idea which is worse, digital or analogue. But someone over at Defcon conference showed how with an amature radio reciver, and a noisy Laptop LCD controller, it was giving out the entire screen contents over the air.
Not conspiracy, just how easy or valuable the target is, and if the hammer and wrench are alternatives or not.
-
Wednesday 11th September 2019 17:45 GMT Anonymous Coward
Re: Van Eck?
"Hammer and wrench" appear strictly in the endgame, when it is time for you to sign your confession in the torture chamber. First usually preceded by couple of years in which to "commit the crimes", i.e. get talked by provocateurs into becoming indictable "conspirator", get "evidence" planted on your box, etc. This is what the subtle taps are for.
-
-