Heartbleed vulnerability in OpenSSL

[AMED]

Looks like doom9.org and forum.doom9.org might be affected by the heartbleed vulnerability.


http://filippo.io/Heartbleed/#www.doom9.org
http://filippo.io/Heartbleed/#forum.doom9.org

http://heartbleed.com/

[Doom9]

Thanks for reporting - I already asked the admin to update and regenerate the certificate we use for encrypted connections. Once this is done (I'll report it here), you should consider changing your password (at least if you were using HTTPs to visit the forum - if you used HTTP, the whole thing doesn't matter).

[LoRd_MuldeR]

Indeed, it doesn't matter if you are using plain HTTP. In that case you are sending your login data over the wire in a completely unencrypted way anyway, which means the bad guy doesn't need any fancy attack to steal your login ;)

BTW: The big problem with the "Heartbleed" vulnerability is not that the attacker can eavesdrop a specific HTTPS connection, e.g. to steal a user's password during the login. It's even worse than that: The OpenSSL bug actually allowed the attacker to request a dump of the server's internal memory, which the server did happily send back to the attacker. Although the attacker could only request 64 KB at a time, this could be repeated many times - allowing the attacker to dump pretty much any secret that might be held in the server process' memory, such as the server's private signing key! That's why any certificate issued by an affected server has to be consider compromised from now on and should be replaced. Ouch!

[foxyshadis]

To dump your password md5 hash (raw password isn't stored or transmitted anywhere), it would have to get lucky and get it just after you logged in, at exactly the right spot, before any other activity used it.

More dangerously, since the md5 hash is equivalent to a password for login purposes here, it basically is transmitted in plaintext; even if you don't know the password that'll still get you logged in, and md5 is pretty trivially crackable now anyway. Good enough for SSL, not so much for HTTP.

The login page could be trivially extended to use the existing securitytoken value as a salt. Aside from that, 3.8.5 is pretty out of date, at a minimum 3.8.7 PL3 + the various patches (http://www.vbulletin.com/forum/forum/vbulletin-announcements/vbulletin-announcements_aa/4024547-security-exploit-patched-in-versions-3-5-3-6-3-7-3-8-4-x-5-x-of-vbulletin) should probably be installed.

Probably not cause to force a mass reset.

[Doom9]

The server has been patched and the certificate regenerated (it's still self signed though).. so if you want to change your password, now is the time (and of course, there's no point in doing so unless you connect via https).

[LoRd_MuldeR]

To dump your password md5 hash (raw password isn't stored or transmitted anywhere), it would have to get lucky and get it just after you logged in, at exactly the right spot, before any other activity used it.

Just for clarification: While the server will store only a (salted) hash of the user's password in its internal DB, the user will still need to send his password over the wire in order to log in. The server will then compute a hash of the user's input and compare it to the expected value stored in the DB. So if the user logs in via plain HTTP (not HTTPS), his password is transmitted over the wire in plain text and could be "stolen" trivially, as a simple Wireshark dump shows:

http://i.imgur.com/zRPQQcXs.jpg (http://i.imgur.com/zRPQQcX.jpg)

(Transmitting a hash of the password instead of the password itself would only mean that the hash is now your login "secret", i.e. you would still be sending your "secret" over the wire as plain text)

The server has been patched and the certificate regenerated (it's still self signed though).. so if you want to change your password, now is the time (and of course, there's no point in doing so unless you connect via https).

Okay, thanks. Have changed my PW now.

But unfortunately the server still seems to be using OpenSSL v1.0.1e (see screenshot above). I think this should have been updated to v1.0.1g by now :confused:

[nevcairiel]

But unfortunately the server still seems to be using OpenSSL v1.0.1e (see screenshot above). I think this should have been updated to v1.0.1g by now :confused:

Many Linux distributions backported the fix into whatever version of OpenSSL they ship, instead of updating to the new version.
I can confirm that the webserver hosting forum.doom9.org is not vulnerable anymore, thanks for fixing it.

[LoRd_MuldeR]

Many Linux distributions backported the fix into whatever version of OpenSSL they ship, instead of updating to the new version.
I can confirm that the webserver hosting forum.doom9.org is not vulnerable anymore, thanks for fixing it.

Thanks for clarification!

[foxyshadis]

Just for clarification: While the server will store only a (salted) hash of the user's password in its internal DB, the user will still need to send his password over the wire in order to log in. The server will then compute a hash of the user's input and compare it to the expected value stored in the DB. So if the user logs in via plain HTTP (not HTTPS), his password is transmitted over the wire in plain text and could be "stolen" trivially, as a simple Wireshark dump shows:

http://i.imgur.com/zRPQQcXs.jpg (http://i.imgur.com/zRPQQcX.jpg)

(Transmitting a hash of the password instead of the password itself would only mean that the hash is now your login "secret", i.e. you would still be sending your "secret" over the wire as plain text)

The login form uses some javascript magic to convert the password field into an (unsalted) md5 of your password as long as JS is enabled, but yeah, it's still a repeatable secret.

Whether or not the hash is even salted on the database side is unknown. Older versions of vB didn't do that by default, and doom9 has been around for a very long time. Only swede could tell us how it's all set up.

[Doom9]

I didn't bother to check the source (the forum is fully paid up so I have everything), however, I checked my own password hash in the database and ran md5 and sha-1 hashes on my password and the output doesn't match... so I presume the salt field that is filled with some random value is used for hashing the password.
I can't say for certain (I don't have the earliest vbb versions anymore) whether this always was so for users that signed up back when we started, but if you change your password now, it seems to get salted.