In the Wake of Heartbleed Part 1: Three Observations

Now that the dust has settled in the aftermath of the Heartbleed bug, I thought it might be useful to summarize some of the things Cradlepoint learned and did that will help us better protect our clients in the future.  Let me be clear that Cradlepoint acted swiftly to resolve the issues created by Heartbleed as soon as the vulnerability was discovered. I’ll talk about the remediation steps we took in my next post.

In a previous life I spent 13 years managing LAN, WAN, and wireless for top-brand stores with thousands of locations. I know the implications of having to patch thousands of devices out in the field: how hard it can be, how long it can take, and how stressed out you become until you’re sure your network is protected again.

As you may know, the Heartbleed bug took advantage of a vulnerability in the open source standard of OpenSSL that everyone uses for their SSL encryption. It showed up in specific versions of OpenSSL, from 1.01 through 1.01F.

There are three particularly interesting things about Heartbleed.

  1. It was out there for a long time: It’s amazing how long the vulnerability existed before anyone knew about it. Heartbleed was introduced into SSL with the release of version 1.01 on March 14, 2012. It wasn’t until about April 7, 2014—more than two years later!—that news of it became public. (Some people found it a little sooner than that. But it wasn’t widely known until the 7th of April.)  At that point, version 1.01G was released to patch devices, applications, operating systems, and so forth.
  2. It affected so many things: Heartbleed created problems in so many different areas. It wasn't just a problem for web applications. It also affected websites, servers, routers, switches, and network storage devices. Typically, malware or viruses affect a limited number of things. Heartbleed went across all these different platforms.
  3. It was virtually transparent: Heartbleed didn’t leave any clear tracks or abnormal entries in logs or records. It was very hard to tell if somebody actually used it, got in, and did something. That's the scary part of it: it’s difficult to know for sure how many systems were compromised and what data was taken because the bug was so transparent. Heartbleed created an open door. Short of looking for access floods, there’s no way of knowing if somebody came through that door.

Heartbleed worked by allowing hackers to compromise the certificates that are used to encrypt data. This meant they would be able to read traffic that would normally be encrypted—such as from a PC to an online shopping site. Heartbleed enabled hackers to get a hold of those encryption keys and use them to view the data that was going back and forth.

That could be credit card data. It could be user log-ins, passwords, and other data from a websites cache. It could be propriety information such as trade secrets or stock market trading. Anything that was going over the public internet that could be accessed normally over HTTPS or SSL could potentially have been compromised.

For all these reasons, Heartbleed was a very challenging bug. In my next post, I’ll talk about what Cradlepoint did to protect our clients as quickly and effectively as possible. Later on, I’ll talk about how companies that have Cradlepoint’s NetCloud Manager had a much easier time dealing with Heartbleed.

In the Wake of Heartbleed Series:

Part 1: Three Observations
Part 2: All Hands on Deck
Part 3: How NetCloud Manager Gave Customers an Advantage Over Heartbleed