Updated 4/15/14: Included Link to Affected Juniper Products
Updated 4/17/14: Included new IDP signature covering Client and STARTTLS Vector
Introduction
Chances are, you've read a few hundred blog posts already on CVE-2014-0160, OpenSSL SSL/TSL/DTSL Heartbeat Information Disclosure - aka the Heartbleed bug.
The good news is, most Juniper products are not affected. SRX was amongst those not affected, and therefore is in a good position to help. For a complete list of affected products and the fixes for them, please Folow This Link.
Even better news? Juniper's IDP signature team has already written a signature to block the attack.
Word has gotten out about the new sig, but there's been some confusion over it, so this blog post will serve as a central clearing house for those frequently asked questions and their answers.
FAQ
Q: Does Juniper have a signature for this issue?
A: YES! It is "SSL: OpenSSL TLS DTLS Heartbeat Information Disclosure", which was released April 8, 2014 at 9:50 p.m PDT in signature export 2362. It is classified as a "High" or "Major" (depending on your management system) severity attack. It is also flagged as a performance-impacting ("slow") signature (more on that in a bit).
The "Short Name" for this signature is:
SSL:OPENSSL-TLS-DTLS-HEARTBEAT
Q: How does the signature work?
A: The signature checks for over-large Heartbeat packets for all versions of SSL/TSL/DTLS.
Q: Isn't that cheating?
A: Yes, it is. The correct way to detect this behavior would be to compare the "Record Length" value to the HeartBeat header's "Payload Length" value. A check for an appropriate mismatch between these two headers would detect all possible attack permutations.
Unfortunately, doing math is not our signature language's strong suit, and it can't do comparisons between values found in traffic. A Protocol Anomaly Attack Object, however, can. These are special checks coded directly into the decoder or the engine. The bad news: A Protocol Anomaly generally takes anywhere from 1 to 6 months (sometimes even longer!) to be added. The signature works well for the time being.
Q: No False Positives?
A: None we've seen so far.
Q: What about False Negatives?
A: We've tried to be as comprehensive as we can with the signature, and as strict as possible, without generating false positives. There are some corner cases, however that could get through. We'd like to hope we've minimized them.
So far, every report of False Negative presented to us has been shown to be a mistake of the tool in question, or a problem with the policy configuration. There are some special things to keep in mind to ensure you have this signature in your policy - it won't generally automatically be there.
Q: Are you protecting clients as well?
A: Regretfully no [*YES! See update below!]. This signature has some performance issues (more on that in a bit) checking in the Client-to-Server direction, but they are manageable. The performance impact in the Server-To-Client direction, however, is very large. Considering the current focus on server issues with this vulnerability, the decision was made to limit the performance impact by also limiting the direction.
Q: What about STARTTLS connections?
A: Another regret [*YES! See update below!]. Right now, we're focused on protecting native SSL/TLS/DTLS-based servers from attack. We're looking into the possiblity of adding support to STARTTLS-protected services, but we're still very concerned about the performance impact. Look for more signatures soon.
Q: I *am* looking for this signature! Where the @#$% is it?!?
A: Due to our legacy dynamic grouping mechanisms in both NSM and Space SD, this signature isn't where you'd normally expect to find it. It's been flagged as "Performance Impacting" (aka "Slow") and therefore is filtered out of the normal Recommended groups like [Recommended]SSL - Major and similar.
"Slow" signatures are relegated to the "Misc_" appended groups, so the most specific dynamic group that contains this signature would be [Recommended]Misc_SSL - Major.
Two other techniques to ensure this signature is in your policy would be:
1. Make a custom dynamic group using the filters: Recommended = Yes + Category = SSL and then add that custom dynamic group to your policy.
2. Explicitly add the signature by "Short Name" to your policy without using a group:
SSL:OPENSSL-TLS-DTLS-HEARTBEAT
*** Client and STARTTLS Protection Update:
An alternate signature has been released with signature update 2365 that also covers the Client direction and also adds support for STARTTLS sessions under certain circumstances. This signature is not to be used in conjunction with the previous signature, it is an alternative that should only be used in very specific circumstances. Its general use is not recommended.
This signature is considerably more performance impacting than the exisiting signature.
There are also higher chances of potential false positives with this alternate signature.
For the majority of customers requiring protection of their servers from attack, this alternate signature is not necessary.
If you are experiencing possible false-negatives with the existing signature for server protection, this alternate signature will not resolve your issue. Please ensure you have the signature in your policy using the above Q&A information, and if you are still experiencing false-negatives, please contact JTAC as soon as possible with your report. Please have packet captures ready so we can confirm the issue rapidly.
The alternate signature is called "SSL: OpenSSL TLS DTLS Heartbeat Information Disclosure (Server, Client, and STARTTLS Support)" and its Short Name is:
SSL:OPENSSL-HEARTBEAT-ALTERNATE
This signature has been marked as "Slow" and also has NOT been marked as "Recommended". In order to add it to your policy, you will need to add it by specifically name, as it will not be included in any predefined recommended group.
In order to apply this signature to your STARTTLS connections, you will need to adjust the application binding within your policy to ensure you cover the ports you need to cover - by default, the signature will only cover SSL-native sessions.
Please consider your environment very carefully before attempting to use this alternative signature - most customers do not need it.
Conclusion
Here at Signature HQ, we're committed to bringing you the freshest, most reliable, most relevant signatures we can, as quickly as possible.
We appreciate the opportunity and the responsibility you entrust us with as your signature provider. Please feel free to contact us through your local Juniper Representative for any signature concerns you have.