Critical OpenSSL vulnerability

A security vulnerability in OpenSSL was published on April 7. With this vulnerability, an attacker is able to remotely dump the memory contents of a process using OpenSSL.
This exposes both the content of SSL/TLS encrypted communications, and the associated private keys. This is a major issue as OpenSSL is a critical component of most encrypted Internet services.

Basefarm’s Security Incident Response Team, together with other Basefarm personnel, investigated which of the servers hosted by us were affected, and to what extent. Those services which were managed by Basefarm were then patched and affected customers were notified. This was completed Tuesday afternoon.

There is unfortunately no way of knowing for certain which information has been stolen during the attack window, so we recommend anyone being affected by this vulnerability to assume that your SSL/TLS private keys have been stolen, even if we have no concrete indication of this.
This means that you will need a new key pair and certificate for any exposed SSL/TLS keys and certificates. Basefarm will help you with this if we manage the keys for you. Your old certificates will also need to be revoked.

Any other information passed over a vulnerable SSL/TLS connection may also have been captured, including usernames, passwords, credit card numbers and other personally identifiable information.
We recommend that you initiate a password change for any account where the password has been passed over av vulnerable SSL/TLS connection over the last day or so.

Please note that if Personally Identifiable Information, credit card or cardholder data, or other sensitive data may have been compromised, you probably have an obligation to alert the proper authorities.
Unfortunately, there is no way of knowing exactly which data has been compromised.

Here are the mitigation steps in detail
1. Emergency fix the vulnerability itself by patching, reconfiguring, or both, on all exposed servers.
2. Generate a new key pair following best practice guidelines.
3. Purchase a new certificate using the new key pair. Without a new key pair, the old and possibly stolen key pair could be abused, e.g. to eavesdrop or to impersonate the service.
4. Switch to the new certificate on all relevant servers.
5. Revoke the old certificate. This is important, as otherwise a stolen private key could still be used to impersonate the web server until the old certificate expires.
6. Consider initiating a change of all passwords etc. that have been sent over SSL/TLS using the old key pair, at least those sent over the last day or so. If someone has an old “recording” of an encrypted conversation, and also gets hold of the old keys, they can now decrypt that conversation. There’s nothing to be done about that in itself, but any reusable credentials could be stolen this way and abused if they are not changed.

Step 6 really is up to you and/or your end users. High-profile and/or high-value sites would be well advised to at least recommend that their users change their passwords, and could use this as an opportunity to convey a strong message that they care about the security of their users.
We have previously written a note in our security tips section of this newsletter about passwords:

So what are the lessons learned?
Things can always be done faster and automated better and that’s something we’re always working towards, and in this case we should have focused a bit more on communication – actually been better at informing the customers that we were working with patching their services.