> If we get a response that's longer than the 3 bytes of data we actually sent (as opposed to the 16384 bytes we claimed we sent) then the server is vulnerable and the extra data sent back is part of the contents of the memory of the server.
Not necessarily. The server could run a custom patch that fills the buffer with /dev/urandom. You might still find user secrets in that buffer as well as a full Shakespeare work if you try hard enough.
That said, I don't see why one would do that, except perhaps to waste attackers resources trying to check all the returned garbage for potential private keys.
I set up something similar as a honeypot, to see who was out scanning. I made the heartbeat response "leak" a fragment of an HTTP request with a username and password, as well as a (freshly generated) DER encoded RSA private key. For fun, I also set up a second honeypot elsewhere that returns ASCII art [1].
Sadly so far I haven't gotten any nibbles. I think I set it up a bit late though (Thursday evening) so perhaps the mass scans had already given way to targeted attacks.
Additionally, even if you send a heartbeat message with the correct length (3), you will ALWAYS get > 3 bytes because OpenSSL pads the response with 16 bytes of random data.
Sure, I simplified things a little bit for clarity. The aim was really to get away from people just looking at the block of hex and seeing 'magic'. :-)
One important thing to realize about the PoC -- if you change "40 00" to "FF FF" or similar, it may seem that you still only get 16KB back. In fact (in violation of the TLS spec) OpenSSL is just fragmenting heartbeat message into multiple packets. If you modify the script to read and print heartbeat responses in a loop, you can get the full 64KB mentioned in the advisory.
That's a very good point (and easy to change in the code). When I was thinking about what to write I considered making a modified version of the PoC that was a bit more readable and adding a few tweaks like handling different TLS versions but in the end I decided that explaining it as-is would be worthwhile in itself.
6 comments
[ 3.1 ms ] story [ 27.8 ms ] threadNot necessarily. The server could run a custom patch that fills the buffer with /dev/urandom. You might still find user secrets in that buffer as well as a full Shakespeare work if you try hard enough.
That said, I don't see why one would do that, except perhaps to waste attackers resources trying to check all the returned garbage for potential private keys.
Sadly so far I haven't gotten any nibbles. I think I set it up a bit late though (Thursday evening) so perhaps the mass scans had already given way to targeted attacks.
[1] https://twitter.com/moyix/status/453760960671383552