OpenBSD Journal

The Potential for an SSH Worm

Contributed by sean on from the dept.

A few people have pointed out a paper from MIT ( pointed out by Bruce Schneier) regarding the potential to exploit 'saved knowledge' in SSH to spread like a worm.

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_config
You 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)

Comments

  1. By Anonymous Coward (82.73.147.65) on

    His name is Schneier. Not Schnier.

    Comments

    1. By phessler (64.173.147.27) on

      Thanks. Updated.

      Comments

      1. By sean (139.142.208.98) on

        Damn, I always miss something. Thanks.

    2. By Gimlet (128.252.229.164) on

      Hey, is it so hard to use an apostrophe to show possession? Typos are easy to make, calm down.

      Comments

      1. By Anonymous Coward (66.32.234.76) on

        oh snap!

  2. By Frank Denis (213.41.131.17) on http://www.00f.net

    Unfortunately, enabling hashing disables completion for the ssh command in shells like Zsh. Sure, this is not critical and there is obviously no workaround, but when you are using the TAB key for everything for years, it's hard to get back to writing full host names again. However host names are still in your shell history, so unless you also disable history logging, hashing host names is pointless.

    Comments

    1. By Bert (216.175.250.42) blambert at thepresidency dot org on

      Nah, that's easy: hash the shell history file :p

      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.

    2. By David (66.88.103.162) on

      Don't forget the last(1) command and wtmp database store related hostnames as well.

      Comments

      1. By Frank Denis (213.41.131.17) on http://www.00f.net

        and /var/log/* Host names and IPs are everywhere.

    3. By sand (217.220.29.251) sandolo at gmail.com on

      Another solution is to not hash any file and to choose good passphrases ;)
      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'.

    4. By Anonymous Coward (203.217.30.86) on

      which is, of course, the point.

  3. By Kevin Kadow (163.192.21.41) on

    Unencrypted DSA keys for making passwordless connections are a necessary evil for process automation.

    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

    1. By Anonymous Coward (68.6.193.220) on

      Definitely. And also (this is probably dead obvious to the people in this forum, but if I had a nickel for every time it didn't happen...) manually check your friggin accounts. Log in as that user, and try hacking into places you shouldn't. At least for a few minutes. Unless you're one of those admins whose work is so perfect it never needs to be verified :)

    2. By Sam (130.88.31.6) on

      Pity that doesn't work for scp.

      Comments

      1. By SH (82.182.103.172) on

        You can use systrace for this, but it involves some work on the remote account. The remote account should have a systraced shell (there is an article on this on undeadly.org) with appropiate systrace policy.

  4. By Anonymous Coward (216.220.225.229) on

    OpenSSH is everywhere. It is also becoming the transport for many other protocols (yeah!). The choices of protocols to attack will shrink.
    Resist the temptation to add complexity to the software and protocol to protect against future attacks. Push in the direction of simplicity.

    Comments

    1. By Ben (208.27.203.127) mouring@nospam.eviladmin.org on

      Sadly the days of KISS are over. They died with SSH protocol v1. *weak smile* v2 protocol complexity is off the scale (along with most protocols), and when you add BSM, PAM and other system security protocol/methods ontop of it you end up with more complexity. Add to that the need to keep backward compatible for buggy servers/clients and you have yet another subsection of complexity. *sigh* In regards to hashing. I remember the team taking about before I wandered off to work on other projects, and the main bonus isn't "oohh you can't see where I ssh to.." It's a speed factor if you are using OpenSSH on large multi-node clusters and you have TONS of systems you have to interact with. - Ben

  5. By Anonymous Coward (211.5.104.241) on

    I call bullshit. Obscurity is NOT security. There are many ways an attacker can find out about ssh relationships... traffic analysis, shell histories, administration scripts, etc.

    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

    1. By djm@ (203.217.30.86) on

      I agree that all of the information in known_hosts is available by other means (e.g. netstat, ps, [uw]tmp), but nowhere is it as concentrated and directly correlated to trust relationships as known_hosts. So, I think it makes sense to spend a little effort in protecting it.

      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...

    2. By superhet (12.135.176.137) jayzel@gmail.com on

      There is immediacy to propagating a worm through known_hosts, as opposed to going through ones history, or traffic analysis. The point is the immediacy here, and not the inevitable, which is a form of security through obscurity, yes. A point lost on some.... because I too at first thought "no big deal. If you are got, you are got." But the point here is that if a worm gets you via ssh stuffs, having a readily available known_hosts will increase the likelihood of the immediate propagation of that worm type paradigm. This reply was generated via 'links' and may have interesting formatting. Preaching to the choir here, I am. (Just saw SW3 yesterday)

    3. By Anonymous Coward (65.87.132.208) on

      Actually, when it comes to slowing the spread of a virus, obscurity helps a good bit.
      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.

  6. By Anthony Roberts (68.145.103.21) on

    I noticed when switching my known_hosts file over to the hashed system that it adds a host twice. Once for the DNS name, and once for the IP address. Isn't the number of IPv4 addresses small enough that a worm on a reasonably fast computer could simply test all the hashed entries against all IP addresses? Indeed, couldn't the black helicopter men do that too?

    Comments

    1. By djm@ (203.217.30.86) on

      If you are afraid of black helicopters and worms that try brute force attacks, then you can set CheckHostIP=no in ssh_config.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]