Further Reading

When the critical flaw in the OpenSSL cryptographic library came to light 11 days ago, it was best known as a dangerous hole that allowed attackers to siphon out user names, passwords, and even private encryption keys processed by vulnerable Web servers. More recently, researchers confirmed that Heartbleed could be exploited to steal the private keys underpinning the widely used OpenVPN application and likely software for other VPNs that rely on a vulnerable version of OpenSSL.

On Friday, researchers with network security firm Mandiant said Heartbleed had been used to subvert a customer's VPN concentrator, an appliance that typically provides a secure way for people to access a network from outside the organization. The devices frequently require multiple forms of authentication before granting access to an end user. Passwords, previously set authentication cookies, and other types of security tokens are frequently used. That's where Heartbleed came in handy for the hackers, who went to work exploiting the bug less than a day after it became public knowledge. A separate researcher theorized such an attack was possible the same day.

Active user sessions hijacked

Instead of probing the client's VPN for passwords or encryption keys, the attackers looked for session tokens set by the targeted concentrator, which relied on a vulnerable version of OpenSSL. In a blog post, Mandiant researchers Christopher Glyer and Chris DiGiamo explain further:

Beginning on April 8, an attacker leveraged the Heartbleed vulnerability against a VPN appliance and hijacked multiple active user sessions. Specifically, the attacker repeatedly sent malformed heartbeat requests to the HTTPS web server running on the VPN device, which was compiled with a vulnerable version of OpenSSL, to obtain active session tokens for currently authenticated users. With an active session token, the attacker successfully hijacked multiple active user sessions and convinced the VPN concentrator that he/she was legitimately authenticated. The attack bypassed both the organization’s multifactor authentication and the VPN client software used to validate that systems connecting to the VPN were owned by the organization and running specific security software.

The exploit method was identified and confirmed by analyzing two sources of information, IDS signatures and VPN logs. The victim organization implemented a set of signatures to identify Heartbleed network activity. The IDS signature “SERVER-OTHER TLSv1.1 large heartbeat response – possible ssl heartbleed attempt”, depicted in figure 1, alerted over 17,000 times during the intrusion. The source of the heartbeat response was the organization’s internal SSL VPN device.

Update: Mandiant's blog post didn't identify the target, but a New York Times report published by after this post went live on Ars said it was a major corporation with "particularly sophisticated attack detection systems." Once connected to the VPN, the intruders tried to move laterally through the network and gain additional control over it. The researchers provided the following image taken from an intrusion detection system, showing the large responses the Heartbleed exploit was able to obtain.

The Mandiant blog post further underscores a point security experts have repeatedly stated in the past week and a half—OpenSSL is so deeply entrenched in Web, e-mail, networking, and end-user software and firmware that there's no telling how many different ways blackhats can exploit it against otherwise secure networks. Cleaning up after the mess is hard because the flawed code touches so many different products and technologies. Short of disconnecting vulnerable systems, there's little administrators can do except to wait for developers to push out fixes and then promptly install each one. And even then, operators still aren't safe until they have revoked virtually all existing encryption certificates and replaced them with new ones.

Depending on the network, it may take weeks or months to complete the Heartbleed recovery. In the meantime, Mandiant has the following recommendations:

Identify infrastructure affected by the vulnerability and upgrade it as soon as possible.

Implement network intrusion detection signatures to identify repeated attempts to leverage the vulnerability. In our experience, an attacker will likely send hundreds of attempts, because the vulnerability only exposes up to 64KB of data from a random section of memory.

Perform historical review of VPN logs to identify instances where the IP address of a session changed repeatedly between two IP addresses. It is common for an IP address to legitimately change during a session, but from our analysis it is fairly uncommon for the IP address to repeatedly change back and forth between IP addresses that are in different network blocks, geographic locations, from different service providers, or rapidly within a short time period.

I'm not sure why the seriousness of this isn't apparent to more people. It's obvious. I was talking to a client the other day and they said that they were 100% secure because they used 2-factor auth. I asked what he thought about his private info being in memory on a given web server. I received a glassy stare. Most people simply think heartbleed is some sort of "virus" (because after all, all bad computer things are viruses, right?).

I'm not sure why the seriousness of this isn't apparent to more people. It's obvious. I was talking to a client the other day and they said that they were 100% secure because they used 2-factor auth. I asked what he thought about his private info being in memory on a given web server. I received a glassy stare. Most people simply think heartbleed is some sort of "virus" (because after all, all bad computer things are viruses, right?).

I think it's the 64k part they don't get, as they're all used to thinking in gigs of memory now, and there's an awful lot of people that never had a computer with less than 1MB ram. They also massively underestimate just how quickly a computer could request this information (and by extension how many times they could do it a minute)

I think these 2 things are related as they are both relativlely small numbers. The problem is one of scale, as such their emotional brain goes - this reads 64 out of memory, and we have a 100 connection to the office, therefore it can do it twice a second, We've got loads of ram so this shouldn't be a problem. They forget that this is actually more than a factor of 1000 out.

Edit:My wife just pointed out that the other explaination may be that they can't wrap their minds around how such a small amount of information could possibly cause a problem forgetting that it's only small in comparison to the capacity of computers today.

Maybe if you compare it to the size of an ebook they may find it easier to understand.

I'm not sure why the seriousness of this isn't apparent to more people. It's obvious. I was talking to a client the other day and they said that they were 100% secure because they used 2-factor auth. I asked what he thought about his private info being in memory on a given web server. I received a glassy stare. Most people simply think heartbleed is some sort of "virus" (because after all, all bad computer things are viruses, right?).

Certainly we should never be complacent; however, using 2-factor-auth is much better than not using 2-factor auth. Even with heartbleed, that's two things (password and random seed for OTP) to steal from memory, both of which should be reasonably transient.

But it's not. As the article stated, the attacker stole the session identifier and used it to impersonate active sessions. This is called session hijacking. The attacker bypassed the VPN's multi-factor authentication by using the heartbleed vulnerability.