How to recover from the Heartbleed OpenSSL vulnerability
Introduction
If you believe your site may have been impacted through the CVE-2014-0160 OpenSSL security vulnerability (commonly referred to as Heartbleed), the first step is to update OpenSSL on all potentially impacted systems. Red Hat has provided fixes for all impacted products:
- Red Hat Enterprise Linux advisory
- Red Hat Enterprise Virtualization Hypervisor advisory
- Red Hat Storage advisory
All other Red Hat products that include OpenSSL were not affected by this issue, as they included an older version of OpenSSL, which does not expose the exploitable functionality. For products layered on top of RHEL, such as Red Hat Satellite, OpenStack, or OpenShift, follow the steps above for securing RHEL systems. Once you have updated your system, you can utilize Red Hat's Heartbleed Detector to confirm the fix is in place.
Red Hat is not aware of any public exploit being used in the wild for this issue prior to the date of disclosure. However, a number of public exploits were published shortly after the issue was disclosed. These exploits could lead to the disclosure of information handled by applications using OpenSSL, including private keys, session tokens, and data submitted by users, which could include authentication credentials.
Note that several security researchers have now proven that it is possible to retrieve private keys from an nginx server vulnerable to his flaw. It has not yet been proven that private keys can be retrieved from Apache httpd servers. The proven attacks against nginx were successful shortly after a system reboot. This leads to the private key being stored in uninitialized heap memory, thereby making it more feasible to retrieve.
It is recommended that you assess the risk this could pose to your systems, and perform additional remediation as you deem appropriate, for example replacing SSL keys.
Replacing SSL Keys
Now that your system is no longer vulnerable, it is strongly recommended to replace any SSL keys which could have been compromised, as described below.
Self-Signed Certificate
If you are using a self-signed certificate, you can regenerate them using the following steps:
- How to create a Certificate Signing Request with a Certificate Authority
- How to apply the Certificate Authority signed certificate
CA Generated Certificates
If you received a signed certificate from a CA signing authority, you will need to work with that vendor to generate new certificates.
Updating SSL Certificates in Red Hat Products
Many Red Hat products are configured to use SSL certificates to secure key services. After creating or receiving new certificates and keys, please follow the guides below to update your configuration to utilize new certificates once generated.
Red Hat Enterprise Virtualization
Red Hat Storage
Red Hat Storage Configuring SSL
Red Hat Satellite
How do I update my Red Hat Network Proxy or Satellite Server SSL keys and certificates?
OpenLDAP server on Red Hat Enterprise Linux with SSL
How to configure OpenLDAP server with SSL/TLS on Red Hat Enterprise Linux 6?
SSL encrypted FTP on Red Hat Enterprise Linux
How to configure vsftpd with SSL/TLS on Red Hat Enterprise Linux
Red Hat Update Infrastructure
Configuring Red Hat Update Appliance SSL Certificates
OpenShift Enterprise
Red Hat Enterprise Linux OpenStack Platform
OpenStack Nova Configuring TLS/SSL
OpenStack Glance Configuring TLS/SSL
OpenStack Configuring SSL for Block Storage
OpenStack Testing that SSL certificates are set up correctly
Web Servers
If you are using OpenSSL on a web server, for example using mod_ssl and Apache httpd, then remote attackers may have used this flaw to compromise session tokens and plaintext user credentials stored in memory. Tools allowing attackers to automatically harvest session tokens from servers vulnerable to this flaw are publicly available.
If you are concerned that session tokens and credentials may have been compromised on a web server running OpenSSL, you may wish to perform the following additional remediation steps:
- Log out all users on the web server, and clear the session token
cache. This can usually be performed by restarting the httpd service. - Optional: Reset all user passwords.
Note that this is an invasive change, and it is recommended that you weigh the cost of performing this step against the risk of not performing it.
Additional Steps
Depending on your specific circumstance, you may want to take additional steps. Items such as public internet availability vs intranet could determine how targeted an attack could be. For example, if you are hosting a public website that requires users to log in, you may want to have your users change their passwords.
Comments