This information has been produced in reference to the recent OpenSSL Heartbleed vulnerability that has been made public at heartbleed.com.
The following Cisco content is associated with this Event Response Page:
Cisco Security Advisory: OpenSSL Heartbeat Extension Vulnerability in Multiple Cisco Products
https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140409-heartbleed
Cisco IntelliShield Alert: OpenSSL TLS/DTLS Heartbeat Information Disclosure Vulnerability
https://sec.cloudapps.cisco.com/security/center/viewAlert.x?alertId=33695
Sourcefire VRT Blog Post
http://vrt-blog.snort.org/2014/04/heartbleed-memory-disclosure-upgrade.html
Heartbleed Continued OpenSSL client.html
http://vrt-blog.snort.org/2014/04/heartbleed-continued-openssl-client.html
Cisco Security Blog Posts
http://blogs.cisco.com/security/openssl-heartbleed-vulnerability-cve-2014-0160-cisco-products-and-mitigations
http://blogs.cisco.com/security/cisco-ips-signature-coverage-for-openssl-heartbleed-issue
http://blogs.cisco.com/security/heartbleed-transparency-for-our-customers
The OpenSSL Heartbleed vulnerability has been assigned the Common Vulnerabilities and Exposure (CVE) ID CVE-2014-0160.
This vulnerability leverages the implementation of the TLS heartbeat extension (RFC6520) and the way an SSL-enabled server validates heartbeat requests to provide a response. The vulnerability could allow an attacker that has crafted a heartbeat request with an improper length to receive responses that contain private data stored in heap memory. Multiple requests could lead to information leakage from TLS encrypted communications.
For detailed information, see the Sourcefire Vulnerability Research Team (VRT) analysis.
The attack is based on a simple premise—input validation. By not checking the heartbeat request length, out-of-bounds data could be provided in the heartbeat response. A persistent attacker could send multiple messages and retrieve private key, certificates, or private information from the SSL communication.
In internal testing, the Sourcefire VRT was able to successfully retrieve usernames, passwords, and SSL certificates from TLS communications.
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 published and includes information on vulnerable products and products 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 products will be communicated according to the Cisco Security Vulnerability Policy.
The Cisco Computer Security Incident Response Team (CSIRT) is investigating Cisco public-facing infrastructure that could be susceptible to this vulnerability to facilitate its remediation.
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. These Snort SIDs have been updated by the VRT since their first release (4/8/2014) to provide valid, useful detection. The VRT also wrote signatures 30520 through 30523 for exploit attempts against OpenSSL clients. Sourcefire included the Heartbleed signatures in the (free) Community Rules for Snort as well.
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 were included as part of Cisco IPS Signature Update Package S785 (4/9/2014). Both signatures will NOT fire from Cisco IPS Signature Update Package S786 (4/10/2014) and later. If an administrator wanted to use either of the signatures separately, he would need to clone it in a new one, set an action and filter it as needed. Readers should note that 4187/0 detects malformed heartbeat requests sent by public proof-of-concept code. Signature 4187/1 detects a server response to a heartbeat request where the response contains more than 200 bytes of data. Use of this signature may cause a negative performance impact on the sensor due to false positives. For that reason, both Cisco IPS signatures ship Retired and Disabled by default. A network administrator would need to make them Active and Enabled in order to take action. To tune the frequency 4187/1 goes off at the expense of fidelity (false negatives), a network administrator can set the
Event action filters can also be used to exclude IP addresses the signature alerts on that are not running vulnerable versions of OpenSSL.
Cisco IPS Signature Update Package S786 (4/10/2014) introduced Meta signature 4187/2 that leverages 4187/0 and 4187/1. 4187/2 will fire when 4187/0 and 4187/1 fire. By default, 4187/0 and 4187/1 will not fire independently after S786. If an administrator wanted to use either of the signatures separately, he would need to clone it in a new one, set an action and filter it as needed. 4187/2 ships Retired and Disabled by default. A network administrator would need to make it Active and Enabled in order to take action.
Cisco IPS Signature Update Package S787 (4/15/2014) introduced signatures 4187/3 and 4187/4. These provide enhanced identification of both client and server exploitation attempts. 4187/3 detects a high rate (six in two seconds) of TLS Heartbeat requests from a client to a server. The rate can be tuned for the environment's needs. Signature 4187/4 detects a larger than expected amount of heartbeat data being returned. Both ship Retired and Disabled by default. A network administrator would need to make them Active and Enabled in order to take action.
All Cisco IPS devices with an IPS signature subscription will be able to use theses signatures after they have been enabled and unretired.
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 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.
Vulnerability Note VU#720951: http://www.kb.cert.org/vuls/id/720951
OpenSSL news: https://www.openssl.org/news/secadv_20140407.txt
This document is part of the Cisco Security portal. Cisco provides the official information contained on the Cisco Security portal in English only.
This document is provided on an “as is” basis and does not imply any kind of guarantee or warranty, including the warranties of merchantability or fitness for a particular use. Your use of the information in the document or materials linked from the document is at your own risk. Cisco reserves the right to change or update this document without notice at any time.