Matt's Life Bytes
Matthew Sullivan's Thoughts on Security & Tech



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: 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
 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.

Insertion of the session ID cookie into the browser.

Insertion of the session ID cookie into the browser.

After saving the modified cookie, we simply refresh the browser.
Insertion of the session ID cookie into the browser.

Reload of the JIRA installation. Note that we are now logged into this installation.

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.

· · ·


  • Camillus · April 8, 2014 at 10:28 am

    Can confirm. I’ve managed to do this as well. This seems to affect nginx more than apache, probably due to its event-driven nature. (

  • Galich · April 8, 2014 at 11:39 am

    Any proof that IIS/IIS Express is vulnerable as well?

  • Max · April 8, 2014 at 12:06 pm

    I’ve tried editing a cookie with the cookie/session ID info I found and refreshed, but nothing happened? What did I do wrong?

  • Admin comment by Matthew Sullivan · April 8, 2014 at 12:28 pm

    IIS is not vulnerable, as it does not utilize the OpenSSL library. Not all cookies will be logged in, as many webapps set a session cookie even if the user isn’t authenticated. It’s luck of the draw.

  • rb · April 8, 2014 at 3:01 pm

    Can confirm as well. Managed to get into someones account simply using session id and visitor id from output, on fairly popular website.

  • Matthias · April 8, 2014 at 4:52 pm

    @Camillus: this has nothing to do with any “apache vs nginx” battle, both are affected equally as the problem is one level down below (both just use openssl).

    Still, this totally beats “goto fail” in my book of epic fail!

  • jcran · April 8, 2014 at 4:56 pm

    Good stuff. One clarification.

    This is ‘session hijacking’ not ‘session sidejacking’. Session hijacking is much worse, as it can be performed from an endpoint, and does not require a MitM attack.

  • Admin comment by Matthew Sullivan · April 8, 2014 at 5:24 pm

    You are absolutely right. Fixed – thanks Jon!

  • Gymmy · April 8, 2014 at 6:55 pm

    ok so we are looking at servers, but how about the SSL in routers and switches ? what is the likely hood the attacker is going to be able to dump out the memory of these devices ?

  • Craig Davies · April 8, 2014 at 8:02 pm

    Hey, great post. We’re all spending a lot of time solving this issue.

    I just wanted to add that JIRA itself is not susceptible to this bug, it’s an Infrastructure issue. To clarify our state, we have published our thoughts on

  • Admin comment by Matthew Sullivan · April 9, 2014 at 10:06 am


    I have added a clarification at the bottom of the blog post.

  • Bachi · April 11, 2014 at 3:30 am

    I’ve set up a heartbleed demo server at that’s vulnerable (and even has a script to ‘attack itself’ and show the output. Search for the PHPSESSID cookie if you want to test the session hijacking (in a legal way).

  • ad^2 · April 11, 2014 at 1:04 pm

    Thanks for the contribution. It really helps to make things clearer seeing real output from a vulnerable server. It’s Friday and I finally get to put Nessus and Metasploit to sleep on my networks. It’s been a fun week.


  • rolloff dumpsters Austin · June 15, 2014 at 9:37 am

    I want to to thank you for this very good read!!I definitely
    loved every bit of it. I have you book-marked to check out new things you post…

  • Heartbleed maliciously exploited to hack network with multifactor authentication | Computero · January 12, 2015 at 1:07 pm

    […] the bug less than a day after it became public knowledge. A separate researcher theorized such an attack was possible the same […]

  • chestionare auto · April 6, 2015 at 1:36 pm

    Here are multiple driving test questions for you to try for free while you prepare.

    Chestauto offers you the largest set for your driving license .

    You can test yourself online at the link below: and get the higher score at the end of practicing.
    Don’t waste your time learning on your own. Chestauto is the key of
    your source driving license tests and the answer of your positive final

  • · May 12, 2015 at 12:50 pm

    Wow! In the end I got a weblkog from where I be able to actually
    obtain useful data regarding my study and knowledge.

  • The Definitive Guide to Heartbleed and Enterprise Mobility | Matias Vangsnes · November 3, 2015 at 8:29 am

    […] An example of which is running the Python proof of concept against a vulnerable JIRA ticketing system and pulling out a JSESSIONID (which is JIRA’s way of tracking your HTTP session). If the system requires authentication then you can just insert the stolen cookie into the browser and become that user on the JIRA installation. ( […]

  • minimon masters save file · December 14, 2015 at 9:51 am

    Greate post. Keep posting such kind of info on your site.
    Im really impressed by it.
    Hello there, You have performed a great job. I’ll certainly
    digg it and for my part recommend to my friends.
    I’m sure they will be benefited from this site.

  • 83Dwight · July 30, 2017 at 11:56 pm

    Hello admin, i must say you have very interesting content here.
    Your page can go viral. You need initial traffic boost only.
    How to get it? Search for: Mertiso’s tips go viral

Leave a Reply


Theme Design by