Skip to main content
We are aware of an issue with a recent Apache update that causes proxied sites to return a "421 Misdirected Request" error. Please see the following article for more information and updates:
Websites show 421 Misdirected Request error while using EA Nginx

OpenSSL Heartbleed Bug (< 1.0.1g) - Encryption keys at risk

bouvrie
Mod Note - [COLOR="#B22222">Official Response by the cPanel Security Team has been posted to the cPanel Blog: Heartbleed Vulnerability Information - cPanel Blog [HR][/HR] Hi everyone. Any news on when OpenSSL 1.0.1g will be made available / pushed for us? Current version is 1.0.1e and that version is vulnerable to the OpenSSL Heartbleed bug. [QUOTE]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 communications, steal data directly from the services and users and to impersonate services and users.
[url=http://heartbleed.com/]Source. Test for vulnerability here. What is being leaked? Encryption is used to protect secrets that may harm your privacy or security if they leak. In order to coordinate recovery from this bug we have classified the compromised secrets to four categories:
    ]
  • primary key material,
  • secondary key material and
  • protected content and
  • collateral.
What is leaked primary key material and how to recover? These are the crown jewels, the encryption keys themselves. Leaked secret keys allows the attacker to decrypt any past and future traffic to the protected services and to impersonate the service at will. Any protection given by the encryption and the signatures in the X.509 certificates can be bypassed. Recovery from this leak requires patching the vulnerability, revocation of the compromised keys and reissuing and redistributing new keys. Even doing all this will still leave any traffic intercepted by the attacker in the past still vulnerable to decryption. All this has to be done by the owners of the services. What is leaked secondary key material and how to recover? These are for example the user credentials (user names and passwords) used in the vulnerable services. Recovery from this leaks requires owners of the service first to restore trust to the service according to steps described above. After this users can start changing their passwords and possible encryption keys according to the instructions from the owners of the services that have been compromised. All session keys and session cookies should be invalided and considered compromised. What is leaked protected content and how to recover? This is the actual content handled by the vulnerable services. It may be personal or financial details, private communication such as emails or instant messages, documents or anything seen worth protecting by encryption. Only owners of the services will be able to estimate the likelihood what has been leaked and they should notify their users accordingly. Most important thing is to restore trust to the primary and secondary key material as described above. Only this enables safe use of the compromised services in the future. What is leaked collateral and how to recover? Leaked collateral are other details that have been exposed to the attacker in the leaked memory content. These may contain technical details such as memory addresses and security measures such as canaries used to protect against overflow attacks. These have only contemporary value and will lose their value to the attacker when OpenSSL has been upgraded to a fixed version.

Comments

103 comments

Date Votes
  • craigedmonds
    I have run the following command: [QUOTE]rpm -q --changelog openssl-1.0.1e | grep -B 1 CVE-2014-0160
    It gives me this: [QUOTE][root@maggie ~]# rpm -q --changelog openssl-1.0.1e | grep -B 1 CVE-2014-0160 * Mon Apr 07 2014 Tom"" Mr"z 1.0.1e-16.7 - fix CVE-2014-0160 - information disclosure in TLS heartbeat extension
    So I assume that my openssl is patched and fixed. However, when I go to filippo.io/Heartbleed/ site, it still says that the site/server is vulnerable. Also if I use this chrome plugin its saying all my sites "could be" vulnerable:
    0
  • MaraBlue
    [quote="craigedmonds, post: 1617591">Any ideas?
    Did you reboot the server, or restart all services that use SSL (httpd, exim, dovecot, etc)? It's been repeated several times in this thread you need to restart all services.
    0
  • craigedmonds
    [quote="MaraBlue, post: 1617662">Did you reboot the server, or restart all services that use SSL (httpd, exim, dovecot, etc)? It's been repeated several times in this thread you need to restart all services.
    Restarting services did not work. Full reboot seems to do the trick. Not fun rebooting 20 servers!
    0
  • clarion
    [quote="craigedmonds, post: 1617591">I have run the following command: It gives me this: So I assume that my openssl is patched and fixed. However, when I go to filippo.io/Heartbleed/ site, it still says that the site/server is vulnerable. Also if I use this chrome plugin its saying all my sites "could be" vulnerable:
    0
  • serkanhamarat
    I updated a CentOs 6.5 than OpenSSL version is correct. Also the package changelog describes heartbeat fix. But, when I go to: WHM -> Server Status -> Apache Status, I saw this: [QUOTE]Server Version: Apache/2.2.24 (Unix) mod_ssl/2.2.24 OpenSSL/1.0.0-fips DAV/2 SVN/1.7.8 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635 mod_fcgid/2.3.6
    It still writes OpenSSL/1.0.0-fips . What is that?
    0
  • stef
    [quote="serkanhamarat, post: 1617822">It still writes OpenSSL/1.0.0-fips . What is that?
    You need to run EasyApache to compile apache/php against the new installed version of OpenSSL. -- Oops, seems to be wrong. I thought the header info was generated at compile time (fixed), but seems that info is pulled from the modules (like OpenSSL) at runtime. So a restart should be fine to have it show the new version, like @OkieDoke says below.
    0
  • OkieDoke
    Re: OpenSSL Heartbleed Bug (< 1.0.1g) - Encryption keys at risk [quote="cPanelMichael, post: 1616791">Yes, the output you provided indicates the patch has been applied: The RPM is patched, so you won't necessarily see a new version. Instead, you will see the CVE listed in the RPM change log. Thank you.
    It is essential that you do [QUOTE]service cpanel restart
    though. As I was showing vulnerable with the patched RPM until I restarted all SSL services. [COLOR="silver">- - - Updated - - - [quote="stef, post: 1617852">You need to run EasyApache to compile apache/php against the new installed version of OpenSSL.
    This is incorrect. OpenSSL is a seperately compiled package. A simple restart is fine. As long as your changelog shows something dated in the last couple of days then you're protected.
    0
  • markb14391
    @Monsta_AU, thanks! On DNS Only, I assume I should also regenerate remote access keys (and, of course, update any servers using those DNS servers in a cluster too).
    0
  • Shane_from_UK
    The OpenSSL Heartbleed Bug is fixed now but what happen, if my existing domains SSL key hacked before patching the openssl....what need to do to secure the existing certificates as we are using it for payment gateway...
    0
  • cPanelMichael
    We have published an article about the vulnerability here: [url=http://cpanel.net/heartbleed-vulnerability-information/]Heartbleed Vulnerability Information | cPanel, Inc. Thank you.
    0
  • ThinIce
    [quote="cPanelMichael, post: 1618041">We have published an article about the vulnerability here: [url=http://cpanel.net/heartbleed-vulnerability-information/]Heartbleed Vulnerability Information | cPanel, Inc. Thank you.
    Potentially moronic question on this if I may. Presuming in the worst case that information has been previously obtained due to this issue from a server such that it's SSL traffic can be intercepted and later decrypted, are the WHM interface pages 'safe' to use to generate new keys and certificates with? i.e. do they show these details / send them back to the browser (over the now potentially insecure link) before the service that is to use them (in the relevant case WHM) is restarted? Looking at the new interface I'm hoping not but it does look possible to me if the certificate details button is clicked that all certs and keys are loaded into the page within script tags. If I'm not being moronic, is there an interface / scripts to do this over ssh instead? I'm aware one can just replace the relevant files but I'm thinking of the general use case that isn't going to be happy doing that.
    0
  • quizknows
    Regarding service restarts, I found that httpd restart did not fix the issue, but a quick httpd stop ; httpd start did. you have to hard restart the services if you don't want to reboot the server.
    0
  • MaraBlue
    [quote="quizknows, post: 1618361">Regarding service restarts, I found that httpd restart did not fix the issue, but a quick httpd stop ; httpd start did. you have to hard restart the services if you don't want to reboot the server.
    That's *also* been detailed in this thread. Come on guys, read. It's only a 2 page thread.
    0
  • Infopro
    5 pages by default forum settings I believe. But your point is still valid all the same. :p [url=http://cpanel.net/heartbleed-vulnerability-information/]Heartbleed Vulnerability Information | cPanel, Inc.
    0
  • quizknows
    [quote="MaraBlue, post: 1618381">That's *also* been detailed in this thread. Come on guys, read. It's only a 2 page thread.
    I know it has been, but someone still asked ~10 posts before mine. People keep asking the same questions, they'll get the same answers :P
    0
  • PCZero
    OK folks it has been a while since I dug into some of this. Combine that with the fact that I just had major knee surgery and I am taking some pretty hefty pain killers you can understand that I am having a little difficulty. I got everything updated I believe. I got this... # rpm -q --changelog openssl | grep -B 1 CVE-2014-0160 * Mon Apr 07 2014 Tom"" Mr""z 1.0.1e-16.7 - fix CVE-2014-0160 - information disclosure in TLS heartbeat extension Which I believe means I am current. Ynder the assumption that all of that is correct, I want to proceed to reissue my certificate. I have followed all of the steps outlined by GeoTrust to get the cert reissued (new CSR, etc) and now have the final email from them with the new data. This is where I am having a brain fart and the pain killers are kicking in. In WHM 11.42.1 (build 5) hoe do I go about installing the new cert REPLACING the one I have installed already. Whichever is easiest (if even available) I can use either the WHM web interface or make changes shelled as root. If someone can give me the step-by-step drug addled idiots guide to this I would greatly appreciate it. At this point i would need a guide that even lists the "any stupid idiot would know this step" steps. Thanks!
    0
  • MaraBlue
    [quote="PCZero, post: 1618791">This is where I am having a brain fart and the pain killers are kicking in. In WHM 11.42.1 (build 5) hoe do I go about installing the new cert REPLACING the one I have installed already. Whichever is easiest (if even available) I can use either the WHM web interface or make changes shelled as root. If someone can give me the step-by-step drug addled idiots guide to this I would greatly appreciate it. At this point i would need a guide that even lists the "any stupid idiot would know this step" steps. Thanks!
    IME the best way is to remove the previous cert (including CSR and key), then install the new one. I did/tried it both ways, and without removing the previous old cert, cPanel screws everything up (sorry, cP peeps, but it does). I found the old CSR would be hostname.com 1, where the new key would be hostname.key (without the "1"), yet the old key would suddenly have a 1. There's no easy way to differentiate the *old* cert from the *new* cert (without opening each up, comparing to the backup...and that's too error prone). Do definitely keep a record of the serial number of the old cert before you delete it, so GeoTrust can revoke it (you have to email them for this). HTH, and hope you feel better. :)
    0
  • PCZero
    Mara, can you give me the click by click, ignorant DFU, idiot guide on how to do this. Assume I am sitting at my computer logged into WHM, staring at the screen and trying to figure out what to click and in what order. I don't want to assume even the simple stuff right now. These pain killers are pretty good! :) PS include the steps to keep a record of the old serial number etc please...
    0
  • MaraBlue
    [quote="PCZero, post: 1618811">Mara, can you give me the click by click, ignorant DFU, idiot guide on how to do this. Assume I am sitting at my computer logged into WHM, staring at the screen and trying to figure out what to click and in what order. I don't want to assume even the simple stuff right now. These pain killers are pretty good! :) PS include the steps to keep a record of the old serial number etc please...
    I just finished my taxes. I think you should share your pain killers with me. :) OK, here we go. This worked for me, YMMV, and all other standard disclaimers. 1. WHM -> SSL/TLS -> SSL Storage Manager. 2. Find the cert you want to replace, click the little magnifying glass. that will show "Resource Information", or the details of the cert. 3. In the second text box you'll see "Detailed Information." Right after the validity dates is the serial number: Validity Not Before: Apr 9 15:35:45 2014 GMT Not After : Nov 1 13:18:19 2016 GMT Subject: serialNumber = oU1IU2HodzjQ5P5AjXXXXXX <--- this number
    Copy that number and save it. 4. Assuming you already have the new CSR and key created (going by what you posted above), as well as the new cert, then go ahead and remove the old one(s) by clicking the red circle with the "X" in the center. Make sure you delete the old ones, and not the newly created ones. If you accidentally mess that up, it's no big deal, you can always have the cert reissued again. I had to do the shared server cert twice, because the first time I accidentally chose SHA-1 hashing instead of SHA-2. 5. still in the WHM -> SSL/TLS section, go to Install an SSL Certificate on a Domain. 6. Fill in the "Domain" just as it is on the certificate. 7. Find the IP if needed (depends on if this is a cert for the hostname, a user's account, etc). 8. Don't use auto-discover, paste the new cert into the box. Paste the new key (or verify that the NEW key is showing if WHM finds a key on the server...never assume it found the correct one, always verify it is in fact the correct one). 9. I normally let WHM find the CAB. So all that's left is to click the shiny install button, and you're done. :) I forgot to add, if the cert is for the server's hostname/shared hosting/services, don't forget to go to Service Configuration -> Manage Service SSL Certificates and "install" the cert for use by the services. This is SUPER easy now with the latest cPanel version. Go to "Browse certificates", find yours, click the checkboxes by all the services (cPanel, FTP, Exim, Dovecot), then another shiny "install" button at the bottom.
    0
  • h4ni
    Hello After i upgrade openssl, and restart services, when I go to filippo.io/Heartbleed/ site, i get : Uh-oh, something went wrong: tls: oversized record received with length 20291 Does any one have an idea?
    0
  • upsforum
    Heartbleed Bug and openssl old versions I have a vps with these specs CENTOS 5.10 x86_64 vmware WHM 11.42.1 root@vps5 [~]# openssl version OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008 root@vps5 [~]# rpm -q --changelog openssl | grep -B 1 CVE-2014-0160 root@vps5 [~]# official guides say that this openssl version not is vulnerable but if I use this tool [url=http://filippo.io/Heartbleed/]Test your server for Heartbleed (CVE-2014-0160) the result is that any sites on my vps are vulnerable
    0
  • h4ni
    [quote="h4ni, post: 1619012">Hello After i upgrade openssl, and restart services, when I go to filippo.io/Heartbleed/ site, i get : Uh-oh, something went wrong: tls: oversized record received with length 20291 Does any one have an idea?
    I have * Mon Apr 07 2014 Tom"" Mr""z 1.0.1e-16.7 - fix CVE-2014-0160 - information disclosure in TLS heartbeat extension
    0
  • Infopro
    Multiple threads merged here.
    0
  • MaraBlue
    I have heard of some false positives from the filippo.io checker. If you get an error there, and if you're sure you've followed all steps (including restarting all services that use SSL, or rebooting your server), then try the checker from SSLLabs:
    0
  • noimad1
    We did all this, yet when we go to [url=http://filippo.io/Heartbleed/]Test your server for Heartbleed (CVE-2014-0160) and run a test it still says we are vulnerable? Am I missing somethign. Here is the output: rpm -q --changelog openssl | grep -B 1 CVE-2014-0160 * Mon Apr 07 2014 Tom"" Mr""z 1.0.1e-16.7 - fix CVE-2014-0160 - information disclosure in TLS heartbeat extension nevermind...restarted all the services again and it worked.
    0
  • robb3369
    [quote="MaraBlue, post: 1619712">I have heard of some false positives from the filippo.io checker. If you get an error there, and if you're sure you've followed all steps (including restarting all services that use SSL, or rebooting your server), then try the checker from SSLLabs: found this after re-issuing several SSL certs...
    0
  • upsforum
    Re: Heartbleed Bug and openssl old versions I tried with geotrust and ssllabs but same result, the server is vulnerable: ------------------------------- geotrust result: OpenSSL Heartbleed vulnerability assessment Your server is vulnerable to Heartbleed attack. ssllabs result: This server is vulnerable to the Heartbleed attack. Grade set to F. (Experimental) --------------------------- [quote="upsforum, post: 1619021">I have a vps with these specs CENTOS 5.10 x86_64 vmware WHM 11.42.1 root@vps5 [~]# openssl version OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008 root@vps5 [~]# rpm -q --changelog openssl | grep -B 1 CVE-2014-0160 root@vps5 [~]# official guides say that this openssl version not is vulnerable but if I use this tool [url=http://filippo.io/Heartbleed/]Test your server for Heartbleed (CVE-2014-0160) the result is that any sites on my vps are vulnerable
    0
  • taeseer
    I tried to upgrade OpenSSL, and installed successfully however when I check its version openssl version OpenSSL 1.0.1e-fips 11 Feb 2013 (Not updaded to 1.0.1g) When I check from file cat /usr/local/ssl/lib/pkgconfig/openssl.pc prefix=/usr/local/ssl exec_prefix=${prefix} libdir=${exec_prefix}/lib includedir=${prefix}/include Name: OpenSSL Description: Secure Sockets Layer and cryptography libraries and tools Version: 1.0.1g Requires: Libs: -L${libdir} -lssl -lcrypto Libs.private: -ldl Cflags: -I${includedir} This file show updated new version 1.0.1g. Should I assume server is upgraded to new version or need any thing more? Taeseer.
    0
  • quizknows
    As stated before this issue does not affect OpenSSL 0.9.8e as shipped with CentOS 5
    0
  • magicalwonders
    Hello, I have a managed VPS running CENTOS 6.5 x86_64 virtuozzo with WHM 11.42.1 (build 5). I've carried out the steps as advised by Michael in post 18. But after testing the server using filippo.io/Heartbleed and getting the message "tls: oversized record received with length 20291" I noticed I'd missed - checking the SSL certificates in the Manage SSL Hosts interface of WHM. However, when I navigate to SSL/TLS " Manage SSL Hosts, it shows the following - [QUOTE]There are no secure sites configured on your server!
    Do I need to do something about this and generate self-signed certificates? I have two IP addresses. My primary, which WHM is installed on is a shared IP with other domains, plus I have another domain on a dedicated IP address. My understanding is that SSL can only be installed on dedicated IP addresses? Maybe I have missunderstood that? I'd appreciate some advice on what I need to do, if anything. Many thanks, Myles
    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post