You almost have to be on some deserted island with no Internet access to have not heard about the OpenSSL Heartbleed vulnerability. This vulnerability is very serious and pervasive because of a few simple reasons:
1) it allows attackers to be able to dump a target’s memory which can include among other things, usernames/passwords, emails currently opened by an email client, private and secondary OpenSSL keys/certificates or data being accessed by programs running on the target system 2) the OpenSSL library with the bug is free, therefore, it’s on a LOT of systems on the internet 3) there is no log of an attacker accessing a site 4) the bug was recently discovered but has been around since 3/2012.
It’s obvious that capturing a username and password is not a good thing but the ability to capture the private and secondary OpenSSL keys means that the attacker has the ability to decrypt SSL traffic between the client and the server. Since items transmitted from client to server via these encrypted streams usually include sensitive information such as bank or debit account numbers, credit card numbers (CCN), social security numbers (SSN), you can see why security professionals are worried.
The bug was simple. Heartbleed is a play on the term “heartbeat”. A “heartbeat” is simply a communication between 2 systems letting each other know they’re still alive (connected). For example, a web client would send a heartbeat to a web server by sending a string of characters and asking the server to send them back to the client. The client sends a string and the length of the string being sent. The length figure can be up to 64 KB. Normally, the server would echo back the string. A sample transaction might look like this from a high level:
1. Client to Server: I’m sending you 5 characters ABCDE
2. Server to Client: I’m sending you those 5 characters ABCDE back.
The OpenSSL function that does this is supposed to send the correct length string but (here we go) if you say “I’m sending a 64KB length string then send just one byte, the server would send back 64KB of memory data. What’s in the remaining 64KB-1 bytes that came back to the client? Any number of things including usernames, passwords, etc.
You’re probably thinking, “Why didn’t they include a check to make sure your length and actual length fields matched?” Well, the authors were asking the same question. That was the bug.
What Should My Response Be?
It’s the answer every CISO hates: “it depends”. First, you have to scan your net to see if you had any vulnerable systems running OpenSSL v1.0.1-v1.0.1f. If you did, then you need to determine what function your server performs. If your server handled user authentication, there’s the possibility that user credentials may have been copied. An appropriate response would be to fix the systems, verify the fixes and then force a password reset for all user accounts.
Here’s where the “it depends” answer makes your life miserable. There’s no way to prove that user credentials or any other items in the server’s RAM were copied. You’re forced to act in a “better safe than sorry” mode.
Mashable lists some of the major Internet services that were affected by Heartbleed. Most of the major services suggested you change your passwords to be “better safe than sorry”. We decided to be “better safe than sorry” and forced a password reset at our site. As of this date, 43K users have changed their passwords. We started a PR campaign telling our user community that they had to change their passwords. We enlisted our Public Relations group, the various groups in charge of the technical aspects of mitigation, the Help Desk and of course, upper management approval.
One pleasant surprise was the speed of an affected sysadmin’s response. When we first scanned our net, we found ~480 systems with the Heartbleed vulnerability. Within 24 hours, that number went to ~220 systems. After 5 days, there were ~48 systems left. These systems were embedded systems waiting for a vendor patch to be created. The sysadmin community’s response was exemplary and helped tremendously to contain the threat.
Here are some links that contain some useful information about Heartbleed:
http://xkcd.com/1354/ – a great XKCD cartoon that explains how heartbleed works
http://mashable.com/2014/04/09/heartbleed-bug-websites-affected/ – the Heartbleed hit list. Contains a list of common Internet services (Gmail, Hotmail, banking sites, etc.) and whether they were affected and the response to the vulnerability. This is a “Must Read”.
http://www.heartbleed.com – technical description of the bug.