OpenSSL "Heartbleed" Vulnerability

On April 7th, 2014 a security advisory was published for OpenSSL, revealing a vulnerability in versions 1.0.1 and 1.0.2, this vulnerability was code-named "Heartbleed". Please read the linked documentation to learn more about the vulnerability.

If you are hosting OAE, depending on the version of libssl deployed on your web node, you may or may not be affected by this OpenSSL bug. If your deployment was affected, here are things you should think about doing.

1. Upgrade OpenSSL

First and foremost, upgrade OpenSSL to a patched version (1.0.1g). There is a new version of libssl1.0.0 in the Ubuntu aptitude repositories. Upgrade, then reboot the machine. If you have multiple web nodes running with DNS fail-over, or just a standby for manual DNS switch-over, upgrade all web nodes. Even an idle/unused web node can be exploited to try and access SSL private keys.

2. Get new SSL Certificate(s)

If you have been running the affected version, definitely consider purchasing a new SSL certificate from your issuer. It is possible that an attacker has compromised the certificate using this exploit which allows eavesdropping by staging a Man-in-the-middle attack on your deployment. As OAE allows for running different tenants on different domains, it is possible you will need to purchase a new SSL Certificate for each domain if you do not use a wildcard certificate.

3. Change the cookie encryption secret

In the config.js file, there is configuration key config.cookie.secret which holds a complex private key for encrypting user cookies. To ensure all existing session cookies cannot be re-used, change this value and restart all your application servers. When this changes, all users using the system at the time will lose their sessions. This secret should be changed to the same value on all application servers.

4. Change Passwords

Just like an attacker can discover the private SSL certificate, they can acquire private user data such as username and password from the memory of the web server. You should instruct all users who have a username and password with the system to change their password. This includes:

• The global administrator password(s)
  • To do this, you can either use the API directly, or you can access an administrator user account widget by logging into any tenant from the Administration UI using the "Login" button for a tenant
• The tenant administrator password(s)
  • If you have "local" authentication enabled for any tenant(s) in the deployment, those users including the tenant administrators should be instructed to change their passwords using the user account management screen
• Regular user password(s)
  • If you have "local" authentication enabled for any tenant(s) in the deployment, those users including the tenant administrators should be instructed to change their passwords using the user account management screen