We have been having some »fun« with the Debian OpenSSL debacle last week. Having read the advisory and realized that the SSH list of vulnerable keys was for public exponent 35, we went on to compile our own list of vulnerable keys with public exponent 65537 (the one most often used in certificates).

On Thursday, we then checked all the CAs with exponent 65537 and key length 1024 or 2048 bits — luckily none of them was affected (all hell would have broken loose if one would have been) ... We checked a few HTTPS webservers, and after the 70th invocation or so, we stumpled over an affected webserver at a major german financial institution. Luckily, the security scene is small, so my boss knew someone in the security team and called him up. The dialogue: »Are you sitting down? ... Good. We know the private key to your webserver« led to some laughter on our side. Kudos to them, though, the problem was fixed about 2-3 hours later. I call that pretty quick for a production system (the new certificates were actually issued 15-30 minutes after we called).

One thing that has not been widely noted (expect for by my boss, who came up with this scenario) is that you also might want to consider your passwords compromised if they were transmitted in an SSH session where one participant had a weak OpenSSL installation. Why so, you ask? The SSH session starts with a Diffie-Hellmann key exchange. In short, the client calculates a random x and sends g^x to the server. The server in turn computes a random y and sends g^y to the client. Knowing x, the client can compute (g^y)^x = g^(y*x) = g^(x*y). The server knows y, so he can compute (g^x)^y = g^(x*y). This is now their shared secret which will be used to encrypt the further communication — including the transmission of the password, if you use password-based authentication.

Now assume someone has been listening in on this key exchange and that either the client or the server was running a vulnerable OpenSSL. Without loss of generality (hah, I didn't think I'd use that mathematician phrase ever again), let's assume it is the client. In this case, the pseudo random number generator is flawed and x is not truly random but only one of 16k possible values. If we know all of them (they are pretty trivial to generate, possibly much faster than the list of RSA keys), we can have a look at g^x for all x and see if the result matches the value sent by the client to the server. We then know x and are thus in the same position as the client and we are able to decrypt the complete session. This means that anything in that session (your login password for the SSH session, passwords for any other servers you might have logged into, database passwords you might have entered) is now in the hands of the attacker.

To make sure that we didn't make a mistake in our theoretical thoughts on this, I have patched my OpenSSH to output x, linked it with a vulnerable OpenSSL library and started it with the Metasplot LD_PRELOAD library. And indeed, for a fixed MAGIC_PID environment variable, a fixed x is generated. This was not so easy to see in Wireshark, because apparently the server decides on the group and sends it to the client. The groups and the generator differ from time to time, so the messages that are sent are different, too. For an attacker, this does not matter though, he just needs to do some more calculations for the different parameters.