2009-04-09
Why ssh needs to verify host keys
Suppose that your ssh does not check host keys and an attacker has not so much successfully impersonated one of your machines as persuaded you to connect to his machine instead of yours, without you knowing. How does the attacker 'win'?
We can see the obvious wins by what ssh turns off if you have
StrictHostKeyChecking set to 'no' and a key fails to verify. First,
the attacker wins immediately if they can get you to type your password
to their ssh daemon, since they can just have their ssh daemon log
it. Second, the attacker can win if they can get access to various bits
of your local session, such as your X display, any forwarded local
ports, or especially your authentication agent. Even a straight text
connection is potentially dangerous, since many terminal environments
these days can be coaxed into taking various actions in response to
escape sequences.
With more work, the attacker can also probably conduct a standard man
in the middle attack, passing things along to log you in to your real
target and then capturing any further passwords or sensitive information
you access in your session. (It's only 'probably' because your real
target might not accept your authentication from the attacker's server,
if you've set restrictive from="..." permissions on your keypairs or
the like.)
Up until now, I naively thought that there were few risks for automated scripts using keypairs for passwordless logins; on an impersonation attempt the login would just fail because of missing keypairs. The flaw in this logic is that I believe there's nothing to stop an attacker's custom ssh server from just unconditionally accepting your keypair and letting you 'log in'.
(In theory the ssh protocol could require the server to demonstrate that it knew the 'public' half of your keypair, but I don't think that it does.)
Then if your script is pushing something, the attacker can get a copy of it; if your script is pulling something the attacker can feed you whatever data they want to. The attacker can also probably do a standard man in the middle attack to monitor what your system expects to pull (or push), and thus capture your real data and analyze what your system expects. (The qualifiers on 'probably' are as before; it depends on what your real target machine will accept the keypair from.)
(Credit where credit is due: a conversation with Pete Zaitcev about my previous entry started me thinking carefully about this issue.)