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.
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:
- Apache HTTP Server using mod_cgi or mod_cgid scripts either written in bash, or spawn subshells.
- 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.
- Allow arbitrary commands to run on a DHCP client machine, various Daemons and SUID/privileged programs.
- 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:
- 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.
- 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.
- We disable all unnecessary services including DHCP, etc during setup.
- 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.
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!
What is it?
Chances are, you’ve already heard about the recent discovery of what’s being called the “Heartbleed” bug in OpenSSL. Basically, this is a vulnerability that existed in OpenSSL for around 2+ years. The vulnerability caused by a gap where encrypted information could potentially be leaked out to hackers. It is important to note that this is NOT due to a flaw in SSL, but rather the platform and implementation of the latest batch of OpenSSL updates.
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.
Given the widespread use of OpenSSL on the internet as the implementation for SSL, and the fact that the bug has been in the wild for years, this means that it is possible that a lot of sensitive information may have been stolen by hackers.
Am I affected?
For servers running RHEL/CentOS 5, the version of OpenSSL used is not affected. For servers running RHEL/CentOS 6, the bug was patched the same day the bug was made public. For all servers managed and hosted with us, we have automatically patched the bug the day it was made public on affected servers. However this does mean that you are not vulnerable to the issue. The key used for your SSL certificates may have already been stolen in the time the bug is in the wild.
For safety, if you are running RHEL/CentOS 6, you are recommended to rekey your domain and request for a reissue of the certificate. If you ordered the certificate from us, we will be regenerating the keys and reissuing the certificates automatically as well.
Personally if you have changed your passwords on any affected sites over the past 2 years, you are encouraged to confirm that the affected site have updated their certificates and change your passwords again.