Contributed by sean on from the dept.
A brief summary is provided below. The paper assumes the initial 'seed' machine has been already compromised. Once a machine is compromised anything is fair game. This being a given, the author's have pointed out that the known_hosts files as well as the /etc/hosts.* files are really good sources for addresses of new targets. This alone isn't enough to build a worm as it would still need a method to impersonate valid users or find some method to compromise these newly found hosts.
The standard methods of replacing daemons and binaries can aid in that task but the real killer is unencrypted ssh keys (ie. used frequently for automating remote tasks). Combine the information gleaned from known_hosts, authorized_keys and having access to an unencrypted ssh key (already authorized elsewhere) you have a very solid starting point for 'worm' like propagation.
The technique in the paper hinges on the accessibility of the known_hosts files and have proposed that this file be hashed/encrypted. This technique has already been implemented in OpenSSH 4.0 and the authors provide a patch backporting the feature to 3.9 and 3.9p1.
If you are already using a OpenSSH 4.0 (or the patched 3.9) setting up hashing of knowns hosts is pretty simple (as is described here). All you have to do is:
echo "Host *" >> /etc/ssh/ssh_config echo "HashKnownHosts yes" >> /etc/ssh/ssh_configYou will also have to recreate the known_hosts files or convert your existing ones using a script provided by the authors.
For more information about this paper check out the MIT CSAIL page on the subject.
UPDATE: I'd like to point out that the authors do not state that the hashing of the known_hosts is a solution to this problem but as a means of mitigating this particular technique for address harvesting.
(Comments are closed)
By Anonymous Coward (82.73.147.65) on
Comments
By phessler (64.173.147.27) on
Comments
By sean (139.142.208.98) on
By Gimlet (128.252.229.164) on
Comments
By Anonymous Coward (66.32.234.76) on
By Frank Denis (213.41.131.17) on http://www.00f.net
Comments
By Bert (216.175.250.42) blambert at thepresidency dot org on
Seriously, though, i don't see this as being a massive problem. Although interesting, there are a number of obstacles to overcome to automate SSH logins as a vector. The largest of which (or, at least, it seems to me) is the heterogeneity of the sshd universe. An exploit for FreeBSD isn't the same as for Solaris, isn't the same as for Linux...
As another poster mentioned, requiring a second authentication factor (e.g., password) that means that something carbon-based is on the other end, as well as restricting the actions of scripted logins to that which they need to do to fulfill their function, would mitigate this (yes, you lose convenience, but all of life's a tradeoff).
Of course, I could need to take off the blinders.
By David (66.88.103.162) on
Comments
By Frank Denis (213.41.131.17) on http://www.00f.net
By sand (217.220.29.251) sandolo at gmail.com on
Informations are everywhere, and IMHO hiding one or more files will only slow down the everyday tasks of the users, while the attacker can still gather A LOT of data from other sources.
once again the rise and fall of security by obscurity, ALALA'.
By Anonymous Coward (203.217.30.86) on
By Kevin Kadow (163.192.21.41) on
I only use authorized_keys on role accounts, never for normal login accounts, and always include a specific command in the authorized_keys file on the server. This limits the damage that can be done using these credentials to the exact task the key was created for.
Comments
By Anonymous Coward (68.6.193.220) on
By Sam (130.88.31.6) on
Comments
By SH (82.182.103.172) on
By Anonymous Coward (216.220.225.229) on
Resist the temptation to add complexity to the software and protocol to protect against future attacks. Push in the direction of simplicity.
Comments
By Ben (208.27.203.127) mouring@nospam.eviladmin.org on
By Anonymous Coward (211.5.104.241) on
And say a worm discovers that you ssh into somemachine.com. Does that allow it to circumvent security? Hell no! The worm will only get in if I have screwed up something fundamental (like using passwords instead of public key auth, or not have a good (or any!) passphrase). Or if I am using ssh-agent, it may own me that way, but I was probably already its bitch at that point.
Now, protecting the data in known_hosts is not necessarily a bad idea since it can make life harder for the bad guy. But it is a brittle countermeasure, since once an attacker gets the info by some path then the fact that known_hosts is hashed (or whatever) is totally useless.
But the real issue is that to stop an attack like this you use strong authentication, not obscurity.
Comments
By djm@ (203.217.30.86) on
Fortunately, the costs for the user of hashing hostnames are minimal. In fact, the new tools make handling known_hosts far easier than going in with vi and searching for an old key to manually zap it. Now you can do "ssh-keygen -R blah" to delete a key by hostname.
Of course, if admins would scan their systems for ssh private keys with absent or trivial passwords, then this would be much less of a problem...
By superhet (12.135.176.137) jayzel@gmail.com on
By Anonymous Coward (65.87.132.208) on
All of you "obscurity isn't security" whiners need to learn how to think more about what happens in practice - rather than just blindly repeating a mantra that you don't really understand the implications of.
By Anthony Roberts (68.145.103.21) on
Comments
By djm@ (203.217.30.86) on