Attackers Exploit the Heartbleed OpenSSL Vulnerability to Circumvent Multi-factor Authentication on VPNs
Mandiant
Written by: Christopher Glyer, Chris DiGiamo
Less than a week since the public disclosure of the "Heartbleed" vulnerability, Mandiant incident responders have already identified successful attacks in the wild by targeted threat actors. The Heartbleed vulnerability (CVE-2014-0160), publicly disclosed on April 7th by security researchers Neel Mehta and Codenomicon is a buffer over-read bug in the Transport Layer Security (TLS) extension. The bug was present in a section of code responsible for providing "Heartbeat" notifications between a client and server. A working proof of concept of the exploit appeared on the Internet last week that allowed an attacker to obtain up to 64KB of random memory space per malformed heartbeat request.
To date, much of the discussion on the Internet has focused on an attacker using the vulnerability to steal private keys from a web server, and less on the potential for session hijacking (with Matthew Sullivan's blog a notable exception).
This post focuses on a Mandiant investigation where a targeted threat actor leveraged the Heartbleed vulnerability in a SSL VPN concentrator to remotely access our client's environment and steps to identify retroactively if this occurred to your organization.
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.
The following evidence proved the attacker had stolen legitimate user session tokens:
- A malicious IP address triggered thousands of IDS alerts for the Heartbleed vulnerability destined for the victim organization's SSL VPN.
- The VPN logs showed active VPN connections of multiple users rapidly changing back and forth, "flip flopping", between the malicious IP address and the user's original IP address. In several cases the "flip flopping" activity lasted for multiple hours.
- The timestamps associated with the IP address changes were often within one to two seconds of each other.
- The legitimate IP addresses accessing the VPN were geographically distant from malicious IP address and belonged to different service providers.
- The timestamps for the VPN log anomalies could be correlated with the IDS alerts associated with the Heartbleed bug.
Once connected to the VPN, the attacker attempted to move laterally and escalate his/her privileges within the victim organization.
Mandiant recommends organizations that are running (or had been running) vulnerable versions of remote access software or appliances take the following actions:
- 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.
