OpenSSL Heartbleed bug sniff tools are 'BUGGY' – what becomes of the broken hearted? Software that claims to detect the presence of OpenSSL's Heartbleed bug in servers, PCs and other gear may falsely report a system to be safe when users are actually in danger, according to a security consultancy. This finding is disputed by developers publishing tools that test for the vulnerability. The teams behind Nessus …
I wish this was unique to Heartbleed. The BEAST detection scripts are often completely inaccurate, as are SSL weak ciphers, SSLv2. I could go on. I find false positives/negatives in these on a daily basis. The level of accuracy from even the best vulnerability scanners is, unfortunately, often woeful.
Vulnerability assessment is not an exact science. You can't always simply emulate the exploit and see if it works (this is obviously true for denial of service attacks that could cripple or crash the target). Often the logic runs:
1. Port scan to identify open ports.
2. Look up port number in database to identify service.
3. Retrieve banner including software version information.
4. Look up software in database to check for known vulnerabilities in the reported version.
Since banners can often be trivially spoofed, this is liable to generate false negatives.
That's fair enough. But you *can* recognise that TLS 1.0, 1.1 and 1.2 exist and test each of them properly. Not merely make a test for TLS 1.0 that fails over if BEAST mitigation has disabled TLS 1.0. Likewise, you can recognise the fact that a lot of STARTTLS based protocols also utilise OpenSSL and support those to.
Something a lot of the tests have failed to do.
That's fair enough. But you *can* recognise that TLS 1.0, 1.1 and 1.2 exist and test each of them properly.
Yes. And in the particular case of Heartbleed, it's not hard to write a proper test client. Rob Stradling put a very simple one on github and posted it to openssl-users.
Interesting that the bug detection code is, in itself, buggy.
If I use OSS for my security, that is my look out. Normally OSS is great: there are so many eyes on the code that I have a reasonable assumption that bugs will be found, and corrected in pretty fast time. Heartbleed is exception that proves the rule, but, OK it is a biggy. However, I installed the code, it's my look out, and I am responsible for any bleed from my system. My customers will expect that of me.
But if YOU release some code that says I have the bug, when in fact I don't, and you publish this, then that is your look out. If your publicity of a false situation drives people away from my site, then this is libel - and in a commercial site that could cause me to seek redress.
This is doubly so if you then say that my rivals site is clean, when it isn't. Customers being customers, as we know, will register on the new site with exactly the same credentials as they had on the old site. How many of you use the same password on eBay, Amazon, etc? For most everage punters this falls in to two classes of people: Those that use the same password and those that lie. Now, if someone gets their credentials from the new site they go to, which you said was fine, they get hacked, and come after me because you said my site was still broken, what am I going to do?
Paris - obviously, because her site is always free from bugs...... oh?
Heartbleed is a fairly easy vuln to test for, so there's no false positive (as outlined in the article) and false negatives are necessarily very contrived set-ups. It's good that the false negatives are found and added to the detection tools, but there are very few systems affected in the real world. Of course you wouldn't want them to be yours...
In any case the detection tools are mostly useful for the clients. As a sysadmin, if you're going to spend that kind of time checking if your pant is down, chances are that you'd better use that time to update OpenSSL instead.
Heartbleed is a fairly easy vuln to test for, so there's no false positive
There could be a false positive - someone could create a honeypot implementation that replied to the malformed Heartbeat request with a response filled with garbage (or, better, plausible-looking but invalid information). But that too would be a contrivance, obviously.
>How many of you use the same password on eBay, Amazon, etc?
Of course I do but since I use the PasswordMaker plugin (along with NoScript and bunch of other plugins) for Firefox it makes completely new passwords based on that password for each site. I use it for any site where someone could withdraw money out of my accounts. Its so good I don't even know the passwords. Yes I am sure its not perfect (especially if you tell it to keep the master password in memory or even worse disk) and you have to be careful to not lose your firefox profile as it uses each unique install as part of generating the passwords but it allows me to be lazy with a little bit of security.
Yes, but in large organisations there's always the odd box under a desk that hosts a "pirate" server setup by an intern 3 years ago, badly configured and unpatched because you wouldn't expect Lucy from receiving to know her way around sh (and the root password is long lost anyway).
There's all the COTS product black boxes too which are usually embedded something or other and presented as a device similar to a toaster or washing machine rather than a embedded computer. You can't just log into one because if its provided as a service or supported only by a supplier, chances are you don't have the detail needed to check it from inside. We can ask the supplier for statements, but that's not always reliable. I have been wrestling with openssl_client and grep's trying to come up with things to verify independantly of the tools available.
So yes, we DO need ways to independantly probe kit reliably from a external point of view that doesn't give false clean bills of health. Yesterday nessus were changing their plugins to detect heartbleed in ssl v3 implementations, even though its not part of the official protocol for v3, because it has been implemented regardless. Its a very fast moving landscape. Hats off to the players listed so far for improving their product in the light of more indepth technical understanding.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
