Within the last few days, a critical vulnerability has been discovered within OpenSSL, dubbed “Heartbleed,” which can enable an attacker to extract information from the vulnerable server’s memory. OpenSSL is a free implementation of SSL, primarily used on Linux systems and appliances such as VPN concentrators. This blog explains the impact of the OpenSSL heartbeat extension vulnerability, recommends ways to detect if it is in your environment, and how to remediate it.
Successful exploitation of the vulnerability could potentially enable an attacker to gain access to the server’s private key, user credentials, session information, or any credit card data stored in the server’s memory. The specific memory content returned to the attacker is random, so the attacker can increase the probability of obtaining sensitive content that is stored in memory by sending multiple SSL\TLS packets to the server. It is estimated that potentially two-thirds of devices on the Internet currently contain this vulnerability.
This is still a rather new vulnerability, but some vulnerability scanners (e.g. Qualys, Nessus, etc.) claim to have released checks to detect it. However, SecureState has found that at least some of these vulnerability checks are not adequate for detecting this vulnerability within the organization’s devices. Although many of the most popular vulnerability scanners are inadequate for identifying this vulnerability, Qualys has a free scanner that they use as part of their SSL Labs project that scans web servers for this vulnerability.
SecureState has found that it is fairly accurate when it comes to the detection of this vulnerability. In this regard, an organization can take all of their sites that use SSL and send them to this scanner (https://www.ssllabs.com). It should be noted that other protocols, such as SMTP and FTP, can also use SSL, and the SSL Labs scanner only accepts URLs that are associated with websites. A second option would be to use a publically available Python script to check for this vulnerability (https://gist.github.com/dyatlov/10192468). This script has a “starttls” option, which can be used for testing other protocols that use SSL (e.g. FTP, STMP, etc.).
It should also be noted that suspicious traffic which attempts to exploit this vulnerability matches a specific pattern, and IPS\IDS rules can be created to detect and\or prevent this vulnerability. The linked blog lists some of the SNORT rules that have been created for detecting this vulnerability: http://blog.fox-it.com/2014/04/08/openssl-heartbleed-bug-live-blog/.
Two modules have been release for the Metasploit Framework: one for testing server-side OpenSSL implementations (auxiliary/scanner/ssl/openssl_heartbleed) and one for testing client-side implementations (auxiliary/server/openssl_heartbleed_client_memory). The module for testing server-side implementations also has support for starttls on POP3, IMAP, SMTP, and JABBER. While a lot of attention has been focused on the vulnerabilities of server-side implementations, it is important to remember that clients can be vulnerable too!
This vulnerability affects OpenSSL versions 1.0.1-1.0.1f, and 1.0.2-beta, and can be remediated by upgrading to OpenSSL 1.0.1g. Additionally, OpenSSL branches 1.0.0, and 0.9.8 do not contain this vulnerability. It should be noted that many third party products (BlueCoat, Juniper, WatchGuard, etc.) use OpenSSL for their SSL implementations. Thus, although the organization may not be running OpenSSL directly, various devices within their organization may still contain this vulnerability. It is recommended that any OpenSSL implementations using a vulnerable version of OpenSSL be upgraded as soon as possible.
Additionally, if there are any devices that utilize a vulnerable version of OpenSSL within the organization, the vendor of those devices should be contacted in order to receive specific recommendations from the third party. Once the specific devices that support the vulnerable version of OpenSSL have been secured, we recommend the following steps be performed:
- Replace the SSL certificate on the effected systems
- Revoke the old SSL certificate which was used by the vulnerable implementation
- Terminate and reinitiate any sessions or connections which may have been hijacked due to the vulnerability
- Have all users who accessed the service change their passwords. If the impacted system was a VPN concentrator, all VPN users should change their password.
- Contact SecureState to have an Impact Assessment performed to assess what information may have been compromised and determine what next steps are required to address any security, privacy or regulatory concerns