Financial Cryptography

Say it ain't so? MITM protection on SSH shows its paces...

For a decade now, SSH has successfully employed a simple opportunistic protection model that solved the shared-key problem. The premise is quite simple: use the information that the user probably knows. It does this by caching keys on first sight, and watching for unexpected changes. This was originally intended to address the theoretical weakness of public key cryptography called MITM or man-in-the-middle.

Critics of the SSH model, a.k.a. apologists for the PKI model of the Trusted Third Party (certificate authority) have always pointed out that this simply leaves SSH open to a first-time MITM. That is, when some key changes or you first go to a server, it is "unknown" and therefore has to be established with a "leap of faith."

The SSH defenders claim that we know much more about the other machine, so we know when the key is supposed to change. Therefore, it isn't so much a leap of faith as educated risk-taking. To which the critics respond that we all suffer from click-thru syndrome and we never read those messages, anyway.

Etc etc, you can see that this argument goes round and round, and will never be solved until we get some data. So far, the data is almost universally against the TTP model (recall phishing, which the high priests of the PKI have not addressed to any serious extent that I've ever seen). About a year or two back, attack attention started on SSH, and so far it has withstood difficulties with no major or widespread results. So much so that we hear very little about it, in contrast to phishing, which is now a 4 year flood of grief.

After which preamble, I can now report that I have a data point on an attack on SSH! As this is fairly rare, I'm going to report it in fullness, in case it helps. Here goes:

Yesterday, I ssh'd to a machine, and it said:

zhukov$ ssh some.where.example.net
WARNING: RSA key found for host in .ssh/known_hosts:18
RSA key fingerprint 05:a4:c2:cf:32:cc:e8:4d:86:27:b7:01:9a:9c:02:0f.
The authenticity of host can't be established but keys
of different type are already known for this host.
DSA key fingerprint is 61:43:9e:1f:ae:24:41:99:b5:0c:3f:e2:43:cd:bc:83.
Are you sure you want to continue connecting (yes/no)?

OK, so I am supposed to know what was going on with that machine, and it was being rebuilt, but I really did not expect SSH to be effected. The ganglia twitch! I asked the sysadm, and he said no, it wasn't him. Hmmm... mighty suspicious.

I accepted the key and carried on. Does this prove that click-through syndrome is really an irresistable temptation and the archilles heel of SSH, and even the experienced user will fall for it? Not quite. Firstly, we don't really have a choice as sysadms, we have to get in there, compromise or no compromise, and see. Secondly, it is ok to compromise as long as we know it, we assess the risks and take them. I deliberately chose to go ahead in this case, so it is fair to say that I was warned, and the SSH security model did all that was asked of it.

Key accepted (yes), and onwards! It immediately came back and said:

iang@somewhere's password:

Now the ganglia are doing a ninja turtle act and I'm feeling very strange indeed: The apparent thought of being the victim of an actual real live MITM is doubly delicious, as it is supposed to be as unlikely as dying from shark bite. SSH is not supposed to fall back to passwords, it is supposed to use the keys that were set up earlier. At this point, for some emotional reason I can't further divine, I decided to treat this as a compromise and asked my mate to change my password. He did that, and then I logged in.

Then we checked. Lo and behold, SSH had been reinstalled completely, and a little bit of investigation revealed what the warped daemon was up to: password harvesting. And, I had a compromised fresh password, whereas my sysadm mates had their real passwords compromised:

$ cat /dev/saux
foo@...208 (aendermich) [Fri Feb 15 2008 14:56:05 +0100]
iang@...152 (changeme!) [Fri Feb 15 2008 15:01:11 +0100]
nuss@...208 (43Er5z7) [Fri Feb 15 2008 16:10:34 +0100]
iang@...113 (kash@zza75) [Fri Feb 15 2008 16:23:15 +0100]
iang@...113 (kash@zza75) [Fri Feb 15 2008 16:35:59 +0100]
$ 

The attacker had replaced the SSH daemon with one that insisted that the users type in their passwords. Luckily, we caught it with only one or two compromises.

In sum, the SSH security model did its job. This time! The fallback to server-key re-acceptance triggered sufficient suspicion, and the fallback to passwords gave confirmation.

As a single data point, it's not easy to extrapolate but we can point at which direction it is heading:

• the model works better than its absence would, for this environment and this threat.
• This was a node threat (the machine was apparently hacked via dodgy PHP and last week's linux kernel root exploit).
• the SSH model was originally intended to counter an MITM threat, not a node threat.
• because SSH prefers keys to passwords (machines being more reliable than humans) my password was protected by the default usage,
• then, as a side-effect, or by easy extension, the SSH model also protects against a security-mode switch.
• it would have worked for a real MITM, but only just, as there would only have been the one warning.
• But frankly, I don't care. The compromise of the node was far more serious,
• and we know that MITM is the least cost-effective breach of all. There is a high chance of visibility and it is very expensive to run.
• If we can seduce even a small proportion of breach attacks across to MITM work then we have done a valuable thing indeed.

In terms of our principles, we can then underscore the following:

• We are still a long way away from seeing any good data on intercept over-the-wire MITMs. Remember: the threat is on the node. The wire is (relatively) secure.
• In this current context, SSH's feature to accept passwords, and fallback from key-auth to password-auth, is a weakness. If the password mode had been disabled, then an entire area of attack possibilities would have been evaded. Remember: There is only one mode, and it is secure.
• The use of the information known to me saved me in this case. This is a good example of how to use the principle of Divide and Conquer. I call this process "bootstrapping relationships into key exchanges" and it is widely used outside the formal security industry.

All in all, SSH did a good job. Which still leaves us with the rather traumatic job of cleaning up a machine with 3-4 years of crappy PHP applications ... but that's another story.

---

For those wondering what to do about today's breach, it seems so far:

• turn all PHP to secure settings. throw out all old PHP apps that can't cope.
• find an update for your Linux kernel quickly
• watch out for SSH replacements and password harvesting
• prefer SSH keys over passwords. The compromises can be more easily cleaned up by re-generating and re-setting the keys, they don't leapfrog so easily, and they aren't so susceptible to what is sometimes called "social engineering" attacks.

Posted by iang at February 17, 2008 04:26 PM | TrackBack