In the days and weeks following the public disclosure of the OpenSSL Heartbleed vulnerability in April, security researchers and others wondered aloud whether there were some organizations–perhaps the NSA–that had known about the bug for some time and had been using it for targeted attacks. A definitive answer to that question may never come, but traffic data collected by researchers on several large networks shows no exploit attempts in the months leading up to the public disclosure.
Researchers from the University of Michigan, the University of Illinois, the University of California at Berkeley , Purdue University and the International Computer Science Institute took a comprehensive look at the way that the Heartbleed vulnerability affected the Internet as a whole in the months since it was disclosed in April, focusing mainly on the response by organizations to patch vulnerable servers and revoke certificates. As the scope and effect of the Heartbleed vulnerability set in, security teams scrambled to determine which of their servers were vulnerable to the issue and whether they needed to begin revoking a bunch of SSL certificates, as well. Many of the top sites on the Internet were patched almost immediately after the disclosure, but that didn’t extend to the rest of the vulnerable server population.
“We began performing daily 1% scans of the IPv4 address space on April 9, 48 hours after the disclosure. Our first scan found that 11.4% of HTTPS hosts supported the Heartbeat Extension and 5.9% of all HTTPS hosts were vulnerable. Combining these proportions from random sampling with our daily scans of the HTTPS ecosystem (which do not include Heartbleed vulnerability testing), we estimate that 2.0 million HTTPS hosts were vulnerable two days after disclosure,” the researchers said in their paper, “The Matter of Heartbleed”.
Heartbleed is a vulnerability in the Heartbeat extension implementation in OpenSSL that could allow either the client or server participating in a connection to read a small portion of the other machine’s memory under certain circumstances. That memory could include confidential data, such as portions of a private key.
In addition to looking at initial vulnerability and patching rates, the authors–who include Vern Paxson, J. Alex Halderman, Nicholas Weaver and several others–also researched the attack landscape against Heartbleed before and after the public disclosure of the bug on April 7. Using traffic collected from passive taps at Lawrence Berkeley National Laboratory, the International Computer Science Institute and the National Energy Research Scientific Computing Center, and a honeypot set up on Amazon’s EC2 system, they looked at logs for the weeks and months leading up to the disclosure, along with data from the weeks immediately after the announcement. The researchers used a scanner configured to recognize SSL Heartbeat messages.
“LBNL’s network spans two /16s, one /20 and one /21. The insti- tute frequently retains extensive packet traces for forensic purposes, and for our purposes had full traces available from February–March 2012, February–March 2013, and January 23–April 30 2014. ICSI uses a /23 network, for which we had access to 30-days of full traces from April 2014. NERSC has a /16 network, for which we analyzed traces from February to April 2014. The EC2 honeypot provided full packet traces starting in November 2013,” the paper says.
“For all four networks, over these time periods our detector found no evidence of any exploit attempt up through April 7, 2014. This provides strong evidence that at least for those time periods, no attacker with prior knowledge of Heartbleed conducted widespread scanning looking for vulnerable servers. Such scanning however could have occurred during other time periods.”
That result also doesn’t rule out the possibility that an attacker or attackers may have been doing targeted reconnaissance on specific servers or networks. The researchers also conducted similar monitoring of the four networks, and noticed that the first attempted exploits occurred within 24 hours of the OpenSSL disclosure.
“The first activity we observed originated from a host at the University of Latvia on April 8, starting at 15:18 UTC (21 hours 29 minutes after public disclosure), targeting 13 hosts at LBNL. This first attack was unusual in that it sent both unencrypted (pre-handshake) and encrypted (post- handshake) Heartbleed exploit packets to each host, likely trying to gauge the effectiveness of both approaches. We observed scanning of the other two networks within a few more hours,” the researchers said.
“In total, we observed 5,948 attempts to exploit the vulnerability from 692 distinct hosts (Table 7). These connections targeted a total 217 hosts. 7 attackers successfully completed 103 exploit attempts against 12 distinct hosts (excluding the intentionally vulnerable honeypot). ”
The researchers also used their scanning operation as an opportunity to notify organizations that are running servers still vulnerable to Heartbleed. The vulnerability received a huge amount of attention, not just in the security community and technical press, but in broader Web circles, and yet the researchers found that plenty of network operators still had vulnerable machines several months after the initial disclosure.
“Even with global publicity and automatic update mechanisms, Heartbleed patching plateaued two weeks after disclosure with 2.4% of HTTPS hosts remaining vulnerable, suggesting that widespread awareness of the problem is not enough to ensure patching. However, as discussed in Section 7, when we notified network operators of the unpatched systems in their address space, the rate of patching increased by 47%. Many operators reported that they had intended to patch, but that they had missed the systems we detected,” they wrote.
