Heartbleed: Examining The Impact

There's little hope of knowing if an asset was breached, if a breach can be identified, or if any data was leaked. Here's how to defend against future attacks.

Yesterday saw the beginning of the most significant breaches in Internet security to date. I'm talking, of course, about the vulnerability that was discovered in OpenSSL (CVE-2014-0160), commonly known as Heartbleed.

This was not a breach like the ones we've grown accustomed to hearing about in recent months, such as Target, Drupal, or the California DMV, wherein customers' personal data or login credentials were leaked. Instead, this breach strikes at the heart of encrypted transfers to the servers we all use in our day-to-day lives.

The Heartbleed vulnerability exists in all default versions of OpenSSL going back to March 2012. Among the products that use OpenSSL are Apache, IIS, Nginx, Cisco AnyConnect, your home router -- it's harder to come up with a list of Web products that don't use OpenSSL than a list of those that do.

What exactly does this vulnerability do, and why is it so bad? Basically, Heartbleed allows an attacker to abuse a normal function of SSL, known as the heartbeat. The vulnerability permits an attacker to read bits of memory on an affected server to which he or she should not have access. Since the bug occurs at such a low level, merely connecting to a vulnerable system and sending it a specially formed request is enough to trigger the vulnerability. No authentication with the server is required. In practice, this means that attackers can connect to a vulnerable server, keep the connection alive, and wait for something interesting to come to their way.

Read the rest of this article on Dark Reading