*** UPDATED 15-April 2014 ***
By now, almost everyone has heard of the OpenSSL Heartbleed vulnerability with CVE id CVE-2014-0160. The vulnerability has to do with the implementation of the TLS heartbeat extension (RFC6520) and could allow secret key or private information leakage in TLS encrypted communications. For more detailed information, visit the VRT’s analysis.
Cisco maintains an Cisco Event Response Page with details and network mitigations about the vulnerability
Network Mitigations:
Effective use of Cisco Sourcefire Next-Generation Intrusion Prevention System (NGIPS) event actions provides visibility into and protection against attacks that attempt to exploit this vulnerability. The Sourcefire Snort SIDs for this vulnerability are 30510 through 30517. VRT also wrote Snort signatures 30520 through 30523 for exploit attempts against OpenSSL clients
Effective use of Cisco Intrusion Prevention System (IPS) event actions provides visibility into and protection against attacks that attempt to exploit this vulnerability. The corresponding Signature IDs for Cisco IPS written for the vulnerability are 4187/0 and 4187/1 which are included as part of Cisco IPS Signature Update Package S785, 4187/2 as part of Cisco IPS Signature Update Package S786 and 4187/3 and 4187/4 as part of Cisco IPS Signature Update Package S787.
Administrators can configure IPS sensors to perform an event action when an attack is detected. The configured event action performs preventive or deterrent controls to help protect against an attack that is attempting to exploit the Heartbleed vulnerability. An IPS device that is not put inline and configured to drop malicious packets will only alert on attempts to exploit this vulnerability and will not prevent (mitigate) these attempts from becoming successful.
For more details on IPS signatures for this vulnerability, refer to the Mitigation section of the Cisco Event Response Page
For information on using Cisco Security Manager to view the activity from a Cisco IPS sensor, see Identification of Malicious Traffic Using Cisco Security Manager white paper.
Cisco Products:
The Cisco Product Security Incident Response Team (PSIRT) is currently investigating which Cisco products are affected by this vulnerability. Cisco Advisory OpenSSL Heartbeat Extension Vulnerability in Multiple Cisco Products was just published and already includes information on vulnerable products and others confirmed not vulnerable. The advisory will be updated as additional information about other products becomes available. Cisco will release free software updates that address these vulnerabilities. Any updates specifically related to Cisco will be communicated according to the Cisco Security Vulnerability Policy.
Cisco Infrastructure:
The Cisco Computer Security Incident Response Team (CSIRT) is investigating Cisco public facing infrastructure that could be susceptible to this vulnerability in order to facilitate its remediation.
Which Cisco IP signature update contains 4187/0 and 4187/1. I can’t find them in the latest update S784.
Thanks,
These signatures will be part of the next IPS Signature Update which is scheduled to be published today.
Do we need to enable both 4187/0 and 4187/1? The 4187/1 generated many 1,000’s of informational messages that I don’t need to see. Thanks -sw
Hi Stephen,
These false positives are expected. With that in mind, in Cisco IPS we released the signature Retired and with Severity and SFR settings that would not block by default. We recommend only using the signature to cover OpenSSL implementations that are vulnerable.
I hope it helps,
Panos
Is this SSL connection the one an admin uses to talk to its Cisco products? Where is the SSL software running?
Hi Greg,
SSL/TLS is used in multiple products and multiple ways. One example is the one you mentioned, that is to manage a Cisco device over HTTPS. Another example could be SSL VPN tunnels. And there are other uses also. It depends on the product.
I hope that helps,
Panos
Hello Panos,
Please advise on how to get this to a status that will not be ignored by the sensor (see message below). I’ve already set enabled the signature and set a sev level. I’d like to see this fire if possible – does the system have to be vulnerable in order to activate the sig or will it do it independant of the destination system vuln status?
Thanks in advance.
evError: eventId=1345083849599548821 vendor=Cisco severity=warning
originator:
hostId:
appName: sensorApp
appInstanceId: 491
time: Apr 10, 2014 05:34:05 UTC offset=-300 timeZone=GMT-06:00
errorMessage: valueIgnored:Signature 4187:0 is retired by default. You can enable it, but it will be ignored. name=errWarning
Hi Catherine,
Indeed, both Cisco IPS signatures are shipped Retired & Disabled – you would need to make them active and enable them. They will fire when they see suspicious activity (see my response to Raghu), but not only to vulnerable systems. To alleviate false positives we recommend to use action filters for them.
I hope it helps,
Panos
Is there any specific recommendation that we can share with the customer about the large set of false positives that are generated
Hi Raghu,
4187/1 detects a server response to a heartbeat request where the response contains more than 200 bytes of data. 4187/0 catches attempts to exploit using the public PoC code. Indeed, use of these signatures could generate false positives. Event action filters should be used to exclude IP addresses the signature alerts on that are not running vulnerable versions of OpenSSL. In other words, use action filters to only alert on vulnerable systems. Summary thresholds could also alleviate the number of alerts generated. Another option can be to use Meta Signatures to combine both sigs for better fidelity (but also some caveats). We are working on that this internally right now.
I hope it makes sense,
Panos
Thanks a lot, that cleared many doubts
You mention that there is a signature to detect this vulnerability; however, I don’t see any mention regarding the actual IDS/IPS devices themselves. I have checked your post and the Cisco Security Advisory for this information, but nothing mentions the Cisco Intrusion Prevention devices. Have you heard anything or do you if this is published anywhere? Thanks in advance for any assistance.
Thanks,
Kevin
Hi Kevin,
In this post above you will find two paragraphs that document the signatures for Cisco Intrusion Prevention System (IPS) and Cisco Sourcefire Next-Generation Intrusion Prevention System (NGIPS) devices. The Sourcefire sigs are also documented in VRT’s Blog http://vrt-blog.snort.org/2014/04/heartbleed-memory-disclosure-upgrade.html
So, practically all Cisco IPS devices with an IPS signature subscription and Sourcefire FirePOWER appliances with a Snort Subscriber Release will be able to use the sigs.
Rgs,
Panos
I do understand there is a signature available to detect vulnerable systems, but I am questioning if the actual appliances are vulnerable. Do the Cisco IPS devices utilize OpenSSL in any fashion?
Now I understand what you were asking. IPS uses TLS for management. The Security Advisory http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140409-heartbleed#affected currently states that the IPS is under investigation. Same is happening in the Sourcefire appliance side as well. Keep checking the advisory and we will keep updating as we continue our investigation.
Hello Panos and others,
Thanks for the reply. Found and flipped the retired flag. Agree that this is way to many false positives. (over 100 in 4 minutes).
Typically IPS/IDS systems help to identify issues. In this case, vulnerability of each server needs to be known up front in order craft event action filters appropriately.
Even while getting pounded with false positives, I initiated a couple of heartbleed external tests and these did not generate an alert..
I’m questioning the real value of these signatures in actually doing something functional to help IPS subscribers.
There seems to be interest in using IPS functionaly for this. Maybe Cisco could build and push a meta signature that includes both to save everybody some time.
Has anyone gotten these to functionally work to a level that provides value?
Hi Catherine,
> Maybe Cisco could build and push a meta signature that includes both to save everybody some time.
Agreed. We are looking into this right now.
Panos
Just to close the loop on this. For Cisco IPS, a new signature was introduced yesterday with S786, that is 4187/2. It is a meta signature that combines 4187/0 and 4187/1. I put further details in the Mitigations section of the ERP http://www.cisco.com/web/about/security/intelligence/ERP-Heartbleed.html If someone wanted to use 4187/0 or 4187/1 independently we could do it by cloning and using them. The ERP also has suggestions of how to tune the signatures for your environment to avoid false positives.
My ASA’s updated to S786 but I don’t see 4187/2. I still see 4187/0 and 4187/1 which I enabled yesterday. What am I missing?
Thanks,
Never mind it was a refresh issue with ASDM…
Thanks,
Super jazzed about getting that knoowh-w.
Hello Panos,
Thanks for the consistent line of communication in this thread.
Seeing that Anyconnect Mobile for iOS is affected by this vulnerability as well, has Cisco considered having this taken down off of Apple’s App Store so that the vulnerable software cannot be downloaded?
This is a very difficult for large IT departments to control the download of this vulnerable software, and it looks like taking the mobile license off of the firewalls is not enough to mitigate the risk since authentication and subsequent banner is presented prior to NO LICENSE alert.
Can Cisco consider doing this as well?
At this moment, we are working with Apple to get the fixed software in Apple’s App Store. Hopefully there won’t be any hurdles and we will have it up there very soon.
Having said that, if Anyconnect users ONLY connect to an ASA to terminate SSL VPN there aren’t many ways for them to get exploited, so some departments might have made a conscious decision to keep using the client.
Following up on this: The Anyconnect client version that fixes this vulnerability is now available in Apple’s App Store.
Hello,
How come Cisco Catalyst switches are not listed along with the other products? I have 2960s and 2960Gs that I need to cross off my list of possible vulnerabilities. Thanks!
Kyle,
The advisory http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140409-heartbleed has Cisco IOS in the non-affected products. The 2960s run IOS, so you should be OK.
Panos
Hello Panos,
Yes, certainly things like MDM and BYOD strategy is going to play into the decisions being made by any given company in reaction to this.
Thanks for the info
Hi Panos,
We tried the signatures on our 4270 IPS but they do not fire when we test it with this script:
http://www.exploit-db.com/exploits/32745/
Regards,
Marc
Thanks Marc.
We are working on this. We have noticed that for a couple tool variations there sometimes are false negatives. So we are looking into tuning the sigs to provide better coverage. Make sure you either enable the 4187/2 sig or at least 4187/0 for catching the PoC code exploits.
Hi Panos,
We did enable all 3 signatures for testing.
Regards,
Marc
Gotcha.
We are working on tuning signatures and making them available. More to come soon…
I notice Cisco IOS-XE is affected:
Conditions:
Running release 3.11S or greater.
WebUI interface on HTTPS enabled:
Release 15.4(2)S
I am running an earlier version than this, but still need to verify the earlier versions aren’t affected.
I’m trying to find the OpenSSL licencse version used for:
IOS XE Version: 03.09.00.S
Can you point me in the right direction or verify the OpenSSL version?
I’ve been checking the Release Notes for my XE version, but Cisco’s website appears to only be updated to OpenSSL version 3.6.0S and doesn’t really show anything after that version.
Thank You
Lisa,
I am not sure where you got the vulnerable IOS XE versions that you are citing. The single source of truth for vulnerable product versions is http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140409-heartbleed. Currently we do not have any specific vulnerable IOS XE versions in there as we are still investigating.
Having said that, I would recommend to limit access to your IOS XE routers only from trusted networks or if you don’t need it disable HTTPS in IOS-XE routers.
Hi Panos –
That information is in Bug Nav on Cisco’s site and the bug ID is listed in the advisory.
Cisco IOS XE [CSCuo19730]
Gotcha. That is the bug information, but no official version info is available right now. The bug condition mentions 3.11S, but that is not exclude other versions from being vulnerable. For a complete list, we need to finish our investigation and we will publish vulnerable version tables in the advisory.
Thank you Panos
I am going by this link: https://tools.cisco.com/bugsearch/bug/CSCuo19730
I am running an earlier version of Cisco IOS XE than stated in the above link. With using an earlier version I guess I can assume my equipment is safe, but I was hoping to verify, for myself, by verifying the actual OpenSSL version used for my version number(listed in my previous post). It is my understanding that only certain versions of OpenSSL are vulnerable.
Thanks again Panos.
> It is my understanding that only certain versions of OpenSSL are vulnerable.
That is correct. But at this point, please don’t assume you are not vulnerable until we have the complete list available. Until then I would suggest to follow the workarounds mentioned.
Take care,
Panos
I do not see any Sourcefire products (IPS sensors or the Defence Center management platform in Cisco Heartbleed product list. Are these still being “investigated” like the IPS software?
Hi Robert,
The next iteration of the Security Advisory (SA) that will make it out later tonight or tomorrow morning will include information for a couple of the products you are asking for. Sit tight. Having said that, there are more Sourcefire products that are being looked at and we will report on later.
Panos
I friend just send me this:
https://na8.salesforce.com/articles/Informational/000002216?popup=true (You need to be logged in to see it)
says that Sourcefire products from 4.10 through 5.3 are not vulnerable – they use OpenSSL, but only version 0.9.8, which is too old to have the bug.
Hi Panos,
With signature 4187/3 en /4 still no hit on exploit.
http://www.exploit-db.com/exploits/32745/
Regards, Marc
Hi Marc,
Note that the 4187/3 detects a high rate of heartbeat requests from a client to a server (6 in 2sec). So, 4187/3 is time-based. You can go low and slow under it, but are unlikely to get useful information. High rate of malicious messages are more likely to get useful information for the attacker and are the type of attack 4187/3 is designed for. Briefly looking at the exploit code, I don’t think it sends the requests in the expected frequency and that is why you don’t see hits.
The 4187/4 detects a larger than expected amount of heartbeat data being returned. Detection depends on the response size. I am double checking something in the size matching expression right now and if we need to tune it more we will do that.
Going back and looking at the regex in 4187/0 (and thus 4187/2 if 200 bytes of data are also seen coming back) should be matching the exploit request. The regex in the sig is ^\x18\x03[\x00-x03]. That should match what is sent by the exploit code which is
hb = h2bin(”’
18 03 02 00 03
01 40 00
”’)
So, I would suggest to test that 4187/1 by itself. It should fire with the exploit code. Then I would suggest to lower the trigger rate of 4187/3 to see if it matches. For the 4187/4 I will check the regex internally.
I believe the sigs should work now. I am sorry that I can’t troubleshoot this further over the Blog. If there are still issues, please open a case with Cisco TAC and we should be able to look into it a little further, get packet captures and get to the bottom of it.
Panos
We will indeed provide an update to 4187/4 in the next update to better match on responses with more data than expected.
Hi,
I have some Cisco Unified 9971 phones. How the fix shouldbe applied? I mean, is ther any firmware update of softtwreI need to download? I have been looking for the update in the fix section but nothing ismentioned about Cisco Unified 9971
Thanks in Advance
Hi Jose,
Unfortunately there is no fixed software for the 9971s yet. When we have it we will update the info in the Fixed Software section of the Advisory http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140409-heartbleed#software
Note that if the phones are deployed using the proper best practices (voice VLAN, not accessible inbound from the internet) then someone on the internet would not be able to exploit this. Also, the HTTPS server is currently not enabled by default on the phones. So, I would check if you can access them over HTTPS because there is a good chance you are safe already.
I hope it helps,
Panos
I am serioulsy getting mixed messages in regards to this vulnerability. As to whether Cisco Deem this signature is critical enough or not. Releasing signture in disable it indicates the following based on Cisco’s own puclished FAQ in regards to retired signatures found at http://www.cisco.com/web/about/security/intelligence/ips_sig_faq.html.
Which says:
Q: Why is signature X retired?
A: Signatures can be retired or disabled for a variety of reasons:
The signature is “old” and of very little value.
The vulnerability being detected is sufficiently old enough to be widely patched
The vulnerability is unlikely to be exploited in the wild.
The signature is more than 2 years old
Specifications have changed and what was previously considered an indicator of malicious activity is now valid or no longer considered malicious. Any reporting of those signatures would essentially be false positives.
The signature has a resources impact.
The sensor resources are limited. Occasionally as new signatures are released, old signatures must be retired to ensure the sensor runs optimally.
There is no way to run all signatures with the resources constraint, so the default shipping signature set must run a subset of all signatures.
There have been reports of false positives and it is not possible to tune the signature to reduce false positives.
The signature effectively detects a vulnerability potentially being exploited, but has the potential in many environments to produce false positive alerts. It is therefore disabled or retired to prevent “noise” in other customers’ networks.
At any time, the end customer is still able to enable and unretire a signature if the customer is still running the affected/vulnerable software and needs the protection provided by the signature.
So based on the above info these retired signatures does not fall on bullet points under The signature is “old” and of very little value. So likely falls under bullet points “The signature has a resources impact.”
So if this is the case why then on the released blog about Heartbleed signature http://blogs.cisco.com/security/cisco-ips-signature-coverage-for-openssl-heartbleed-issue/ it does not provide specific impact of enabling these signatures?
What is straight clear answers as to the impact of these signatures, or its being left to customers to be guinea pigs?
Hi Arthur,
You are right that the sigs ship disabled to avoid performance impact. The first sigs we released could have a performance impact on an IPS but we wanted to provide coverage and suggested to only apply them to interesting traffic and calibrate to the environment’s needs. Since update S789, sigs 4187/3 and 4187/4 should be used. These signatures have been calibrated to only look in limited parts of the packet for better performance. Our performance tests showed that there is no significant performance change when having these sigs enabled compared to older signature packages for various traffic patterns tested.
Having said that, someone should have in mind that performance cannot be accounted for everyone’s environment. Depending on traffic profiles, enabled sigs and applications, IPS performance could change. Our tests are reference to show how the sigs affect the appliance, compared to previous tests, but we would suggest to everyone to monitor the load after applying the changes.
I hope it helps.
The 4187 signatures were useful for us in confirming results of other Heartbleed investigation and analysis. We saw a number of 4187/4 hits on systems running TLS that was not the OpenSSL version and we are investigating whether this code is vulnerable too. What is the exact criteria used for “server returns larger than expected heartbeat response”? thanks, sw
Hi Stephen,
Thank you. The 4187/4 fires when the heartbeat data returned from the SSL/TLS server is more than 128bytes. Of course, you could calibrate that for you environment.
I hope it helps.