[LINK] Poorly Managed SSH Keys

Karl Auer kauer at biplane.com.au
Mon Feb 24 14:07:17 AEDT 2014

On Mon, 2014-02-24 at 02:16 +0000, Stephen Loosley quoted:
> Poorly managed SSH keys pose serious risks for most companies
> [...]
> Three in four have no processes for managing [ssh]keys [...]
> http://www.arnnet.com.au/article/538884/poorly_managed_ssh_keys_pose_serious_risks_most_companies/?fp=2&fpid=1

While I'm happy to accept that many companies may not be managing access
credentials properly, I don't accept that it's unique to SSH keys. A
company that manages credentials properly will be managing ssh along
with them, more or less automatically.

The big and related flaws in the article are:

> Even though more than half of the surveyed enterprises had suffered
> SSH-key related compromises

What does "ssh related" mean? This makes it sound like it is a flaw in
SSH that made the compromise possible. This is extremely unlikely.

> About 46% said they never change or rotate SSH keys -- even though the
> keys never expire.

And this is SSH-related how? answer - it's not. Failing to require
password/passphrase changes is a) not necessarily all that bad and b)
not something specific to ssh.

> A hacker who acquires an unsecured SSH key

Just like any other form of credential. Nothing specific to ssh here.

> Because SSH keys provide administrator-level, fully encrypted access
> to enterprise systems, any compromise of the keys could allow an
> attacker to gain complete control of a system while they remain hidden
> from view.

Except for the weasel word "could" this is false in a misleading way.
No-one in their right minds allows ssh root logins. The default
configuration for most ssh servers is to disable root logins. Nor does
the fact that the access is fully encrypted (whatever that means) have
any relevance here. As to the "hidden from view", it's no more hidden
from view than anything else. The fact of the login is visible, just as
it is with any other form of login.

Most ssh access is to an ordinary user-level account. From that account,
mechanisms such as sudo, su, and setuid are used to perform
higher-privileged tasks. Those mechanisms (except setuid) require
further credentials.

> [...] said Kevin Bocek, vice president of product marketing and threat
> research at security vendor Venafi, which commissioned the Ponemon
> survey.

Ah! Now we come to the nub of the matter. A security firm whipping up a
bit of hype. Gosh, that's new.

> "SSH is really critical as a root-level access [tool]," Bocek said.

No it is NOT. It *can* be used directly for root level access- very few
people do, and those that do are idiots.

>  "It is an encrypted channel that goes around traditional host
> protections."

No it is NOT. It integrates WITH traditional host protections. Bocek
reveals himself to be ignorant or disingenuous - or both.

> By stealing SSH keys, attackers like those behind The Mask APT can
> impersonate admins, snoop around and take complete control of a
> target's network without being detected, he said.

Just like any other form of access credential - if you steal it, you can
misuse the access. Nothing specific to ssh here.

>  There are signs that National Security Agency contractor Edward
> Snowden might have used SSH keys or a similar digital certificate to
> access and steal documents without being detected, he said.

Signs, eh? I bet there were portents too. Bullshit. Out and out

It seems from available information that Snowden used his existing
legitimate access to do unexpected things. In fact, some might say that
was the actual problem! If he did steal credentials, there is nothing
special about stealing ssh credentials rather than some other kind of

> To get a handle on the problem, enterprises must figure out where SSH
> is in use and how many keys might be floating about on their networks.
> They then need to find a way to correlate the keys back to the
> appropriate servers, evaluate whether they're needed and put in place
> a process for automatically changing keys.

Something they should be doing for all access credentials. ssh does not
need special treatment.

Regards, K.

Karl Auer (kauer at biplane.com.au)

GPG fingerprint: EC67 61E2 C2F6 EB55 884B E129 072B 0AF0 72AA 9882
Old fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A

More information about the Link mailing list