Debian: Weak Cryptographic Keys
On May 13, 2008, a security advisory was issued, warning that Debian 4.0
("etch") Linux distribution contained a crippled random-number generator. As a
result, most cryptographic functionality was severely weakened. Unlike
most security vulnerabilities, simply updating the software on affected
machines is insufficient to close the security hole -- weak cryptographic
keys generated on the affected machines also need to be replaced.
ECE IT Services has taken the following precautions:
- Some servers have obtained new SSH host keys, resulting in warnings visible to users.
- Effective immediately, weak SSH keys are no longer accepted for authenticating to SSH servers. Affected users will need to regenerate their SSH RSA keys if they wish to log in user RSA keys instead of passwords.
- New 2006-06-10: DSA keys are no longer accepted for authenticating to SSH servers, even if they were created using a random number generator. Due to the way the Digital Signature Algorithm works, if a DSA key is ever used from a machine with a weak random number generator, an evesdropper can derive the DSA private key. If you have been using a DSA key, please create an RSA key instead, as the RSA algorithm does not have this weakness.
- We have re-issued all SSL certificates that contain weak keys. If you have installed the ECE Root Certificate, this should result in no visible change. Otherwise, your web browser will warn you about connecting to uncertified servers.
Actions Required of Users
Since Debian is widely used in the ECE Department, and this security hole affects even users who normally do not use a Debian 4.0 workstation, please feel free to ask help@ece.ubc.ca if you need guidance on what actions you need to take.
- If you use RSA or DSA keys to authenticate to SSH servers, and your key no longer works, check your ~/.ssh/authorized_keys file. If ECE IT Services has determined that your authorized_keys file contains a weak key or a DSA key, there will be a comment in that file indicating so. In that case, you should remove the key from ~/.ssh/authorized_keys, run ssh-keygen to generate a new RSA key, and add your new RSA public key to ~/.ssh/authorized_keys.
- If your SSH client warns you that the host key of the server you are connecting to has changed, you will need to accept the new host key.
The OpenSSH warning looks like this:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is 01:23:45:67:89:ab:cd:ef:01:23:45:67:89:ab:cd:ef. Please contact your system administrator. Add correct host key in ~username/.ssh/known_hosts to get rid of this message. Offending key in ~username/.ssh/known_hosts:123 RSA host key for server.ece.ubc.ca has changed and you have requested strict checking. Host key verification failed.
If you use PuTTY as your SSH client, then the warning looks like this:
Normally, you should heed the warning as an indication that an attacker may have intercepted your SSH session, but in this case the host key changes are legitimate. Use a text editor to remove the offending line from your known_hosts file.
For your convenience, ECE IT Services has already removed weak SSH host keys from all users' ~/.ssh/known_hosts files in their ECE home directories. As a consequence, you will see this (if using OpenSSH):
The authenticity of host 'server.ece.ubc.ca (137.82.1.1)' can't be established. RSA key fingerprint is 01:23:45:67:89:ab:cd:ef:01:23:45:67:89:ab:cd:ef. Are you sure you want to continue connecting (yes/no)?
Please check that the fingerprint matches the ones given below. Then and only then answer "yes" to continue.
SSH Server | Fingerprint of RSA Host Key |
---|---|
ssh-linux.ece.ubc.ca | 8e:95:cc:cf:66:9b:da:0f:67:72:28:94:a1:f7:33:1a |
atwell.ece.ubc.ca | 94:de:32:58:95:57:65:26:91:d7:d3:26:ea:75:91:df |
blake.ece.ubc.ca | 7d:b6:7d:d6:34:1e:a1:7a:e4:c2:02:f2:eb:77:f1:7b |
commlab32.ece.ubc.ca | 28:6c:22:85:6a:1a:c9:a6:d5:0b:cf:3b:9f:ce:0e:fc |
commlab33.ece.ubc.ca | 00:c1:e6:49:3e:2c:a4:d3:c1:5a:61:ba:cd:99:0c:76 |
dellped.ece.ubc.ca | e4:75:c7:56:ad:16:bf:22:0c:02:9c:63:a1:1b:9a:80 |
golomb.ece.ubc.ca | 6a:2c:d7:c0:3f:c7:f2:97:93:a5:78:df:a3:8a:b7:70 |
gould.ece.ubc.ca | 94:79:ae:07:15:6e:a9:83:a6:f4:36:c4:0d:96:cc:3e |
hct0.ece.ubc.ca | 49:34:b1:2b:97:be:02:cb:45:75:00:da:9d:62:68:07 |
isp-pc01.ece.ubc.ca | d2:63:1d:84:76:06:72:dc:9c:8a:09:b3:9d:62:a5:72 |
ito1.ece.ubc.ca | 67:5f:40:a0:11:de:77:41:14:52:2c:6e:d8:eb:cb:98 |
ito4.ece.ubc.ca | c2:ab:8b:63:b5:8d:08:a0:7e:7f:32:d2:a4:c9:8d:bc |
ito5.ece.ubc.ca | d5:af:b3:2b:0c:13:8c:d9:d0:46:92:5f:78:ba:b2:8c |
ito6.ece.ubc.ca | 56:85:16:7a:84:5d:e3:c3:76:60:ca:df:c6:cf:53:e0 |
jerry.ece.ubc.ca | 26:1c:72:bc:3e:9a:39:93:32:c5:47:42:2a:51:f0:2e |
kramer.ece.ubc.ca | 02:e2:65:09:b5:dd:6d:fd:0e:16:0b:a0:75:2a:70:c5 |
lampe1.ece.ubc.ca | 9f:5d:2f:19:ad:7c:bb:cc:ca:de:ac:8b:78:1f:27:3b |
lersse0.ece.ubc.ca | 07:af:7f:01:e7:ed:a1:fa:30:fb:28:fa:cc:b7:69:14 |
lvs1-r2.ece.ubc.ca | 8e:95:cc:cf:66:9b:da:0f:67:72:28:94:a1:f7:33:1a |
lvs1-r3.ece.ubc.ca | 8e:95:cc:cf:66:9b:da:0f:67:72:28:94:a1:f7:33:1a |
lvs1-r4.ece.ubc.ca | 8e:95:cc:cf:66:9b:da:0f:67:72:28:94:a1:f7:33:1a |
lvs1-r5.ece.ubc.ca | 8e:95:cc:cf:66:9b:da:0f:67:72:28:94:a1:f7:33:1a |
mach1.ece.ubc.ca | 80:96:e7:47:fb:1e:11:d8:3e:e3:1e:9c:df:5a:74:d8 |
mach13.ece.ubc.ca | a0:b8:a4:d8:be:ec:2f:23:1b:39:4e:f6:a4:b4:e4:4c |
mirabbasi2.ece.ubc.ca | 3c:64:ed:f4:96:ae:b4:b8:ba:e6:87:ba:f9:d3:be:2d |
morty.ece.ubc.ca | 08:5a:37:8a:ee:79:2e:47:74:7a:08:c3:72:ea:20:5e |
psserv.ece.ubc.ca | f0:29:7c:01:63:09:ea:52:67:d9:b9:c2:ad:57:63:32 |
rafeef1.ece.ubc.ca | b9:2f:5f:6c:4c:8b:3b:5a:85:f1:42:cc:c7:d0:b3:f7 |
rs-dell01.ece.ubc.ca | d1:88:0f:2e:1d:20:c5:ad:c1:19:46:ce:e3:24:67:48 |
rs-dell02.ece.ubc.ca | 78:25:8c:17:93:a6:87:9a:ca:79:93:6a:b2:11:08:72 |
rs-dell03.ece.ubc.ca | c6:63:85:34:9a:78:82:eb:b0:93:2d:04:dc:8c:5a:c0 |
rs-dell04.ece.ubc.ca | e1:89:02:0c:d1:b3:eb:fc:14:06:15:c2:0b:9a:ee:2c |
rs-dell05.ece.ubc.ca | 6b:db:9c:00:18:f9:56:d6:d1:f8:d3:f2:0f:37:1c:28 |
rs-dell06.ece.ubc.ca | d3:b5:1b:1e:1c:06:19:2a:9b:dc:7d:f7:40:4a:cd:50 |
rs-dell07.ece.ubc.ca | e6:17:8a:9e:84:8b:c4:68:29:d2:82:01:4a:90:fb:1e |
seal-hct.ece.ubc.ca | 7a:df:40:a6:ec:c6:94:bc:6a:36:a1:51:a5:34:b1:3d |
shannon1.ece.ubc.ca | 6a:3d:90:4d:87:6c:6c:60:8c:b3:60:95:48:a2:40:62 |
shannon2.ece.ubc.ca | 9f:e6:0d:77:d9:b3:be:06:51:55:90:37:fc:7d:9b:03 |
shannon3.ece.ubc.ca | 88:02:03:31:2a:06:52:e9:d9:c5:2f:54:41:4d:6f:5f |
shannon4.ece.ubc.ca | 04:4a:25:b5:5e:9b:aa:b0:a3:ed:38:ec:41:56:af:79 |
solomon.ece.ubc.ca | 9b:15:c5:95:0b:96:3d:50:ed:a4:20:06:da:a6:74:6d |
ssh-linux.ece.ubc.ca | 8e:95:cc:cf:66:9b:da:0f:67:72:28:94:a1:f7:33:1a |
vikram.ece.ubc.ca | eb:a7:91:1b:a1:da:49:20:ad:c0:dd:c3:47:e9:0a:7a |
vklinux1.ece.ubc.ca | 55:19:d5:fc:40:f0:8d:28:3f:96:3e:38:3f:28:a6:df |
vklinux3.ece.ubc.ca | ed:0f:a0:46:08:c3:df:36:ce:6f:b8:47:d7:e9:ce:15 |
vklinux4.ece.ubc.ca | f7:d3:d9:49:d0:13:ce:c9:77:2e:94:01:01:40:df:4e |
vklinux5.ece.ubc.ca | 43:ac:ca:8a:b1:e7:d1:7f:5d:ad:85:63:d7:e1:6c:d9 |
vwong-pc01.ece.ubc.ca | 9f:f1:d3:65:cb:92:78:49:e9:be:6f:dd:49:74:e7:fa |
xena4.ece.ubc.ca | 82:a0:50:16:5c:ec:a1:53:4d:46:21:ee:2d:19:0e:f5 |
xena6.ece.ubc.ca | 6f:0a:96:3a:aa:2c:ab:4b:60:0d:b6:2d:55:33:f7:69 |
zark4.ece.ubc.ca | 3c:03:56:5d:87:cf:59:c8:ea:41:2b:c2:fc:d3:a9:02 |
zark6.ece.ubc.ca | 77:bc:10:03:d5:d2:23:54:c3:40:c5:ba:cc:b0:b3:9b |
zark7.ece.ubc.ca | a1:cc:85:d0:c7:44:ac:1c:fc:62:5e:3f:14:7f:89:4a |
zark10.ece.ubc.ca | b2:dd:6b:3c:94:f7:f3:05:17:d7:61:17:d8:7a:38:03 |
Background
The principle behind cryptography is that the communicating parties share a secret key known only to them. If an attacker is able to guess what the secret key is, then he or she can decrypt the communications or impersonate one of the communicating parties. Therefore, secure cryptography requires random-number generators that generate keys that are hard to guess.
Normally, SSH keys are 1024 or 2048 bits long. An attacker taking the brute-force approach, trying every single possible key, would require 2{^1023} or 2{^2047} attempts on average before finding the right key.
It was recently discovered that Debian 4.0 ("Debian etch") and Debian-derived Linux distributions (such as Ubuntu) shipped with an OpenSSL package that was mistakenly modified in such a way that its random-number generator produced extremely predictable output. The random-number generator only had 16 bits of randomness, and 2{^16} is much much smaller than 2{^1024}. In Linux, most services rely on the OpenSSL library for cryptographic functionality.
The greatest risk to ECE servers is that an attacker could try logging in with all of the known weak keys resulting from the crippled random-number generator and have a high probability of finding one of the 2{^16} keys within minutes, without having to guess account passwords or SSH key passphrases. Therefore, ECE IT Services has disabled known weak keys in ~/.ssh/authorized_keys files.
Another possible risk is that an attacker could set up rogue servers pretending to be ssh-linux.ece.ubc.ca or www.ece.ubc.ca. This is a more difficult attack to execute, but ECE IT Services is taking the precaution of changing weak SSH host keys and SSL certificates.
There are also less likely risks. If an attacker had been evesdropping on network traffic, he or she could decrypt SSH or HTTPS sessions that took place in the past. Also, any DSA SSH keys that have ever been used with vulnerable SSH servers could be compromised due to the way the DSA protocol works.