Security Vulnerabilities

[Taz-Matt]

Hi,

I have tried searching both Google in general and this forum but I do not seem to find any information on how to fix Poodle, weak DH key exchange params, removing support for old protocols and allowing more recent ones, disabling weak ciphers.

With all the news about this in the last few years, I was thinking I could easily find that information.  Am I just not searching for the right keywords?  Does anyone have tutorials or procedures to fix these issues?

References:
https://www.ssllabs.com/ssltest/
https://cryptoreport.geotrust.com/checker/views/certCheck.jsp

Thanks for any feedback!
Matt.

[Lawrence]

Hi Taz,

Have you checked to see if you are affected by Poodle? Most servers by now should have patched a long time ago.

Create a bash file and run it with the following code. I'm attaching it as well in case the forum jarggles up the code.

#!/bin/bash
#
#  Copyright (C) 2014 by Red Hat
#
#  This program is free software; you can redistribute it and/or modify
#  it under the terms of the GNU General Public License as published by
#  the Free Software Foundation; either version 3 of the License, or
#  (at your option) any later version.

host=${1:-127.0.0.1}
port=${2:-443}
timeout_bin=`which timeout 2>/dev/null`

echo -n "$host:$port - "

out="`echo 'Q' | ${timeout_bin:+$timeout_bin 5} openssl s_client -ssl3 -connect "${host}:${port}" 2>/dev/null`"

if [ $? -eq 124 ]; then
   echo "error: Timeout connecting to host!"
   exit 1
fi

if ! echo "$out" | grep -q 'Cipher is' ; then
   echo 'Not vulnerable.  Failed to establish SSL connection.'
   exit 0
fi

proto=`echo "$out" | grep '^ *Protocol *:' | awk '{ print $3 }'`
cipher=`echo "$out" | grep '^ *Cipher *:' | awk '{ print $3 }'`

if [ "$cipher" = '0000'  -o  "$cipher" = '(NONE)' ]; then
   echo 'Not vulnerable.  Failed to establish SSLv3 connection.'
   exit 0
else
   echo "Vulnerable!  SSLv3 connection established using $proto/$cipher"
   exit 1
fi

[Taz-Matt]

Hi Lawrence,

Thanks for the reply!  Unfortunately, it is vulnerable :

[root@XXXXX ~]# ./poodle.sh
127.0.0.1:443 - Vulnerable!  SSLv3 connection established using SSLv3/ECDHE-RSA-AES256-SHA

The system has the most recent version of both HostBill and the OS.

If you take a look at the results of the tools I have shared in my original post or if you try it on a standard install of HostBill + updates on RHEL/CentOS, you will get the following security issues, amongst others:

This server supports weak Diffie-Hellman (DH) key exchange parameters.
This server is vulnerable to the POODLE attack. If possible, disable SSL 3 to mitigate.
The server supports only older protocols, but not the current best TLS 1.2.

Since the configs of HostBill seem to be custom (not simply website files), I do not want to mess around with config files and get an unsupported config that is hard to maintain.  So I was wondering if there were articles that show how to fix these issues that should be common on a lot of installations of HostBill at the moment.

I use other softwares for other purposes and companies who created those software all provide patches or tutorials showing how to resolve these issues, but not HostBill (that I know of up to now).  Does anyone have any info on this?

[BRJP]

I use other softwares for other purposes and companies who created those software all provide patches or tutorials showing how to resolve these issues, but not HostBill (that I know of up to now).  Does anyone have any info on this?

Hi Taz,

Just to be clear, these vulnerabilities have nothing to do with HostBill.  These are server level vulnerabilites caused by supporting SSL2, SSL3 and weak cyphers within web server and mail server etc.  You need to security harden your server - no alteration of HostBill will prevent these issues.

[Taz-Matt]

Hi BRJP,

Take a look at these processes:

[root@XXXXX ~]# netstat -lntp | grep 443
tcp        0      0 0.0.0.0:5443                0.0.0.0:*                   LISTEN      24488/nginx         
tcp        0      0 0.0.0.0:443                 0.0.0.0:*                   LISTEN      24488/nginx         
tcp        0      0 0.0.0.0:4443                0.0.0.0:*                   LISTEN      24488/nginx         

Nginx was installed by the Hostbill installer script.  After having purchased the license, that is what was written within HostBill's client portal under my license details:

-----
To install HostBill use instructions below:
# In your freshly installed Centos 6 x86_64 log in as root and issue command:

wget http://install.hostbillapp.com/install/install.sh && /bin/bash install.sh XXXX    (where XXXX is the license number/id)
-----

