<i>This should be a useful tool on its own, but I wrote it primarily because the pattern-matching rules for Snort are inadequate. IDS vendors won't fix their stuff until I can prove they are inadequate.</i><p>Ugh. In the old days the mantra of full-disclosure was "well, if we don't make exploit tools, then the vendors won't issue patches." And then it became "well, if we don't make exploit tools, then the sysadmins won't patch." Apparently the bar has sunk so low that people personally pushing out Snort rules on snort-users aren't actually catching all instances of the bug is the justification for releasing tools to steal private keys.<p>In reality, lots of people in the security community just like seeing chaos in the world, because it makes for even more news headlines and in their mind this increases the status of the security community. Then it's time for the <i>post hoc</i> justifications for their behavior.
I have a few ubuntu servers. When I do a "check for heartbleed" check with various tools, it says they are not vulnerable. However, these servers were installed 6 months ago and not updated for at least 2 months. How can they not be vulnerable?
While I know private keys are important and you really don't want to leak them, I have to wonder if the security community's focus on the private keys as the crown jewels that heartbleed accesses is a little misplaced.<p>If someone can steal your private key, yes, they can now impersonate your SSL server. For HTTPS, they'll need to actually perform a DNS spoof or similar to truly exploit that change, though. I guess there might be more of a concern about things like DKIM keys being stolen. We have to be a little less trusting of SSL certs to verify identity.<p>But in all this fuss about the keys, we seem to be forgetting that the heartbleed vulnerability allowed attackers to sniff random cleartext as it passed through OpenSSL. Session identities, usernames, passwords, sure - but again, the security industry focuses on credentials being stolen as the worst case scenario. But what about all the other private data going across the SSL connection?<p>This reminds me a little of the focus on operating system security preventing privilege escalation, while ignoring the risk of malware trashing all of a user's own data - you might lose all your photographs, but at least the device drivers will be safe.<p>When it comes to heartbleed, users might legitimately fear that data they sent over SSL could have been eavesdropped by anybody; but the security industry doesn't seem to care about that as much as it does about whether the private key could have been compromised.
Well, with the exploits for this vulnerability now showing up everywhere i <i>almost</i> feel bad for the people that still have not-patched servers lying around.
It could be just my perception but it seems like the authors of Heartbleed exploit code are focusing on www and email servers.<p>Doesn't OpenVPN use OpenSSL?
Will these automated tools work on vulnerable Android devices? If so this seems a little irresponsible, I mean it is one thing to stick it to lazy sysadmins but making it easy to exploit peoples phones seems evil.