Heartbleed security bug: How it works

Others have not been as fortunate, with Mumsnet and Canada’s Tax Authority amongst those to announce that their data has been compromised.

A variety of opinions on the seriousness of Heartbleed have been put forward, ranging from “it’s not the end of the world” to “the sky is falling, duck and cover.” Usually the former refers to the relatively low percentage of sites impacted by Heartbleed, pegged at about 17 per cent or 500,000 sites by Netcraft.

And then there’s the impact on gadgets and devices we might not immediately think of. A wide variety of smart phones, IP phones, switches and routers have been identified as being vulnerable. Home internet routers and that nifty system you had put in that lets you mess with your house’s temperature from any device, anywhere are likely impacted. With the Internet of Things connecting more and more devices, the list has the potential to grow significantly. The growing consensus is that a plurality of the impacted devices will never be updated; leaving organisations that may interact with those devices vulnerable and in need of a mitigating solution that doesn’t rely on updates or changes to the device.

There will be, as everyone scrambles to protect customers and consumers from Heartbleed, a variety of mitigating solutions offered up to address this pesky bug. Network devices will enable organisations with the visibility necessary to detect and reject requests attempting to exploit the vulnerability.

There are a variety of points within the data path where solutions could be put into place to mitigate this (and similar) vulnerabilities. Customers must choose the most strategic point in the network at which to deploy their selected mitigation. To choose that point, organisations should ask how the exploit is detected by given solutions. To see why that’s necessary, consider how the attack works.

How Heartbleed works

Heartbleed takes advantage of a missing length check in the OpenSSL code handling a relatively innocuous extension to the TSL/SSL protocol (defined in RFC 6520). It comprises two simple messages: a request and a response. The request can be sent by either the client or the server as a means to keep the connection alive. The sender ships off a HeartbeatMessage with a small amount of data, expecting the receiver to send back that same data. What’s important about the protocol interaction is that whichever party sends the request determines the length of the response. The sender tells the receiver how much data it’s sending – and therefore how much should be returned.

Now, the OpenSSL code should be making sure the length the attacker says he’s sending is actually what’s available. The code, however, does not. It simply trusts the sender and grabs whatever amount of data was specified out of memory. This is how an attacker can access data that’s in memory and wind up with all sorts of sensitive data like passwords and private keys.

Mitigation options

Because this exploit takes advantage of a vulnerability in encrypted communications, any mitigating solution must be in the path of that communication. That’s a given. In that path are three points where this exploit can be mitigated:

1. Client

You can check the client operating system and device type and match that against known usage of the impacted OpenSSL versions. Once detected, the client can be rejected – preventing the offending request from ever being sent in the first place. Rejection of clients based on the possibility they might be an attacker can result in angry legitimate consumers, employees or partners, however.

2. On Request

Inspect client requests and upon discovery of a HeartbeatMessage, reject it. This prevents the request from being forwarded to vulnerable systems and servers.

3. On Response

Inspect responses and upon seeing a HeartbeatMessage response, check its length. If it’s greater than a length you feel comfortable with, discard it. This method will prevent attackers from receiving sensitive data, but it should be noted that at the point of discovery, the server – and data – has already been compromised.

The right place to implement a mitigating solution is one that will afford you the choice of your mitigating solution – or allow all three, if you really want comprehensive coverage. In most networks, that strategic point of control is the application delivery firewall.

The right tool is not just one that has the right position in the network. It takes visibility and programmability to dig deeply into the network stack and find the data indicative of an attack – intentional or not. The right tool will be able to distinguish between client side and server side traffic and apply the applicable logic. 

The logic that detects Heartbleed on the client side is different than that of the server side. In the case of the client it must look for a specific message indicating a Heartbeat request or inspecting the client device environment itself. On the server side, it’s checking the size of the response. Each of these cases requires unique code. That means the right tool must have a programmatic environment that can execute with surgical-like precision the logic necessary at the right time – at the time of connection, on request and on response.

Action items

At this point, nearly a week after the exposure of Heartbleed, organisations should have a good handle on how it works and the impact on their business. There’s no question the response to Heartbleed involves server patches and upgrades and the procurement of new keys, with consumer password change processes to come soon thereafter. 

In the meantime, servers (and thus customers) remain vulnerable. Organisations should be looking at putting into place a mitigation solution to protect both while longer-term plans are put into action.

Written by F5 Networks‘ Lori MacVittie.

Image source

Share this story

Close
Menu
Send this to a friend