That is exactly what I did, right after I had performed a clean minimal install of the OS.  So basically, I have never had to configure anything except the settings within the app itself, which have nothing to do with the security issues I currently have.  There were no web servers installed by the original OS installation, everything was done by HostBill's script, so I am wondering why no one seems to know what I am talking about.

If anyone has anything to help, that would be very appreciated!  From what I see up to now, there might be a lot of installations of HostBill with those kind of issues out there and people might benefit from that thread.

Please note, I agree it is not the code of the app that is problematic, but the bundle that was installed by the custom install script HostBill has created.  I believe that HostBill is responsible of providing an install script that does not implement security flaws or providing patches or procedures to fix these security flaws as they are discovered with time.

Thanks again BRJP for pitching in! 
Matt.

[BRJP]

Hi Matt,

Thanks for the detailed response. 

So it sounds like HostBill has installed NGINX as part of the installation?  I cannot be sure, but it may have done this via YUM as part of the installation. NGINX is (as you know) a web server that can run HostBill.  (We use Apache only but thats another story!)

NGINX would have come with default settings - some of these would have been less secure than appropriate.  You would have to alter the NGINX configuration files to tighten the security for Poodle, Weak Cyphers, etc.  Otherwise the web server (that runs HostBill) will give you less than secure results when you perform a PEN Test or an SSL test.  As we run Apache for HostBill, we have configured the web server against the vulnerabilities you mention above.  This has provided us a (currently as vulnerability are ever changing!)  an A+ score on Qualys SSL Lab.

In summary, I think you did not have a web server before and as part of the installation HostBill installs a web server (NGINX).  NGINX by default is insecure and you have to tighten security via editing configuration files to minimise vulnerabilities.

Does that sound more plausible?  Or do you think there is still a separate issue?

[Taz-Matt]

Hi BRJP,

     Yes, that is exactly what I am saying.  And since this seems to be the way they want people to install their application (bundled with other software), then I think they should at least provide some kind of procedure to make it more secure, just like any other provider would usually do when they bundle stuff.

     Well, it seems like I will have to search for all the details and do it on my own until the scans look good.  It might be a good idea to take note of everything I do and post it here.

Thanks for trying to help, all help is appreciated when it comes to community support! 
Matt.

[BRJP]

Hi Matt,

Is there a link to your report you can send to me via PM?  Screenshots or whatever shows us some of the issues.

We can then have a look and see if we can take some of the pain out of it for you?

[Taz-Matt]

Hi Bradley,

    After an hour or so of finding the right config file (multiple copies in odd places), I have found that the right config file is :

/usr/local/kbkp-software/apps/b-nginx/usr/local/conf/port-80/main.conf

    Oddly, it is in the "port-80" directory but defines port 443 also.  In there, I have defined the following up to now :

    ssl_protocols  TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers "EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA256:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH:!aNULL:!eNULL:!MEDIUM:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RC4:!SEED";
    ssl_prefer_server_ciphers   on;

    And I am pretty happy with the results so far, getting an "A" rating on Qualys' SSL Server Test.  I might mess around with the settings again to verify if I can make it better without sacrificing too much on compatibility.

    Once the settings are written to the file, simply run the following to restart nginx and apply them :

/usr/local/kbkp-software/apps/b-nginx/etc/init.d/nginx restart

    Now I just hope that future updates I receive from HostBill won't affect those settings.  I doubt it since it is probably only done once at install time.  If I have further problems or if it becomes hard to maintain, I will move to Apache.  Will let you know of any further details.  I hope this helps anyone else who has the same setup.  And I sincerely hope that HostBill come up with an "official" article/tutorial on this to help people secure their new install as much as they need it to.  The default setup surely will not pass any PCI tests, making it really bad to store any customer payment information.

Thanks!
Matt.

[BRJP]

Good to hear that you are in the A ratings.   I am pretty positive  that HostBill will not overwrite any NGINX settings.

Give me a shout if you need any further support - I am happy to help where we can.

[Taz-Matt]

Thanks Bradley,

The only thing that I am worried about is for the nginx updates as this was not installed as an RPM or similar.  So now I wonder how I will keep it up to date easily without messing up the configs.  I'll surely find a way or revert to a more standard and supported Apache install.

Matt.

[Taz-Matt]

Hi,

Just letting know that I have finally decided to reinstall from scratch directly in Apache.  Was a bit longer to setup the OS packages and install manually than with the script that the company provides but I figured I will reap the rewards of doing it that way every month when I don't need to spend time on updating everything manually.  Also, it is a more "standard" install so if I hire anyone, they will be able to pick it up much faster.

Short: I would not recommend installing from the automated script HostBill provides.

Thanks for the help!
Matt.