For want of a nail the shoe was lost,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.
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.
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.
- 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
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
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:
HashKnownHostsand the tool for a system-wide cleanup and conversion is in the default open-ssh already:
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).
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