3 ms·
> 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
by ithkuil 13y ago
> 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.
- moyix 13y agoI 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. [1] https://twitter.com/moyix/status/453760960671383552 https://twitter.com/moyix/status/453760960671383552
- schwap 13y agoAdditionally, 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.
- richm44 13y agoSure, 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'. :-)