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.
Content update imminent! We've put the detection functionality into our TLS parsers. They are being updated to Live shortly. Stay tuned for the announcement
What should be looking for in the Meta to alert on?
I think it will be a risk.warning- "heartbleed_data_leaked"
Some simple application rules on the decoders can help detect vulnerable versions of Open SSL. It does this by reading server banners when someone connects to a monitored web service via the HTTP Protocol. However, this is an SSL issue, and webhosts that allow only SSL will not trigger detection via these rules. This is a stop-gap, passive vulnerability application rule and should not be relied upon in place of a rigorous, active vulnerability scanning service.
One rule is:
server contains 'openssl/1.0.1e','openssl/1.0.1f','openssl/1.0.1a','openssl/1.0.1b','openssl/1.0.1c','openssl/1.0.1d'
Note that this issue is a patching issue. SA may help in identifying and prioritizing which hosts to patch first, but it is not a substitute to a rigorous scanning and patching effort. Good luck to all those working long hours getting fixes in place.
Just uploaded a pcap of a heartbleed attack with the new TLS and it does not appear to be catching it :/
Doesn't even show that it used TLS when in wireshark I can see that it did.
Sean- which TLS parser were you using? How big is the pcap and is it something I can get?
Just spoke to the gentleman who created the TLS parsers and would very much like to get that pcap if at all possible. Our first run parsers were a bit too specific in what they were attempting to recognize in regards to Heartbleed, so we opened them up a bit. This may or may not have anything to do with your results, but that certainly isn't to say that you haven't captured an attack scenario we haven't seen. We can always improve, however we need to know exactly what is being missed.
The file is small, only 6kb in size. Do you have an email I could send it to? I would rather not put the pcap in public.
Obviously we're interested in any attack scenarios that are flying under the *current* parser functionality radar- so this is a big help.
You should be getting the pcap now.
That doesn't look like a successful attack to me?
I see the heartbeat request from the client, and the server ACKs the packet. But before the server actually sends a heartbeat response, the client FINs and the session is over. No data leakage.
Or is there something I'm missing?
Very well could not be a successful attack. I was going based on Heartbleed: Packet Capture | Didier Stevens and the malformed heartbeat request was very similar to the one found in the pcap.
My other post is apparently being moderated. But I wanted to confirm that we have now seen this parser work successfully in our network to devices that are still vulnerable. Good thing I am not the one who manages our certs....
I find risk.info is not picking up, but risk.warning is picking up.
Do you have any pcap that I can use test if tag both risk.info and risk.warning. May not be same pcap could be two different pcaps@
The risk.info meta is triggered by the same conditions as the app rule mentioned by Fielder here:
server contains 'openssl/1.0.1e','openssl/1.0.1f','openssl/1.0.1a','openssl/1.0.1b','openssl/1.0.1c','openssl/1.0.1d'
So there needs to be 'server' meta that contains one of those strings. The 'server' meta itself would be registered by other parsers (most likely one of the HTTP parsers).
I find hits for this rule server contains 'openssl/1.0.1e','openssl/1.0.1f','openssl/1.0.1a','openssl/1.0.1b','openssl/1.0.1c','openssl/1.0.1d', But not risk.info==“openssl vulnerable to heartbleed”.
Would you be able to share a pcap that hits the rule but not the parser?
server contains 'openssl/1.0.1e','openssl/1.0.1f','openssl/1.0.1a','openssl/1.0.1b','openssl/1.0.1c','openssl/1.0.1d'
Server header is visible only for http traffic. How is it detecting ssl version of https traffic
Is this parser only looks for server header in http traffic.
I’ll create a case and upload pcap that has http traffic with server header contains ssl version number. But risk.info is not tagged there.
Motley, please send me email so that I can share case number with you to look at pcap.
I have issue here, some http traffic also tag as heartbleed, why?
patriot3w: Is it an HTTPS session? If not, can you share the pcap?
It's http sessions, let me send you the pcap privately.
can you send me your email? i am not able share the files to you from ECN.
thanks guys, i've sent.
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
In our SA system, the parser TLS actually detecting HTTPS/HTTP/IMAPS and other SSL traffic, although the server header cannot see.
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...)
So do you mean any traffic using heartbleed vulnerability to exploit even the server is not vulnerable will be tagged?
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.
I see, how is the false positive things?
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.
Just question: how to prove to the customer the parser is working correctly?
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.
The latest updates to TLS-flex and TLS_lua to address false positives have now been published in Live.
thank you. will advise the customer to update.
Praveen_jpmc: I suspect you may be confusing the functionality of the two alerts?
The risk.informational "openssl version vulnerable..." and the risk.warning "heartbleed data leak" are completely independent capabilities of the parsers - they are in no way dependent upon each other.
risk.informational "openssl version vulnerable..." is functionally identical to the previously mentioned app rule. App rules look at meta, and generate new meta from them. In this case, the app rule looked at "server" meta for the openssl version string.
risk.warning "heartbleed data leak examines the actual contents of TLS heartbeat requests and responses, regardless of TLS version, OpenSSL version, or protocol being encapsulated within the TLS.
risk.warning- "heartbleed_data_leaked"
Is this the correct meta field that will be alerted on as Fielder suggested when using the TLS parser?
To detect vulnerable servers, look for instances of “openssl vulnerable to heartbleed” under the risk.informational. For detecting exploit attempts, look for “heartbleed data leak” under risk.warning.
The attack detection in the TLS-flex and TLS_lua parsers will register,
risk.warning: "heartbleed data leak"
The app rule mentioned above has been folded into the TLS-flex / TLS_lua parsers as well, so it is not necessary to create it separately. It will register,
risk.informational: "openssl vulnerable to heartbleed"
on Apr 9, 2014
We are testing both an app rule for identifying vulnerable servers and a parser for detecting the 64K leak associated with Heartbleed.