Heartbleed (OpenSSL security vulnerability)

[erikun]

Has everyone heard about this yet? It is apparently a recently discovered security vulnerability with OpenSSL, a popular form online encryption. It allows people to retrieve information and code from websites, taking information from a server's active memory. Still, it's more informative to simply give you the relevant articles.

The Wire (http://www.thewire.com/technology/2014/04/what-you-need-to-know-about-heartbleed-the-new-security-bug-scaring-the-internet/360366/)
Los Angeles Times (http://www.latimes.com/business/technology/la-fi-tn-tumblr-change-passwords-heartbleed-https-20140408,0,4912342.story)
Lifehacker website (http://lifehacker.com/what-the-heartbleed-security-bug-means-for-you-1560801201) for a bit more information about it.

The Wire has linked to this incomplete list (https://github.com/musalbas/heartbleed-masstest/blob/master/top1000.txt) of websites affected, with Yahoo being one of them. Lifehacker has more information (http://lifehacker.com/lastpass-now-tells-you-which-heartbleed-affected-passwo-1561522244) about Heartbleed, including a tool (https://lastpass.com/heartbleed/) for checking if a website is vulnerable.

http://heartbleed.com (http://heartbleed.com/) has been set up to provide information about the bug.

The recommendation has been to change your password, or at least ensure that the vulnerability has been patched and then change your password. A patch that fixes the bug has been released. I'm also wondering if this forum has any potential vulnerability to the bug, or if it needs to receive the OpenSSL patch as well.

[EDIT]
Regarding the last part, this was answered in the Board/Site Issues forum (http://www.giantitp.com/forums/showthread.php?340321-OpenSSL-Bug-Heartbleed) with a very clear "No."


1) Your authentication for the forums has never used SSL, it uses a different method. Your password has never been vulnerable to heartbleed.

2) Additionally, the server has never been vulnerable to heartbleed anyway.

[Grinner]

I'm curious as to how this vulnerability works. SSL is used to encrypt connections, so while it's far from impossible, it's definitely unusual for this sort of behavior to manifest.

Maybe it makes a sort-of malformed connection with the server?


A patch that fixes the bug has been released. I'm also wondering if this forum has any potential vulnerability to the bug, or if it needs to receive the OpenSSL patch as well.

Because this site doesn't use HTTPS, I don't see how that would be a problem.

[erikun]

I'm curious as to how this vulnerability works. SSL is used to encrypt connections, so while it's far from impossible, it's definitely unusual for this sort of behavior to manifest.
This website (http://gizmodo.com/how-heartbleed-works-the-code-behind-the-internets-se-1561341209) goes into detail about what exactly happens with the Heartbleed bug.

Basically, two computers stay connected over a HTTPS connection by passing information between one another. The computer receives some random information, copies it into memory, then grabs that information from memory and sends it back. This is called a "handshake" or "heartbeat". The bug works by (falsely) requesting more information than is needed, meaning that the hacker gets not only the random information that is sent, but also a big chunk of information that was in computer memory as well.

One important thing to know is that computer memory is never actually "empty" while the computer is running. Data is stored in memory, but isn't erased when no longer used. Rather, computers simply tag the memory as "junk data" and allow the computer to overwrite it when that part of memory is needed. (This is how deleted files on your harddrive work as well, and why it is possible to recover a deleted file.) The bug makes the server return this "junk data" still in memory, which can include passwords and other important information. And while there is a limit to how much data a person could get with a single "heartbeat", there is no limit to how many times that person could request it.



From what I've seen, the earliest time anyone discovered the bug was two days ago, on the 7th. OpenSSL 1.0.1 through 1.0.1f is vulnerable, as is 1.0.2-beta. OpenSSL 1.0.1g is not vulnerable and contains the patch, and so anyone with the above OpenSSL versions should upgrade to OpenSSL 1.0.1g. 1.0.2 will be fixed in 1.0.2-beta2, but hasn't been patched yet. Here is the statement from the OpenSSL website saying exactly that. (https://www.openssl.org/news/secadv_20140407.txt)

[Grinner]

Basically, two computers stay connected over a HTTPS connection by passing information between one another. The computer receives some random information, copies it into memory, then grabs that information from memory and sends it back. This is called a "handshake" or "heartbeat". The bug works by (falsely) requesting more information than is needed, meaning that the hacker gets not only the random information that is sent, but also a big chunk of information that was in computer memory as well.

So it's kind of the inverse of a buffer overflow attack?

[erikun]

So it's kind of the inverse of a buffer overflow attack?
Kind of, yes. They've both related to mismanaging computer memory, although buffer overflow involves saving to memory it shouldn't and Heartbleed involves retrieving memory it shouldn't.

[Kariccia]

I did some (http://arstechnica.com/security/2014/04/critical-crypto-bug-exposes-yahoo-mail-passwords-russian-roulette-style/) looking (http://blog.cryptographyengineering.com/2014/04/attack-of-week-openssl-heartbleed.html). It looks like it's just a simple "lacking a bounds check" bug. The "heartbeat" length is 16bit variable. That's why there's a limit to how much info a heartbeat message can provide.

[IthilanorStPete]

Heard about it. I've been meaning to start using a password manager anyways; this just gives me the impetus to go ahead and do it.

EDIT: After a bit of looking around, LastPass seems to be well-regarded. Any thoughts?

[erikun]

I'm also wondering if this forum has any potential vulnerability to the bug, or if it needs to receive the OpenSSL patch as well.
In case anyone was wondering, this was answered in the Board/Site Issues forum (http://www.giantitp.com/forums/showthread.php?340321-OpenSSL-Bug-Heartbleed) with a very clear "No."

1) Your authentication for the forums has never used SSL, it uses a different method. Your password has never been vulnerable to heartbleed.

2) Additionally, the server has never been vulnerable to heartbleed anyway.

[Zrak]

I feel like I've mostly done my due diligence with regard to changing passwords on sites confirmed as patched and so on, with the exception of not being sure what to do about Netflix. I get conflicting information when I search for it or test it, and can't find anything about what kind of SSL it used. Anybody happen to know one way or the other?

[Palanan]

Originally Posted by erikun
Basically, two computers stay connected over a HTTPS connection by passing information between one another. The computer receives some random information, copies it into memory, then grabs that information from memory and sends it back. This is called a "handshake" or "heartbeat". The bug works by (falsely) requesting more information than is needed, meaning that the hacker gets not only the random information that is sent, but also a big chunk of information that was in computer memory as well.

One important thing to know is that computer memory is never actually "empty" while the computer is running. Data is stored in memory, but isn't erased when no longer used. Rather, computers simply tag the memory as "junk data" and allow the computer to overwrite it when that part of memory is needed. (This is how deleted files on your harddrive work as well, and why it is possible to recover a deleted file.) The bug makes the server return this "junk data" still in memory, which can include passwords and other important information. And while there is a limit to how much data a person could get with a single "heartbeat", there is no limit to how many times that person could request it.

I've been reading articles and listening to news reports on this issue all day, and you've explained this aspect of it better than anyone else I've seen.

Thank you, and nicely done.

[Slipperychicken]

So we only need to change our passwords on sites which use HTTPS?

[Mando Knight]

So we only need to change our passwords on sites which use HTTPS?

No. You need to change your passwords on everything that had to patch OpenSSL (not all Internet security is OpenSSL... Microsoft, for example), and then if you reuse your password (like 90% of the Internet does), change your password for everything that shared the old password with the vulnerable site, but only change your password on vulnerable sites after they patch OpenSSL (otherwise, your new password could be stolen just as easily as the old one).

That is, if you suspect that you're at risk of being snooped. Due to how Heartbleed works, there's no way of verifying if any particular person had their passwords stolen.

If you use Steam, it was affected and was patched fairly promptly.

[Sith_Happens]

Do you have to have logged into or otherwise used a website recently for your information to be vulnerable? I'm wondering if I need to change the password on my Gmail that I haven't touched in years.

[Grinner]

Do you have to have logged into or otherwise used a website recently for your information to be vulnerable? I'm wondering if I need to change the password on my Gmail that I haven't touched in years.

I've been wondering about that as well. Since it was only recently discovered by Google and because it's such a subtle hack, it's possible that people have been using it for years. However, to gain your account credentials, the attacker has to be actively monitoring your connection with the server's key in hand.

[pendell]

There are white-hat sites which will determine whether a given web site is vulnerable or not. example (http://filippo.io/Heartbleed/).

Happily, openssl is not the only ssl implementation available, and at least some of them are not affected.

Respectfully,

Brian P.

[Mando Knight]

However, to gain your account credentials, the attacker has to be actively monitoring your connection with the server's key in hand.

They didn't need any keys to exploit Heartbleed. That's why it's such an important exploit to stop. It uses a buffer underflow to skim the server's memory, ~64kb at a time, and if it finds the keys in one of those sections, the intruder can stop using Heartbleed, and simply intercept or spoof encrypted messages. Here's a video to help explain:

https://www.youtube.com/watch?v=rE5dW3BTpn4

[Grinner]

They didn't need any keys to exploit Heartbleed. That's why it's such an important exploit to stop. It uses a buffer underflow to skim the server's memory, ~64kb at a time, and if it finds the keys in one of those sections, the intruder can stop using Heartbleed, and simply intercept or spoof encrypted messages. Here's a video to help explain:

I believe there's a misunderstanding here.

My point was that Heartbleed can be used to obtain the key the server uses to encrypt packets for a given connection. That key can then be used to decrypt the packets flowing between the server and the user, possibly revealing account credentials (i.e. when the user sends his username and password in cleartext to the server).

I suppose you could also look directly at the password in memory (as it's being hashed), but I'm not certain how easily that could be connected to any given username. It could be analogous to writing the passwords down and mixing them into a hat with every other user, hoping you pull the right one.

[Sallera]

Could be done pretty easily, depending on the authentication implementation in question. Note the second two images in the Ars article - the data the researcher pulled has login=___&passwd=____ right in the retrieved memory. The key's the ongoing threat, but there appears to be plenty of opportunity to simply grab sensitive data directly.

[Whoracle]

For what it's worth: There's testing kits around to see if a given server is heartbleed vulnerable. The whole exploit can comfortably be done with 153 lines of python, including whitespace and empty lines.

One thing that gets overlooked as well: Quite a few websites encode things like SESSIONID in GET, even though they really shouldn't. That's something that you have to do if you do cross-session tracking of users, like, for example, the master account for several subaccounts. Log in as master, then, log in without password as subaccount, because you are the master, but the system might still want to track that this isn't a regular login by the subaccount, so it passes the SESSIONID into the new session. This is clear text readable as well, so you can easily hijack sessions. From my tests, I _think_ have seen session cookies in the dumps as well, so you could easily forge a cookie. Haven't tested that, because my servers are not vulnerable and I'm not going to hijack a session on $random_website just for the lulz, but if anyone still has a vulnerable server somewhere, you could test for that, too. It's insane how much info you can get from those 64k.

Also, I've heard quite a lot of guys talking how "they only use SSL/TLS for their admin login anyways, and they haven't logged into the admin backend in months...": Great, so the last login is still in memory, and since you only login as admin, admin credentials are ALL that's going to be in there...

What really bugs me about that is that the heartbeat function that gets exploited is useless in the first place. Keepalive is implemented in the TCP layer below all that, so there's no need to implement it again. Granted, UDP doesn't have it, but since UPD is by definition not feasaible for a transport layer, you don't need it there. It's completely useless. And still someone implemented it, someone else waved it through, and, worst of all, most of the major distributions out there kept it enabled as default, which then hurts the users... *sigh*

Overall, heartbleed is a really interesting piece of bug, because the severity of the bug itself is quite low*. This just goes to show that the standards for classifying bugs should be looked at again.

* I can go into more detail on this if people want, but it gets a bit more technical

[JeenLeen]

A good (?) explanation of the bug: http://xkcd.com/1354/

It sounds accurate according to the technical stuff I've heard, but this isn't my area of knowledge. I think this comic explains the technical stuff easily to a layperson.

[Kariccia]

It's accurate. That's what's happening.

[Whoracle]

For everyone that's hosting their own website and providing SSL: Revoke your certificates and generate new ones. It has now been challenged (https://www.cloudflarechallenge.com/heartbleed) as well as proven (https://twitter.com/indutny/status/454773820822679552) that you can relatively easily extract server private keys via heartbleed outside of carefully monitored lab setups, so anyone using this exploit before is likely to also have your private SSL key, and can thus just play man in the middle as he wants to.

Still doesn't affect GiantITP.

Another thing that I noticed: Even if your webserver didn't serve anything over SSL, there's still data in that SSL memory block if the server is listening on an SSL-enabled port. Confirmed that on a testserver yesterday. This is at least valid on a setup with Apache 2.4, and most likely with lower versions, too. So even if you didn't serve an SSL site, if you have/had "Listen 443" somewhere in your httpd.conf or its includes, and if your server was vulnerable to heartbleed in the first place, you might have leaked stuff.

[pendell]

For everyone that's hosting their own website and providing SSL


Clarification: Using openSSL to provide SSL. There are other libraries, such as the APR libraries provided with Tomcat, that also implement SSL but are not impacted by Heartbleed.

Respectfully,

Brian P.

[Whoracle]

Clarification: Using openSSL to provide SSL. There are other libraries,[...]

Absolutely true, should have clarified.


such as the APR libraries provided with Tomcat, that also implement SSL but are not impacted by Heartbleed.

Half true. See stackexchange (http://security.stackexchange.com/questions/55139/does-the-heartbleed-vulnerability-affect-apache-tomcat-servers-using-tomcat-nati).
Tomcat with APR still uses OpenSSL as underlying library, depending on the environment. So, unless you are ABSOLUTELY sure that no part of your application/server environment links against openSSL, revoke your certs. Also, of course, google for hb-test.py and check your machines for something you might have overlooked.

Why the hb-test.py, you ask? Well, if I assumed my server was vulnerable, the last thing I'd do is to go to some website, enter my (most likely vulnerable) URL/IP and let them check it. Not if I can get a 150 lines python script that I can audit myself and that gives me the same results without me having to trust someone else :-)

tl;dr: Pendell has a very good point, but Tomcat with APR CAN STILL BE VULNERABLE.

[pendell]

You're right, I should have clarified. As discussed in Tomcat's howto (https://tomcat.apache.org/tomcat-7.0-doc/ssl-howto.html), Tomcat can be configured to use openSSL or JSSE to implement SSL, depending on the connector you choose in server.xml. JSSE is not vulnerable to heartbleed (http://scn.sap.com/community/bi-platform/blog/2014/04/11/testing-for-heartbleed-vulnerability-for-the-bi-platform).

Respectfully,

Brian P.