Wandering Thoughts archives

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

sysadmin/WhyVerifyHostKeys written at 00:17:19; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.