This week, researchers from Codenomicon and Google Security publicly disclosed a critical bug in the OpenSSL cryptographic software package used by millions of internet connected services. This weakness, referred to as the Heartbleed bug, allows anyone on the Internet to steal information from vulnerable systems by exploiting a protocol designed to ensure the security in network communications. The amount of damage this bug may cause is not to be underestimated and thankfully a security patch has already been released.
According to Netcraft’s April 2014 Web Server Survey, 66% of the web servers on the Internet use open source web servers, like Apache and Nginx, may utilize vulnerable instances of the OpenSSL software package. Many Internet services, including email, online banking, financial trading and some VPNs, may utilize vulnerable versions of OpenSSL. It is not known how many of these services use the affected versions of the software, but in any case, the potential for widespread harm is extremely high.
The Heartbleed bug allows an attacker to steal up to 64kB of memory content by exploiting the Transport Layer Security (TLS) heartbeat extension (See: RFC6520) in OpenSSL. A heartbeat is a mechanism for keeping a connection open between a client and server even if no other communication is currently occurring. This heartbeat elevates the reestablishing a secure connection and reduces request latency for the end-users. The exploit triggers a buffer over-read caused by a missing bounds check during the TLS heartbeat response process which exposes information that is normally protected.
The content that may be retrieved by the attacker may be any content in the memory of the vulnerable system including a wide variety of security-sensitive information. Organizations that process credit cards or other Personally Identifiable Information (PII) may have that information leaked by simply processing the information on a vulnerable web application server. The attack, known as Session Hijacking, becomes an easy attack against a vulnerable service as the application servers may provide the appropriate session information to the attacker. Many services rely upon SSL/TLS to provide communication security and privacy over the Internet for applications such as web browsing, online banking, email and some VPNs.
Despite the sensationalist headlines that are circulating the internet, the key is not to panic, and to take a measured response to this issue. A robust incident response plan will help you here, but our general recommended course of action is as follows:
Perform an inventory of OpenSSL installations that may have some exposure, and then determine if any of those installations are using the vulnerable versions, or have been in the last two years. This may include application servers, email servers, SSL-based VPN end-points, networking equipment and 3rd party appliances.
- What servers or service may be affected?
- Which SSL certificates may be been exposed?
- Are there any other services or applications that operate on a vulnerable server that may be been exposed?
- What is the relative priority of the affected services or servers with regards to remediation?
- Were certificates on any affected servers also used on other servers?
Isolate & Contain
The primary purpose of this phase is to limit the damage and prevent any further damage from happening. A good example of containment in this case is disconnecting the affected systems by either disconnecting the system completely from the network or at least prevent outside connections. This in turn will isolate the problem from the rest of the production network and prevent further exploitation of the vulnerability.
This phase deals with the actual removal and restoration of the affected systems. It is strongly recommended that the first and foremost action be to update any vulnerable versions of the OpenSSL software package to current 1.0.1g release. Vulnerable systems unable to immediately upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS option. Due to the remote possibility of private SSL keys being stolen these keys should be revoked and replaced with newly generated keys. Certificate revocation is a complex and potentially costly process but the general steps are as follows:
- Perform an explicit certificate revocation through your organizations certificate authority.
- Obtain new certificates from your certificate authority.
- Only after patching vulnerable instances of the OpenSSL software package, install the newly generated certificates on affected systems.
Finally, ensure that your intrusion detection and prevention systems (IDS/IPS) are updated with appropriate signatures to block or log these attacks as appropriate.
Resolution & Closure
The purpose of this phase is to integrate any procedural improvements based on the experiences of this response into the incident response plan. The incident response team should analyze the incident and how it was handled, making recommendations for better further response, preventing a recurrence and improving the quality of the incident response process.
All software can contain bugs and security vulnerabilities, whether Free and Open source software (FOSS) or proprietary software.
Organizations should have a comprehensive vulnerability and patch management program in place, including an incident response plan, that covers all of your electronic assets. A proper risk management program is vital to ensure critical vulnerability like this can be dealt with effectively.
To check to see if a host, one that you own, is prone to the Heartbleed bug, see the Heartbleed OpenSSL Bug Checker.
For more information regarding this bug see: