banner

Thales Blog

Vormetric And Heartbleed: Remain Calm And Keep Encrypting

April 11, 2014

KCVM

If you’re reading this blog, chances are good that you’ve heard of a horrid bug in OpenSSL named Heartbleed.  Rarely has a software bug caused such a ruckus in the security community.  The bug is sufficiently bad – an attacker can read random parts of the server’s memory – that an upgrade to the fixed version is an urgent matter.  To add to this, the versions of OpenSSL with the bug are very widely used – up to 2/3rds of all encrypted internet traffic by some estimates.  This certainly caught the attention of practically every computer HW/SW vendor and the IT world.

After a thorough evaluation, Vormetric has determined that the impact to Vormetric software is not catastrophic, but an upgrade to a patched version is very strongly recommended.   There are a few reasons that this bug is not catastrophic.  Many parts of our Data Security Manager don’t use OpenSSL and hence aren’t vulnerable.  On our agent side, we use OpenSSL, but the most important asset – the encryptions keys – remains protected.  Regardless, the version of OpenSSL that we currently use – “1.0.1f” - is vulnerable, and we are going to issue patches for our DSM and agents.

Let’s start our analysis on the Data Security Manager side.  The DSM’s web UI, web services interfaces, and communication to the agents does not use OpenSSL, so we’re good there.  The SSH interface does use OpenSSL, but the SSH protocol is not vulnerable.  The DSM also can (if properly licensed) be a KMIP server, and that interface does use OpenSSL.  Unfortunately, this interface is vulnerable.  However, this service is only available if licensed and this currently only affects a small slice of our customer population.

On the agent side, we use OpenSSL for all traffic to our DSM.  The agent listens for connections from the DSM, and so it does function as a TLS server.  Unfortunately, this interface is vulnerable.  However, this is mitigated somewhat by the way that we have always protected the data encryption keys.  The keys that protect data are themselves encrypted with another key as they go over the wire, and aren’t decrypted until they are used much later.  What could be exposed are metadata items, like policy information, guard point locations, and so forth.  In a highly rare occurrence some private authentication keys for the agent could be compromised, but they won’t be worth much – they still won’t lead to data encryption keys being compromised.

When this attack is performed against the agent, the following warning message is displayed in the agent’s log:

2014-04-10 08:34:59.796 [VMD] [WARN ] [11139] [COM4635W] A machine identifying itself as 127.0.0.1 tried to contact the VMD, but there was an error: SOAP 1.1; "SOAP-ENV:Server"; Subcode: "[no subcode]"; Reason: "EOF was observed that violates the protocol. The client probably provided invalid authentication information."; Detail: "SSL_accept() failed in soap_ssl_accept()".

What this message is telling you is that someone not holding a proper certificate attempted to communicate with this agent.  This is never good.

Our Application Encryption product (also known as our Key Agent) is not vulnerable to this issue, since it only acts as a client in a TLS connection.

Previously I was of the opinion that our agents and KMIP code was more secure than it actually was.  I was under the impression that because our agents and KMIP code required a signed certificate (also known as “TLS Mutual Authentication”) we would avoid this issue.  It turns out that I was quite wrong on this count.  Our initial use of several Heartbleed detection scanners (including Nessus and Rapid7) indicated that we weren’t vulnerable.  It wasn’t until we ran a detection script from Steffen Ullrich that I realized the real situation.

We at Vormetric are taking this vulnerability very seriously.  We certainly don’t want this OpenSSL bug anywhere near our software, no matter the probability of it being exploited or the ramifications.  We are currently working on issuing patches for this issue in both the DSM and in our agents.  We will be running these patches through our intensive QA process, and intend to have the patches generally available soon.