2014-04-09 09:43 AM
By now you should have all heard about the Heartbleed flaw:
Here’s everything you need to know about the Heartbleed web security flaw — Tech News and Analysis
I just spoke to the Live content team and they are working on creating an application rule to detect Heartbleed activity. Hopefully it will be available in the next 24 hours.
2014-04-16 11:07 AM
It is a false positive - working on it now.
2014-04-16 12:26 PM
It is important for everyone to understand that the detection rule will ONLY trigger on HTTP. You don't see server banners with an SSL session.
In server banners, if they are running a vulnerable version of open ssl, it shows up in risk.info. Its a passive way to detect some vulnerable servers. The rule can also be modified to look at just internal servers or external by appending org.dst exists or !exists
2014-04-16 07:47 PM
In our SA system, the parser TLS actually detecting HTTPS/HTTP/IMAPS and other SSL traffic, although the server header cannot see.
2014-04-17 10:08 AM
Fielder was referring specifically to the rule for Heartbleed vulnerability detection that was folded into the TLS parsers, which relies on seeing a server header. More specifically - it relies on seeing server meta, which will usually come from a server header in an HTTP session.
The TLS and Heartbleed exploit detection don't rely on seeing a server header. They will work for any SSL traffic (HTTPS, SMTPS, IMAPS, etc...)
2014-04-17 10:38 AM
So do you mean any traffic using heartbleed vulnerability to exploit even the server is not vulnerable will be tagged?
2014-04-17 10:57 AM
A successful Heartbleed attack will result in a risk.warning "heartbleed data leak", regardless of whether the risk.informational "openssl vulnerable to heartbleed" is registered or not.
Obviously, if an attack was successful then the server was vulnerable. Fielder's point was that the risk.informational "openssl vulnerable to heartbleed" will only be registered for HTTP.
So, for example, an IMAPS server using a vulnerable OpenSSL version won't cause the "vulnerable" alert to be registered - but if it is successfully exploited it will still cause the "data leak" alert to be registered.
2014-04-17 11:11 AM
I see, how is the false positive things?
2014-04-17 11:16 AM
I've updated the TLS parsers, but they haven't made it through QE to be published to Live yet. I'll post when they're published.
2014-04-17 11:20 AM
Just question: how to prove to the customer the parser is working correctly?
2014-04-17 11:36 AM
One way would be to import or tcpreplay pcaps of successful and failed exploit attempts to a decoder, and note if the meta is registered or not as appropriate.
Of course the customer may want to examine the pcaps to determine for themselves that they are representative. I can't share the pcaps that I have, but you or they could generate some by using the publicly available exploit code.