Hijacking user sessions with the Heartbleed vulnerability

The Heartbleed issue is actually worse than it might immediately seem (and it seems pretty bad already).

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.

So why is Heartbleed worse than you think? It’s simple: the currently-available proof-of-concept scripts allow any client, anywhere in the world, to perform a session hijacking attack of a logged in user.

As of this morning, the most widely-shared proof-of-concept is this simple Python script: https://gist.github.com/takeshixx/10107280. With this script, anyone in the world can dump a bit of RAM from a vulnerable server.

Let’s have a look at the output of this utility against a vulnerable server running the JIRA ticket tracking system. The hex output has been removed to improve readability.

[[email protected] ~]# python heartbleed.py jira.XXXXXXXXXXX.com
 Sending Client Hello...
 Waiting for Server Hello...
 ... received message: type = 22, ver = 0302, length = 66
 ... received message: type = 22, ver = 0302, length = 3239
 ... received message: type = 22, ver = 0302, length = 331
 ... received message: type = 22, ver = 0302, length = 4
 Sending heartbeat request...
 ... received message: type = 24, ver = 0302, length = 16384
 Received heartbeat response:
[email protected] /browse/
(lots of garbage)
 cept-Encoding: g
 e: en-US,en;q=0.
 8..Cookie: atlas
WARNING: server returned more data than it should - server is vulnerable!

This is definitely a dump of memory from a GET request that came in very recently. Did you notice the JSESSIONID cookie up there? That’s JIRA’s way of tracking your HTTP session to see if you are logged in. If this system requires authentication (and this JIRA install does), then I can insert that cookie into my browser and become that user on this JIRA installation.


After saving the modified cookie, we simply refresh the browser.


As you can see above, once we’ve taken a valid session ID cookie, we can access this JIRA installation as an internal employee. The only way to detect this type of attack is to check the source IPs of traffic for each and every request. It’s also worth noting that JIRA happens to be the software I chose for this demonstration, but the issue effects any web service that uses cookies to track the session state (almost every site on the Internet).

The Heartbleed vulnerability is bad, and with almost no effort allows a remote attacker to potentially perform a session hijacking attack allowing authentication bypass. Please patch your systems immediately.