Linux Podcasters Unite!

September 23, 2008 on 10:28 am | In Blog | No Comments

A new project is taking shape, an aggregator for Linux podcasts. Currently there are two sections…One for blog posts and one for podcasts. Check them out at

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

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

Show notes for Episode 1

September 23, 2008 on 10:19 am | In Blog, Show Notes | No Comments

Recently, the Debian project announced the existence of a couple of major vulnerabilities, specifically, DSA-1571 and DSA-1576, which were on openssl and openssh, respectively. These were for a predictable pseudo-random number generator within openssl. The random number generator, due to a patch that was put in place in Sept 2006, severely limited the randomness of the numbers generated. Instead of billions or trillions of combinations, there are thousands. This means an attacker is able to brute force keys in only a few hours instead of thousands or tens of thousands of years. Applications which depend on these random numbers for communication security, including openssl, openssh and openvpn, need to be upgraded . Keys generated with the suspect random number generator must be regenerated. I also want to note that this applies to all Debian-based distros, including Ubuntu/Kubuntu/Xubuntu, Linux Mint, any deb-based installation.

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.