How the Heartbleed vulnerability works

I’ve been reading about the Heartbleed bug, trying to understand how it does what it does, how a hacker could use the vulnerability to gain access to your data.

If you have not heard of Heartbleed, read this, which was posted last night.

Is Heartbleed bad?

In case you’ve been out of the loop, Heartbleed (CVE-2014-0160) is a vulnerability in OpenSSL that allows any remote user to dump some of the contents of the server’s memory. And yes, that’s really bad. The major concern is that a skilled user could craft an exploit that could dump the RSA private key that the server is using to communicate with its clients. The level of knowledge / skill required to craft this attack isn’t particularly high, but likely out of reach for the average script kiddie user.

I’m not well versed in this sort of thing, but here’s my take on how this works.

First, a script is run against a vulnerable server. The vulnerability allows a raw chunk of RAM to be retrieved from the server. The exploit is repeated until a chunk of RAM is retrieved containing a GET request. For the exploit to have value, the retrieved RAM has to also contain an authentication cookie. Different servers, different cookies.

Once a cookie is retrieved, you build a new request using that cookie and, since the cookie matches an existing session, your request is considered part of the existing session and you now have control over that session. Once you control a session, you are, in effect, logged in to the server.

If you see a hole in my explanation, please clarify in the comments for the benefit of other readers. This seems a pretty big hole to have skated through all this time.