All You Wanted to Know About the Heartbleed Bug

Apr 10, 2014 By Sharon Solomon

The steep rise in E-commerce and online transactions has made application security a major priority. SSL and TLS protocols were the benchmarks of online safety until recently. Everything changed when Random Storm, a British security company, exposed the Heartbleed bug. This major vulnerability has simply dented the once reliable OpenSSL technology.

Hundreds of websites have been at risk since the vulnerability was introduced back in 2011. The extent of damage is not yet known. Millions of passwords, usernames and credit card numbers could have been compromised due to this breach.

All CISOs and Security executives are busy re-configuring their networks and changing passwords for sensitive accounts. The panic is justified as more than two-thirds of the servers today completely rely on the OpenSSL protocol as their security backbone.

What exactly is Heartbleed?

CVE-2014-0160, nicknamed Heartbleed because of its location in the OpenSSL’s implementation of the TLS in the Heartbeat extension (RFC6520), is considered dangerous because it enables data and identity theft without being detected. The flaw enables hackers to read all communications between users and the vulnerable website even though the communications are encrypted.

The reason is that OpenSSL relies on what is called “keys” to encrypt and decrypt the communications. Making the analogy to the real-world, consider a locked briefcase. The locker ensures the data within the briefcase is secured against prying eyes. Only the holders of the locker’s key can open the briefcase and read the documents. The same goes for the digital communications –in this case, not being able to read the documents is equivalent to encrypting the data.

Bleeding Behind the Scenes

Getting a bit technical, let’s dive a bit into how OpenSSL works and take a look into the corresponding vulnerability.

In OpenSSL’s Heartbeat protocol, the client sends the server a request to read a certain amount of data in the message. It sends the server the number of bytes in needs to read (64k) and the data itself. The server then reads the exact amount of data in the message as specified by the client.

[Want To Check If Your Website Is “Heartbleeding”? – Click Here]

The issue though occurs when a hacker sends a message, specifying the number of bytes to read, but no data. The server then recognizes the need to read a certain amount of data – but since the server did not receive any data to read from the client, it instead reads that amount of data from the process memory and sends it back to the client. And that’s where the problem lies: the data from the process memory also includes the communication “key”. Ultimately, the hacker gains the communication key and so can read any communication between users and the website they are interacting with – even though communications are performed over an encrypted channel.

Yahoo and Heartbleed – A Security Disaster

Internet superpower Yahoo, the world’s second-biggest email provider and owner of Tumblr, has already confirmed that its data was compromised due to the vulnerability. This confession came after security researcher Scott Galloway run his privately-compiled Heartbleed script and harvested 200 usernames and passwords in just a few minutes.

Yahoo officials have said that their developers have fixed the leaks in their leading services such as Yahoo Mail, Yahoo Finance and Yahoo Search. But no concrete instructions for the Yahoo users have been made public so far. The good news – other big websites such as Google, Twitter, Facebook and Dropbox don’t have the aforementioned vulnerability.

How to Avoid Heartbleed?

Enterprises can prevent the bleed by looking at their server application code and ensuring that:

  1. The server reads only from a clean slate of memory. This means preventing the server from reading “uninitialized” code which might contain sensitive data.
  2. Ensuring that keys are destroyed after usage. Since hackers were able to obtain the keys, we know that OpenSSL is implemented in such a manner that the keys stayed much too long in memory. Yet, keys are the most sensitive piece of data that the server can hold –  the longer they are stored, the more the risk of exposure.

Please feel free to share your Heartbleed experience and know-how with our readers. Leave us a comment below.


The following two tabs change content below.

Sharon Solomon

Stay Connected

Sign up today & never miss an update from the Checkmarx blog

Get a Checkmarx Free Demo Now

Interested in trying CxSAST on your own code? You can now use Checkmarx's solution to scan uncompiled / unbuilt source code in 18 coding and scripting languages and identify the vulnerable lines of code. CxSAST will even find the best-fix locations for you and suggest the best remediation techniques. Sign up for your FREE trial now.

Checkmarx is now offering you the opportunity to see how CxSAST identifies application-layer vulnerabilities in real-time. Our in-house security experts will run the scan and demonstrate how the solution's queries can be tweaked as per your specific needs and requirements. Fill in your details and we'll schedule a FREE live demo with you.