Movaci and Heartbleed

In the wake of April 7th’s disclosure of CVE-2014-0160 the Movaci Technical team has been working along with a number of service providers and software vendors to address this urgent issue. Movaci’s servers use a number of OpenSSL libraries for communication that were found vulnerable.  As we were rushing to make changes, we also stepped back to analyze the issue, identify what might be affected, and work to provide the best possible fix.

Summary

We believe this vulnerability is unlikely to be used to reap information from our servers from user’s private data such as passwords or emails.  Simple analysis of all possible indicators of such an attack (much like Monte-Carlo simulation with deterministic outcomes) was taken to ensure we catch all possibilities of attacks and its indicators.  Practically the analysis was done using number of simulations of reaping data using the OpenSSL vulnerability on a snapshot of our server with vulnerable libraries.  Attack scenarios and analysis is detailed below.

1. Stealing of Private Keys and Certificates

It is highly unlikely that any of our certs were stolen, using a simple analysis of various SSL reaping scripts and simulating possible outcomes/ indicators in logs, IDS events and system alerts.  This is mainly from the fact that these type of reaping to run thousands if not millions of queries against our server was not seen in the past 3 months of logs and IDS alerts we maintain on our server.  This includes looking at a single network resource or a single behavior (bytes/packet) from multiple network systems resembling a harvest of private information on our server.  (Read related)

2. Attack Access Methods

The attack is most effective in using http and reaping information from our servers that perform authentication.  These would be our primary mail systems and our VPN servers. Our VPN server was patched against this about 3 months before the vulnerability release.  This was basically because the updated image on our VPN server just does not allow heartbeat feature of SSL to be available. This was coincidental and not planned to really mitigate this vulnerability. On our mail servers the problem of reaping any information is restricted by a number of factors.  While OpenSSL is vulnerable we also protect our mail servers with memory protection by running micro processes and restart of services to provide clearing of much memory cache of sensitive information. This makes it difficult to gather past information from http sessions.  Analysis of our logs from past 6 months reveals not attempt either from a single network address or from a behavior a successful scan that will allow someone to reap large amounts of data over the network. Our other servers exposed over the internet do not carry any user data or private data but what is publicly available only through secure channels.  These servers do not carry any session information or user’s data.

3. Patch cycle and our security monitoring / auditing

Our mail servers were patched about 3 hours after the public release of the vulnerability (April 7th 2014).  Our VPN servers were already updated 3 months before, disabling this attack access method.  This we seem as a reasonable response time.  Analysis of logs during our log retention of 3 months, only shows number of scans after vulnerability exposure from small amount of network addresses using many public services such as Symantec’s heartbleed check, Qualys SSLlabs,  http://filippo.io/Heartbleed home-grown heartbleed test and similar ones to our mail servers.  Similar attempts to our public servers were not analyzed as they don’t really carry any sensitive information.

4. Web session protection and session hashing

Our critical servers have a further protection of http session protection.  Any private information such as a stolen session key or HTTP Cookie, cannot be reused on our server.

If a session is broken with either a network change (network address, traffic hops) or through an access method change (browser, concurrent session); we completely destroy the temporary session forcing the user to login once again.  This we feel like a critical way to protect even logged in sessions that are provided via our mail server. Note: Heartbleed, although simply explained (in blogs, news etc.) and talked about a lot on the web, is a complex attack vector.  This can be confusing for non-technical users as there are several factors in play to successfully complete such an attack.  Strangely these include factors that may not have been considered such as how busy the SSL offloading servers/systems are, how many of these servers exists and what private information (if any) resides in them.  We recommend that you consult experts to ensure what you are reading with a dialogue to better understand the issue.  If you are able to simulate this in a test environment many of these will become obvious to you as it has to our technical team. Security is Movaci’s number one priority. We take security very seriously and continue to do our best to respond to these type of emergencies in a calculated way.  Although it is unlikely that any data was compromised, we recommend that you continue best security practices such as change passwords regularly, use password only from systems that you own and not from public computers and finally adopt reliable web password access methods we already provide such as based password that requires a pin number and a randomly generated password code for each web login.

Questions?

Contact our technical support team via http://my.movaci.com