Protect Server Against Heartbleed OpenSSL VulnerabilityFree consultation

The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet.

1

Customers

2

Case Studies

3

Affiliates

4

Philosophy

We offer cyber security penetration testing and consultancy services to a variety of customers.
Such synergies bring value in to Valency Networks which benefit the customers by having solutions to variety of their requirements.
Such synergies bring value in to Valency Networks which benefit the customers by having solutions to variety of their requirements.
Such synergies bring value in to Valency Networks which benefit the customers by having solutions to variety of their requirements.

What is Heartbleed vulnerability?

The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private networks (VPNs).

The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.

Affected Versions:-
OpenSSL versions 1.0.1 through 1.0.1f (inclusive) and version 1.0.2-beta are vulnerable; branches 1.0.0 and 0.9.8 are not vulnerable.

Heartbleed Solution:
Following are the recommended steps need to followed in order to protect server against the Heartbleed OpenSSL Vulnerability


  1. Update Operating System

  2. On Ubuntu and Debian, you can update by typing:
    sudo apt-get update
    sudo apt-get dist-upgrade

    If you only want to upgrade the affected packages, and not update the entire system (only recommended if you have reason to believe that upgrades to other components will break your system), you can selectively upgrade the OpenSSL packages by typing:

    sudo apt-get install --only-upgrade openssl
    sudo apt-get install --only-upgrade libssl1.0.0
    This will upgrade the vulnerable packages while leaving the rest of your system in an un-upgraded state.

    On CentOS and Fedora, you can type this to update the entire system:
    yum update

    If you wish to only upgrade the affected package, you can instead issue this command:
    yum update openssl

    Again, this is only recommended if you have a specific reason for not updating the complete system.

  3. Checking OpenSSL Version Numbers
  4. You should check your version of OpenSSL after you have updated your system While OpenSSL version 1.0.1g is the official fix of this problem, the version that fixes this for different distributions and releases may vary. Some releases and distributions patched their older versions to fix the problem, rather than releasing an entirely new version into an older, stable ecosystem.

    Because of this reason, it is best to check through your distribution's packaging system, since the openssl version command might not reflect the information we need.

    Debian and Ubuntu Releases and Fix Versions
    For Debian and Ubuntu systems, you get the current version of your OpenSSL package by typing:
    dpkg -l | grep "openssl"

    You should receive output like this:
    ii openssl 1.0.1e-2+deb7u6 amd64 Secure Socket Layer (SSL) binary and related cryptographic tools
    From above shown output check the reported version on the official site for the list of affected version for the Heartbleed vulnerability. If the reported version is mentioned in the site under affected version the advised to update the OS or check the OPEN SSL package is updated properly.

    CentOS and Fedora Releases and Fix Versions
    For CentOS and Fedora systems, you can query the version of the OpenSSL package installed on your system by typing:
    rpm -q -a | grep "openssl"

    You should receive output that looks like this:
    openssl-1.0.1e-16.el6_5.7.x86_64

    From above shown output check the reported version on the official site for the list of affected version for the Heartbleed vulnerability. If the reported version is mentioned in the site under affected version the advised to update the OS or check the OPEN SSL package is updated properly.



  5. Revoking and Reissuing your SSL Certs/Keys

  6. If you have purchased an SSL certificate from a provider and you have updated your OpenSSL packages on your server, you will need to revoke your old keys and you'll have to reissue new keys. This is a process known as "rekeying". This process is very dependent upon the SSL service that issued your initial certificate, but you should search their administration interface for an option that is similar to "rekey" or "reissue keys". Most SSL issuers will revoke your former key when you rekey, but you can usually also do this explicitly using their administrative interface. Follow the directions that your SSL provider gives you. They may give you very specific instructions for how to regenerate a CSR, or they may not.

    If they do not provide you with the specific openssl commands that they would like you to use, you can generate your new SSL CSR by typing something like this. Again, add sudo if you are not root:
    openssl req -new -newkey rsa:2048 -nodes -keyout hostname.key -out hostname.csr

    You will need to copy your generated CSR into your provider's web interface after generation in order to rekey your server. You will then need to download the new certificate from the web interface.

    You will have to install the new keys to the same location that your old keys and certificates were kept. The path that you'll need to use for your certificate and keys will vary by distribution and how you configured your web server. For instance, some are kept in /etc/ssl/certs while others may be kept in locations provided by your web server.

    For example, if you are using the Apache web server, you should see a line in your main Apache configuration file, a virtualhost file, or a separately sourced configuration file that points to the location where it looks for your SSL information:
    SSLEngine on
    SSLCertificateFile /path/to/your_domain.crt
    SSLCertificateKeyFile /path/to/your_key.key
    SSLCertificateChainFile /path/to/CA.crt

    These may look different, but they should point you in the correct direction to find your SSL certificate location. When you are finished, you should restart your web server to use the new keys. The method of doing this will vary by distribution and server.

    On Debian or Ubuntu, you can restart your web server by typing:
    sudo service apache2 restart # For Apache web server

    On CentOS or Fedora, you can restart by typing:
    sudo service httpd restart # For Apache web server

  7. Additional Considerations from a Client's Perspective

  8. Because of the widespread nature of this bug, there are other considerations that you should take into account as well. As a consumer of web services and sites, you should also react quickly to try to minimize the potential damage to your accounts and information.

    • Change your password on every site that you use, after you have verified that they have updated their OpenSSL versions to patch this vulnerability. If you change your password prior to the remote site patching their SSL version, your new password is just as vulnerable as your old one.
    • Secure any VPN instances that you have set up. There are a few different ways that VPN connections are implemented, but SSL is one of the most popular. For instance, OpenVPN uses SSL. Any certificates required to connect to your server should be regenerated to ensure that they are secured.
    • Remove all session keys and cookies. This means regenerate API keys, clear cookies that are stored in your browser, etc. This may be a massive inconvenience, but the cost of not going through these pains now is that your accounts are basically wide open and communication with remote servers that have not updated their OpenSSL should be considered no more secure than plain-text.