This is one of the most scary bugs I have seen in the last few years. A lot of discussion is going on and there are quite a number of blogs regarding this. But I couldn't find anything that explicitly talks about the vulnerability and exploitation methods. Also many organizations have multiple https servers using openssl. So I have created this mas auditing tool that could scan them all in one click.

The vulnerability lies in the implementation of TLS Heartbeat extension. There is common necessity
in an established ssl session to maintain the connection for a longer time. The HeartBeat protocol extension is added to TLS for this reason. The HTTP keep-alive feature does the same but HB protocol allows a client to perform this action in much higher rate.

In the above code memory is allocated from the payload + padding which is a user controlled value. There was no length check for this particular allocation and an attacker could force the Openssl server to read arbitrary memory locations.

The total length of a HeartbeatMessage does NOT exceed 2^14 or max_fragment_length when negotiated as defined in [RFC6066]. Here we are only able to leak 64 kb of memory and that could easily have usernames/password etc. Even though openssllib has loaded the server secret keys somewhere in memory it very unlikely to access that using this bug due the the heap allocations.

Constant HB request could be made to the server leaking (random memory) any amount of data from the server .

The fix to this bug was to simply bound check the payload + padding length to not exceed 16 bytes .

I have created a Mass Auditing tool. So that you can give in a huge range of targets as a list and the tool would find important informations for you. Give it a list of targets and it would detect the vulnerability and list out if any username password is found.