stopping the next ssh leapfrog chained attack

For want of a nail the shoe was lost,
for want of a shoe the horse was lost,
for want of a horse the knight was lost,
for want of a knight the battle was lost.
So it was a kingdom was lost - all for want of a nail.

It is sensible to assume that the 'black hat' side is just a smart as the 'defense', indeed that they read the open literature and mailing lists, and think about where unseen holes might remain. They share and collaborate, albeit covertly and imperfectly.

The end case of this train of thought is that using a 'security through obscurity' approach is simply to 'hide and hope', ostrich-like, that the counter-party chooses another target.

So we end up with the case for openly discussed and developed security. It may not be possible to 'wash the linen' publicly at first, but if a project does not provide a frank and open 'root cause analysis' and response to its clientele, when an exploit has occurred, one has to question why one should trust them prospectively.

Part of basic system administration is inventorying the hosts under management. Based on review of some found cracker scripts, it is clear that some scripts 'phone home' information about the target or compromised host. At first, generic drop box accounts might have been used for transport, but of course those have to be retrieved, or forward along information, and as such can be traced in some cases. Game over.

So methods to anonymously place, and retrieve content emerge on the 'cracker' side:

• encrypted IRC networks for command, control and transport;
  
• computer mediated one-time pads and drop boxes which enforce proper use and are provable secure (at pg. 5), see also Schneier on the topic [we differ from his assertion that OTP are: 'also pretty much useless. Because the key has to be as long as the message, it doesn't solve the security problem.' While correct so far as it goes, that objection merely clarifies the remaining problem to solve];
  
• strong asymmetric [public, private keypair] cryptography with DH key transfer can permit truly untraceable secure communication.

The three preceding forms of root level access are taken from the news.

• for convenience, backups are customarily not strongly keyed with one time keys -- backup processes are customarily scheduled to run in slack activity periods, and so run at night when no-one is there to provide the keying; automated hardware one time keying systems that meet FIPS 140-2 standards are hard to do properly and expensive when certified to NIST standard levels
  
• locking bolts to control chassis access (the 'Kensington cable' chassis frame slot), BIOS lockdown, and tamper switch audit are routinely left unused and unmonitored
• the 'minimal' case of 'cracker' compromise

Presently Red Hat derived distributions carry too much gratuitous 'plain-text treasure' for a person in possession of an unencrypted backup, or with unchecked physical access to hardware, or who has root level read access.

I am thinking here particularly of harvesting 'known_hosts' and residual 'known_hosts2' for cleartext 'next hop' targets. I have speculated on this vector in the past.

Quick test to play along: run:
sudo find / -name 'known_hosts*' -print 2> /dev/null | grep [s2]$
and then as a non-privileged user, cat a few files. For extra credit and extra heartburn, repeat the inventory thus:
sudo find / -type d -name '*gnupg' -print 2> /dev/null

I certainly do not like what I see on my systems in reviewing the contents of the found files. It is clear that my practice (before authoring this piece) of rsyncing disk-to-disk backups around without cleaning up; and leaving working files on host transfers and migrations around are not well thought out as to security implication.

[herrold@centos-5 ~]$ wc /tmp/transferiso/1/root/.ssh/known_hosts
54 162 13967 /tmp/transferiso/1/root/.ssh/known_hosts
[herrold@centos-5 ~]$

Enough. I will not continue such a state of affairs. The default global ssh and sshd settings need to be altered in /etc/ssh/

man ssh_config provides:

HashKnownHosts
Indicates that ssh should hash host names and addresses when they are added to ~/.ssh/known_hosts. These hashed names may be used normally by ssh and sshd, but they do not reveal identifying information should the file’s contents be disclosed. The default is “no”. Note that hashing of names and addresses will not be retrospectively applied to existing known hosts files, but these may be manually hashed using ssh-keygen(1).

and the tool for a system-wide cleanup and conversion is in the default open-ssh already:

man ssh-keygen contains the following option:

-H Hash a known_hosts file. This replaces all hostnames and addresses with hashed representations within the specified file; the original content is moved to a file with a .old suffix. These hashes may be used normally by ssh and sshd, but they do not reveal identifying information should the file’s contents be disclosed. This option will not modify existing hashed hostnames and is therefore safe to use on files that mix hashed and non-hashed names.

We just need to have the will and the time to make the changes, write the scripts, do the work to secure content, adopt better habits, and push those habits into scripted repetitive tasks. Yeah -- that's all ... hmmm

---

081023 typo, layout, and grammar fix