Another week, another new SSL exploit

Late last week, a new SSL bug was discovered by Google Research Labs. Simply put, due to the large number of protocols, clients and servers, most clients will start with the highest supported protocol and downgrade accordingly in order to be compatible to older servers. The weakness happens in SSLv3 which is 18 years old which can allow an attacker with sufficient computing resources to guess the encrypted data. For the more technical reader, here’s a link with more details.

While exploiting this bug is fairly difficult due to the large amount of computing resources needed, once the exploit was known, our team started putting together an action plan within hours. We started off implementing a patched version of OpenSSL on all servers which support TLS_FALLBACK_SCSV. This is a mechanism that solves the problems caused by retrying failed connections and thus prevents attackers from inducing browsers to use SSL 3.0. It also prevents downgrades from TLS 1.2 to 1.1 or 1.0 and so may help prevent future attacks.

However we did not stop there. We continue to refine our response and came out with methods to disable SSLv3 on all the main servers on our clients and our own servers. This includes:

  • Apache Web Server
  • WHM / Cpanel Control Panel
  • POP3 / IMAP Mail server
  • Exim SMTP server

This ensures that SSLv3 is no longer available to be exploited even if there’s some still unknown method to exploit it.

While this may break support for older clients, we estimated this to be of very limited impact. The security advantages also fair outweighs the disadvantages. If in doubt, please feel free to contact our support team.

Bash Vulnerability – Shellshock Exploit

What is it?

Chances are, you’ve already heard about the recent discovery of what’s being called the “Shellshock” exploit in GNU Bash. This is a vulnerability that existed in Bash through versions that have span 25 years. However as it is a little used function, the exploit did not come into light till this week. The vulnerability can result in remote execution of arbitrary code.

Bash is widely used by many popular Linux distributions and Mac OS X. This means that the exposure surface is extremely large. As the bug has been in the wild for many years, it is unknown if this exploit have been used in the past.

Critical instances where the vulnerability may be exposed include:

  1. Apache HTTP Server using mod_cgi or mod_cgid scripts either written in bash, or spawn subshells.
  2. Override or Bypass ForceCommand feature in OpenSSH sshd and limited protection for some Git and Subversion deployments used to restrict shells and allows arbitrary command execution capabilities.
  3. Allow arbitrary commands to run on a DHCP client machine, various Daemons and SUID/privileged programs.
  4. Exploit servers and other Unix and Linux devices via Web requests, secure shell, telnet sessions, or other programs that use Bash to execute scripts.

Am I affected?

For servers running RHEL/CentOS 5/6/7, our team was aware of the issue the same day it was made public on 24th September. Our team worked through the night to ensure the patch was applied within hours after it was released. The first patch was incomplete and we applied a 2nd patch the next day, once again within hours after the patch is available.

With respect to the above potential issues, we will like to explain how our managed servers using our default security policies are unaffected. We have kept it general on purpose:

  1. Most of our servers do not have mod_cgi in use. On top of that, we do not run PHP under CGI wrapper. Further to that, we restrict some key functions of PHP that would have made this a more dangerous bug such as system / exec.
  2. Most of our servers do not allow external shell access. For those that do, we do not use Bash as the shell. There are also other policies limiting access to only authorized users.
  3. We disable all unnecessary services including DHCP, etc during setup.
  4. Please refer to response 2 above. Another exposure surface we can foresee is the use of cron which may allow some users to put malicious commands. However, we currently do not run these jobs under Bash as well, but is using a separate shell.

If you have a specific area or question you like to clarify, please feel free to open a ticket with us. We will be happy to address any concerns directly for our clients.

How to secure SSH

In our work with clients, we do a lot of server management and security hardening on the servers before it’s released to the clients. One of the first things we typically work on is to ensure SSHd is secured. The reason is that any kernel root exploit will be made easier with shell access.

This tutorial is not meant to be all encompassing, although we will cover a few key areas. We will use Redhat / CentOS Linux distribution as an example and file paths will vary depending on the distribution. We will also use “nano” as the text editor in the examples.

Change the SSH port

While security by obscurity is heavily criticized in some quarters, the truth is due to the time taken to scan all the ports, unless it’s a targeted attack, this step should immediately stop scanners dead in their tracks.

nano /etc/ssh/sshd_config

Change:

#Port 22

to (Replace “NEW_PORT” with your port of choice)

Port <NEW_PORT>

Allow only strong protocols

Version 1 of the SSH protocol has many weaknesses, of which it’s out of scope of this article to discuss. But we will be disabling it.
Change:

#Protocol 2,1"

to

Protocol 2

Allow only strong protocols

Version 1 of the SSH protocol has many weaknesses, of which it’s out of scope of this article to discuss. But we will be disabling it.
Change:

#Protocol 2,1"

to

Protocol 2

Disable Password Authentication

We advise that you consider using only key authentication with your server. This means that even if someone someone get your password, your server will continue to be secure. If you are unsure about how to generate a SSH keypair, do refer to our quick tip here.

Change:

#PasswordAuthentication yes

to

PasswordAuthentication no

On top of that, you would need to disable direct root login:

Change:

#PermitRootLogin yes

to

PermitRootLogin without-password

 

Restart SSHd:

/etc/init.d/sshd restart

Enjoy better SSH security!

How to generate SSH keypairs

We will be using Redhat / CentOS conventions in our examples in terms of the file paths.

Generate the Key Pair

ssh-keygen -t rsa -b 2048

This should generate the files in ~/.ssh/, “id_rsa” and “id_rsa.pub”

id_rsa is your private key and should NEVER be given out. id_rsa.pub is your public key which can be freely shared.

Enjoy better security!