FFS!
Evil OpenSSH servers can steal your private login keys to other systems – patch now
Malicious OpenSSH servers can silently steal people's private SSH keys as they try to login, it emerged today. This means criminals who compromise one server can secretly grab keys needed to log into other systems from a user's computer – allowing crooks to jump from server to server. The security cockup, present in the …
COMMENTS
-
-
Thursday 14th January 2016 18:56 GMT petur
FFS indeed...
"When there's a serious security bug in the remote access tool used by 70+% of the servers in the world, people sit up and take notice," said Kenn White, co-director of the Open Crypto Audit Project.
The problems occur in how OpenSSH client code between versions 5.4 and 7.1 handles roaming,
This phrase makes it look like those 70+% servers are vulnerable, but it is a client bug...
(yes, lots of servers means many clients but still....)
-
Thursday 14th January 2016 19:01 GMT Voland's right hand
Doubly FFS
X-forwarding and Agent forwarding are the first thing to enable to make ssh useful.
It is standard usage scenario - ssh into a jump box and ssh to the next system inside the network. If you do not have agent enabled you will be entering passwords or passphrases which is a recipe for disaster.
Time to start patching.
-
-
This post has been deleted by its author
-
-
Thursday 14th January 2016 20:36 GMT Anonymous Coward
Re: does no one use passphrases on their private keys?
"does no one use passphrases on their private keys? "
Yes, min 20 chars and we don't use agent forwarding, hopping a gateway server to another requires passphrase entry. Doing it another way is just for the bone idle.
The only use for phrase free keys here is for servers to connect to others with no user interaction, things like log transfers etc and then each server has a different key and logs in to a different account on the central machine with user privs. Some of these setup a reverse tunnel that can be used to access the connecting system behind NAT over a mobile 3g connection, but you still need to enter a passphrase to acess it over the tunnel.
The lazy will always get pawned.
-
Friday 15th January 2016 12:25 GMT Anonymous Coward
Re: does no one use passphrases on their private keys?
We use passphrases on all personal use keys, or anything that is manually initiated.
The only place we use keys without passphrases, is server-to-server and only for automated processes, and these are separate keys per point-to-point connection.
-
-
Thursday 14th January 2016 20:38 GMT chasil
Password [algorithim] strength
Key passwords make this more difficult to exploit:
"One bright spot is that passphrase-encrypted SSH keys are leaked in their encrypted form and must be cracked offline. Not everyone protects their keys using a passphrase, however."
I wonder if converting the private key to PKCS #8 format will provide further protection?
http://martin.kleppmann.com/2013/05/24/improving-security-of-ssh-private-keys.html
My cygwin keys on my workstation are in PKCS #8 format - but then again, I also have the putty pagent running, which likely erases any benefit from PKCS #8.
-
Thursday 14th January 2016 20:54 GMT Anonymous Coward
"This information leak may have already been exploited in the wild by sophisticated attackers"
I see OpenSSH 5.4 was released in 2010, however, back in 2007 when I was building secure remote access services for various government departments, one of the items of functionality prohibited in the guidance was... session roaming...
So given the disclosures todate (such as Edward Snowdon's), I suspect OpenSSH isn't the only implementation of session roaming to have vulnerabilities that would permit the client's key pair to be fully compromised and so facilitate an attack on central systems...
-
-
Friday 15th January 2016 17:43 GMT Crazy Operations Guy
Re: My workaround...
Its fun to run things on other ports. I run ssh on a high-numbered port and run a dummy version of ssh on 22, it just grabs the username / password and the IP of the machine into a csv file and then respond with 'access denied', (Its actually just OpenSSH compiled with an authentication library that does nothing but writes out the data given to it). Now I have a nice big list of usernames and passwords from the bots, and since its coming from multiple bot-networks, I get a wide variety and can sort on the most common to get a very efficient list that I then use for pen testing. That list has greatly reduced my time-to-compromise for my pen tests.
Only our IT staff are allowed to log in via SSH, and they use key-based authentication and are given files that specific distrust the public keys given out by my fake ssh server (That key happens to be 00:11:22:33:44....).
-
Friday 15th January 2016 10:53 GMT Anonymous Coward
Not good
I suspect I'm not alone in being lazy with keys - I use them without a passphrase so I can jump between systems without typing passphrase or password. This means that if one of these systems is compromised and someone steals my private key, they have access to all of the systems.
On the plus side, the systems are mostly secure. On the minus side, I will have to generate a new key for systems that are wholly mine. If someone gets the key for those, I'm the one to blame.
-
Friday 15th January 2016 11:28 GMT PassiveSmoking
I think the time has finally come to admit that security-critical subsystems should never be written in a language as hairy as C. There's so many gotchas (double-free, dangling pointers, buffer overruns, etc etc etc) that you can't depend on C code to keep sensitive data private.
We need an SSH library written in something that doesn't let the programmer make so many mistakes and makes it very obvious when they do make one, preferentially one that does all the error-prone memory management for the programmer. C# or Swift, maybe?
-
Friday 15th January 2016 12:11 GMT Peter Gathercole
Languages other than C @Passive Smoking
At the risk of angering the anti-C lobby, it is unfortunate that trusting a language that implements things like strict bounds, type and syntax checking is not a universal panacea. You're just exporting your trust to another component that could possibly be very complex.
Consider the following potential headline:
"Devs told to patch their <vendors implementation of language of choice> development environment, recompile and re-ship all applications due to security checking bug in <vendors implementation of language of choice>'s compiler and runtime."
This becomes more complicated for users of software who may not be aware of the development environment used for the software they've purchased or otherwise procured.
Admittedly this is a bit of a contrived scenario, and there is a good chance that because of run-time linking, it may only be necessary to provide a new execution environment or run-time libraries that provide the fix, but just switching to a more strict language does not ensure that applications are guaranteed to be more secure.
At least, where the bug is in the C source code, it is sufficiently primitive that you can see the error in the source of the application, and not have to trawl your development environment.
-
Friday 15th January 2016 14:41 GMT Roland6
Re: Languages other than C @Passive Smoking
Well the only language that comes close to satisfying the requirement would be Ada; but only if you also use a certified compiler...
There are good reasons why C became the language of choice for systems programmers; the mistake was allowing application programmers to use it. :)
-
This post has been deleted by its author
-
-
Friday 15th January 2016 11:39 GMT John Robson
Private key on the server???
Wha'
Why is it ever transmitted - surely the appropriate way to do auth forwarding (which is useful) is for the server to pass the auth requests back to the client (which may pass them back to the next client etc.) until it's at the machine with the private key
-
-
-
Friday 15th January 2016 14:00 GMT Remy Redert
Re: Private key on the server??? @John Robson
Because nothing needs to be implemented on the server. It's just the client keeping your key in memory so that if the connection is dropped for any reason, the client can automatically reestablish the connection without bothering the user about it. If the drop is short enough, the user might not even know his connection was dropped.
-
-
-
-
-
Friday 15th January 2016 16:03 GMT phuzz
Re: Workaroud breaks putty
Ulp, ignore that, if you add "UseRoaming no" to sshd.conf (rather than ssh.conf) then you break SSH, and that is of course what I've done. (thank fsck for puppet still working and being able to fix my cockup)
Not that anyone else is going to be daft enough to make that mistake, right?
-