Ten Years Of Heartbleed: Lessons Learned

April 2024 marks the 10 year anniversary of the Heartbleed flaw and the ensuing scramble to patch the bug in the popular OpenSSL cryptographic software library. 

The bug is as noteworthy as it was notorious. It pushed security teams to understand the attack surface they were protecting, why an accurate inventory of IT assets mattered and the importance of being able to locate endpoints fast.

Heartbleed was discovered on April 1, 2014. A patch was released seven days later. The bug was present in some versions of the ubiquitous OpenSSL cryptographic software library, was given the CVE number 2014-0160 and a “high risk” CVSS score of 7.5.

Heartbleed’s impact: Immediate

According to the resource website Heartbleed.com, set up by Synopsys, a successful exploit of the vulnerability allows anyone on the internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. It would also allow for the compromise of secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content.

This would allow an attacker to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.

The impact of Heartbleed saw the Canadian government temporarily shut down online services of several government departments, although an attacker managed to steal around 900 Social Insurance Numbers by exploiting Heartbleed. Also, the Tor Project found some relay servers were still susceptible to the Heartbleed bug weeks after the patches were released.

Despite the undisputed destruction and massive heartburn to the wider business community, Heartbleed had a sliver of a silver lining that should not be forgotten. 

Give it some credit

Ten years on from its disclosure, does Heartbleed deserve more credit than it received for the impact it had upon cybersecurity? Yes, the Window for exposure was small, but its potential for exploit was huge. Let’s consider some of the points that cybersecurity has gained from April 2014:

According to Heartbleed.com, the bug was initially introduced to OpenSSL in December 2011, and was in the wild from 14th March 2012. However, its disclosure on April 1, 2014, showed how reliant we had become on the internet, says Neil Thacker, CISO of Netskope.

“There was so much reliance on the internet around that time, in 2014, when Heartbleed became a publicly known vulnerability, and 10 years previously there would have been less reliance on it for business and commerce,” he says. “I think this was a wakeup call to realize the internet was fragile, and we found out OpenSSL had one person working on it full time, to keep it secure and keep it updated.”

Thacker says Heartbleed also proved the need to put more focus on securing widely used systems, as even though other vulnerabilities have followed — such as Shellshock, Bash and Log4Shell — but he says there should have been a realization from Heartbleed that we should be doing more about this.

“There has been a huge increase in vulnerabilities in open source, and in proprietary software, but I think Heartbleed was one that probably scared people the most in that point in time.”

The discovery

The bug was officially discovered by two entities: Neel Mehta from Google Security, and by researchers from the Finnish cybersecurity company Codenomicon, now part of Synopsys.

Mark Van Elderen, who was with Codenomicon at the time of the acquisition, and now serves as director of strategic communications at Synopsys, says a lot of the popularity of Heartbleed comes down to the image of the bug, specifically with its logo, saying it became a household name for security experts:

He also makes the significant point that so many vulnerabilities require factors for exploitation: physical access, the victim to be running a specific software version, “but Heartbleed was exploitable by default and trivial to exploit, and required no extra piece to trigger the vulnerability.”

Asked if he felt that there were positive elements to Heartbleed’s discovery and legacy, Van Elderen says Heartbleed was a “wake up call for a lot of people”, and not just administrators and CISOs, but as open source software is everywhere “we need visibility into code in IT and software and asset inventory, and how to proactively manage risk in the organisation.” 

Who is on top?

Phil Odence, general manager of the Black Duck Audit Business at Synosys, says those businesses who were on top of their vulnerability and exploit management were able to deal with Heartbleed.

”The big problem is not the existence of vulnerabilities, as they get patched, but not patching them,” Odence says, pointing at Synopsys’ studies which found 10% of the applications tested included the Heartbleed vulnerability. By 2018 this had reduced to four percent of applications containing the vulnerability, “and 2019 was the first year that we didn’t see Heartbleed in any code bases.”

Odence claims that before the disclosure of Heartbleed, “companies were not that good at knowing what open source was being used” with Van Elderen saying that in the case of an open source bug, “the onus is on the consumer to fix it, and pretty much anyone running a web server can download a patch and new version of the component — but that is one of the challenges of open source risk, and if you don’t know if you’re running an open source component it is hard to fix what you don’t know exists.”

Are things better?

In conclusion, are we in an overall better position than we were 10 years ago if a similar vulnerability were to be found? Van Elderen says instances like Heartbleed, the Equifax breach and Log4Shell have raised awareness on open-source risk management, and the importance of updating and patching open source.

“We have become more reactive and responsive and that is not an easy challenge: if it was easy not talking about it, but major branded vulns like Heartbleed raise an important level of awareness for organisations, and see businesses get better at it,” he says. “It will never completely go away, but we are definitely getting better.”

Odence says there is more use of open source, but also a trend of companies tracking what they are using. He says in 2014, 30% of the typical code base was open source, but now that is closer to 75%, and made up of modern languages like JavaScript.

“The typical open-source code base we look at will have multiple, hundreds of code bases in it, and that is a lot more to track and manage, so big outbreaks are going to be easier to manage,” Odence says. “If you’re using 500 open source components and know 90% of what you’re using, you still have 50 components you don’t know about, and within there is going to be vulnerabilities.

(This article was originally published on SC Media’s sister site SC Media UK, a CyberRisk Alliance resource serving the UK and the greater European security community.)

READ MORE HERE