Episode 2 will be released next week. The review (and rewrite) of the information took longer than anticipated because of travel (Lisbon and Chicago this time) and illness.

Since I am working on getting Reasonably Secure Builds together and will be walking through a Debian build with an encrypted filesystem, and since I needed to upgrade vmware, I decided to do the full upgrade on lexington and get it up to scratch. I actually used the latest Lenny daily build of the Netinst CD, and it was nice. It is basically the same as I have always done, except for the fact that they have replaced the lilo command line prompt on the burst page with a dialog-like menu to give you your options.

I really want to get it running again, so that I can play with Untangle. It looks like a very cool product, and lexington has enough filesystem space for me to evaluate it.

More on my progress with Untangle. In fact, if things work out with it, expect an AP episode on it, somewhere in the firewalling eposodes.

http://www.linuxplanet.org/casts/

http://www.linuxplanet.org/blogs/

As root, or through sudo:

apt-get update && apt-get upgrade (or dist-upgrade)

This will upgrade openssh and openssl. If the ssh host keys are found to be vulnerable, they are automatically regenerated and the old keys are archived as /etc/ssh/ssh_host_rsa_key.broken and /etc/ssh/ssh_host_dsa_key.broken<c/ode>.

The upgrade also installs three new tools called <code>openssh-blacklist, openssl-blacklist and openvpn-blacklist. These packages contain lists of partial key fingerprints, enough to verify the vulnerability of a key. They will block vulnerable or compromised keys from connecting.

openssh

As root or sudo,

ssh-vulnkey -a

This will give you an initial list of vulnerable ssh keys on your system, including ssh keys, known_hosts and authorized_keys. Key fingerprints are compared to /etc/ssh/blacklist.DSA_1024 and /etc/ssh/blacklist.RSA_2048. Note that if you generated non-standard keys, for instance, at an unusual bit size, the keys could still be vulnerable but not be in these lists. In addition, according to an article in the yobi wiki, any DSA key which was exposed to a compromised machine should be considered compromised. My personal recommendation is to regenerate any key which was generated between September 2006 and May 2008,

ssh-vulnkey -a will list all keys on your system, with a status of Not blacklisted, Unknown or COMPRPMISED. I used ssh-vulnkey as a reference to list the keys which I needed to regenerate, and started by regenerating all of my personal keys on all of the machines on the network that were generated during the time window in question. This includes unattended accounts, such as my account for backuppc and my network monitoring system.

Compromised host keys can be in a user’s .ssh/known_hosts, so issue a

find / -name known_hosts

Examine each file for the compromised key. Since I was doing a clean sweep, I simply deleted the entire known_hosts file. It will be repopulated when a logging into a new host. To do this, issue

find / -name known_hosts | xargs rm

Use the same procedure for authorized_keys. When you push your keys to the server, this file will again be created and/or populated.

Continue to run ssh-vulnkey -a until all keys are clean. Repeat the process on each host. To regenerate a user key, issue

ssh-keygen -t dsa

or

ssh-keygen -t rsa

and follow the prompts. Choose a good passphrase for your key. Pauldotcom had a great discussion of good passwords/passphrases on episode 106, if memory serves (the discussion is not listed in their show notes, so you’ll just have to go listen).

Other good passphrase resources include

queen.clara.net unix-ag.uni-kl.de

To regenerate host keys, move the old host keys to another filename or delete them, then run

dpkg-reconfigure openssh-server

openssl

The tool for this application is called openssl-blacklist. There is no -a option, so you need to find the ssl certs on your system. Ssl certs are similar to ssh keys, in that they have two parts. In the case of ssl, you have a certificate file (which is generally a .pem or a .crt) and a .key file. Obviously, if you called it something else, you are probably savvy enough to know what it is called. The openssl-vulnkey tool works against the key file, rather than the certificate itself. You should search your system for key files, which is usually called something.key. You should usually be able to find a something.pem or something.crt nearby. A couple of good places to look are in /etc/ssl/private for the key, with the certificate in /etc/ssl/certs, if you run openvpn, /etc/openvpn. Also check beneath /var/www if you run a web server with https. This tool does not have a -a feature, so you must run it against individual keys. However it does accept multiple keys. Run openssl-vulnkey /etc/ssl/private/*.key, the output should be similar to ssh-vulnkey.

OpenVPN

OpenVPN works with either ssl certificates or with shared keys. The ssl certificates are handled by openssl-blacklist, while openvpn-blacklist handles shared keys generated by openvpn. Normally, these are used for tls-auth files or if you are using shared-key authentication for your vpn. Keys generated by openvpn look similar to

#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
b54ea37f29de1988937868e3cdbf7ded
2e720ed9531f68df3fe03f21a4087c0d
74c132f5fb47c3852b3f3d4b29ebe3af
cc009cc78af265664f4ec04adc514ad8
58e0e5f9667da0d453f8c8440027bcae
c704444177a8de47819063c957f7ac35
3463c2d61deb9406799d0fad448f8941
d484fa04b37d6be97e33acd3d1b8260c
836bdc3bba7814e693b8ee886fab4e2f
3501f1482d1c8d2710e3186f8155d434
95301361b8bf68c4d2c1f15f0eadd526
86cfbcf1659ab9bb0b4decc46c24b471
7164a2824aaa4aef56734c5086f5f571
b0ed86119b14c78a1fc7e38eb3dfab4d
924ae1213179d2401b36604907c005fc
9eb5f0a0f0b4c16833f14f0ebc5240eb
-----END OpenVPN Static key V1-----

in the first line. The process for running the tool is the same as openssl-blacklist. Once you have checked all applicable keys, your systems should be in far better shape.

Conclusion

Why is this a critical vulnerability? Because with the ease of brute forcing the keyspace, not only can an attacker eavesdrop on supposedly secure communications, but they can also decrypt any sessions which they may have recorded through, say, tcpdump or wireshark.

I got back on the 14th, and was fighting jetlag the entire week. Last weekend, the kids came over to celebrate my birthday,  and this week have been in SAP training. So I will get that segment re-recorded as soon as possible, and get it out.

In essence, any keys or certs that were either compromised or unknown status and were created between Sep 2006 and May 2008 were deleted and recreated. In the immortal words of Ripley in Aliens, “I say we take off and nuke the entire site from orbit. It’s the only way to be sure.”

I will give a step-by-step of the process that I used to update in episode 1, which should be out this week.

In any case, I will make a real effort to release the episode this week.