Heartbleed maliciously exploited to hack network with multifactor authentication

Demonstrating yet another way the catastrophic Heartbleed vulnerability threatens users, malicious hackers were able to exploit the bug to successfully bypass multifactor authentication and fraud detection on an organization's virtual private network (VPN), security researchers said.

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:

1. Identify infrastructure affected by the vulnerability and upgrade it as soon as possible.
2. 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.
3. 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.