Wednesday, January 8, 2014

SSH keys: An Argument for Continuous Audit

Suppose you see this, when connecting to a critical system:

$ ssh [redacted]
The authenticity of host 'redacted (IP # redacted)' can't be established.
ECDSA key fingerprint is b1:fb:be:19:ef:2e:3e:b9:e8:da:f5:72:27:3b:41:b4.
Are you sure you want to continue connecting (yes/no)?

I believe that the correct response to that prompt is, in many cases, 'no'.

Let us set aside common problems
  1. even security specialists (who should definitely know better) tend to burn through this message, and just connect
  2. even security-conscious system administrators often fail to appreciate the fact that key fingerprints have to be communicated to users out-of-band, or they have no effective means of doing so
  3. Point 2 is an artifact of SSH having no concept of a third party vouching for the authenticity of a host certificate, as HTTPS does (though there are huge problems with this as well)
What it comes down to is part of the trust basis lies in files with /etc/ssh. Public and private keys, server configuration, key revocations, are all in here. Files in $HOME/.ssh serve as a modifier. $HOME/.ssh/known_hosts is as critical as any other file in this system. Perhaps more so, as known_hosts replaces the entire functionality of third-parties guaranteeing (unreliably, in the case of TLS) that a server is, in fact, the machine you think you are connecting to. 

So, an ssh user correctly or incorrectly trusts that the connection target is correct, and now, in the light of recent NSA revelations, we have to think about crypto, which leads us to the ECDSA key fingerprint seen above. Bruce Schneier believes that elliptic curve crypto was deliberately weakened by NSA, at least in a TLS context. Like most security practitioners, I believe him to be trustworthy, in the sense that he might be incorrect, though he is extremely knowledgeable, but he would not intentionally mislead anyone. OpenSSH originates from Theo de Raadt's OpenBSD project, and I also regard Theo de Raadt as trustworthy, for the same reasons.

Practitioners might then look at changelogs for their SSH system, or do code reviews. This is an obvious win for transparency, versus binary-only systems, but we do not often have time to do careful evaluations, and make carefully calibrated decisions.

The greatest safety, then, would lie with systems that allow configuration files to be pushed. This is a powerful argument against ad-hoc deployments, if another was needed. It does not, however, provide insight into which machines may have been vulnerable, and for what span of time.

It is difficult to know where critical data resides--my take is that in most enterprises, this is not a solveable problem. A lack of knowledge of vulnerability windows only compounds the issue, and only continuous audit techniques can generate the trustworthy data required to even begin to evaluate risk.














No comments:

Post a Comment

Thanks for your comment; communities are not built without you.

But note than comments on older posts usually go into a modertion queue. It keeps out a lot of blog spam. Weird links to Web sites hosting malware, marketing nonsense, etc.

I really want to be quick about approving comments in the moderation queue. When I think I won't manage that, I will turn moderation off, and sweep up the mess as soon as possible.

If you find comments that look like blog spam, they likely are. As always, be careful of what you click on. I may have had moderation off, and not yet swept up the mess.