In-brief: more than three years after it was first discovered, the Heartbleed vulnerability in OpenSSL continues to plague organizations worldwide. Why has it been so hard to fix? In this Industry Perspective, Patrick Carey of the firm Black Duck talks about some of the complicating factors that make vulnerabilities like Heartbleed so hard to eradicate.
In 2012, the Heartbleed bug was born of a programming mistake. A flaw in the open source OpenSSL cryptographic software library could be exploited to reveal not only the contents of a secured message, such as a credit-card transaction over HTTPS, but also the primary and secondary SSL keys themselves. The keys could, in theory, be used to bypass secure servers without leaving a trace that a site had been hacked. The bug was discovered, privately reported, and named “Heartbleed” two years later, on April Fool’s Day 2014, appropriately enough, and announced to the public on April 7th with a patch issued that same day.
Within 24 hours of its disclosure, hackers used Heartbleed to breach what the New York Times would refer to only as “a major corporation.” A week later, a 19-year-old used Heartbleed to steal taxpayer data from the Canada Revenue Agency, lifting over 900 social insurance numbers from the government site (he was arrested almost immediately).
Three years later, and nearly five years after the bug was first introduced, Heartbleed continues to vex technology dependent organizations. Why? Let’s review some of the factors that contribute to Heartbleed’s persistence.
The birth of Heartbleed could be thought of as much a people as programming problem. The chronically underfunded and understaffed OpenSSL team (currently composed of 15 members, two less than in 2014) ran into the converse of Linus’ Law, a lack of eyeballs to find problems in their code. And the people problem is helping Heartbleed to persist. Three years later, many servers and devices are still open to the Heartbleed vulnerability, although the patch has also been available for the past three years.
In early 2017, a survey by the search website Shodan found some 200,000 servers globally that were still vulnerable to Heartbleed. Running a similar search on Shodan for “vuln:cve-2014-0160” a few days ago, I found the number had dropped to around 144,000. That’s good progress, but still a daunting figure. The individual entities hosting the largest number of Heartbleed-vulnerable devices are service providers such as AWS, and many probably are innocuous instances set up on the fly by development teams that never bothered to shut them down. But I suspect many others are not. And again, the reason is a people problem.
Whether Open Source or Proprietary Code, You Need to Patch, Patch, Patch!
Whether open source or proprietary code, most known vulnerabilities like Heartbleed and Wannacry have patches available on the date of their public disclosure. Despite the availability of patches, an alarming number of both companies and individuals simply do not apply them. Months after Microsoft issued its security patch, thousands of computers remain vulnerable to the WannaCry exploit for a variety of reasons, ranging from the use of bootleg software to simple indolence.
Patches often aren’t applied because of people – a lack of IT time, money, and resources or concerns that the patch might break a currently-working system. Each time a patch is introduced, changing a system can impact its reliability and functionality. Healthcare organizations, for example, often will put functionality and uptime as a higher priority than security, and in doing so expose themselves to attack on unpatched — and vulnerable — applications.
Open Source and Push vs. Pull in Software Updates
In some cases, it’s a lack of insight — people or organizations are simply unaware of a critical vulnerability or its patch until they’re under attack. While software vendors like Microsoft can “push” updates and fixes out to users, open source has a “pull” support model unlike most proprietary software — users are responsible for keeping track of vulnerabilities as well as fixes and updates for the open source they use rather than having those fixes “pushed” out to them. Unless an organization is aware that a vulnerable open source component is included in its application(s), it’s highly probable that that component will remain unpatched.
Given that open source is at the core of commercial application development, it should be no surprise that almost all — 96 percent — of the 1,000+ applications scanned to compile Black Duck’s most recent Open Source Security and Risk Analysis (OSSRA) report contained open source components. What may be surprising is that 67 percent of the applications containing open source also had known vulnerabilities – making them prime targets for the next Heartbleed.
Best Practices for Managing Open Source (and Avoiding the Next Heartbleed)
As open source use continues to increase, effective management of open source security risk is becoming increasingly important. To make progress in defending against open source security threats like Heartbleed, businesses must adopt open source management practices:
- Establish and enforce open source use policies: Many organizations lack even basic documentation and enforcement of open source policies that would help them mitigate risks. Manual reviews are a minimum requirement, but as software development becomes more automated so too must management of open source policies.
- Create an inventory of the open source you use: You can’t defend against threats you don’t know exist. A full and accurate inventory ( aka bill of materials) of the open source used in your applications is essential.
- Map open source to know vulnerabilities: Sources such as the National Vulnerability Database provide information on publicly disclosed vulnerabilities in open source software. Organizations need to proactively and regularly check these sources to identify vulnerable open source components they have in use.
- Stay alert for new threats: With more than 3,600 new open source vulnerabilities discovered every year, the job of tracking and monitoring vulnerabilities does not end when applications leave development. Organizations need to continuously monitor for new threats as long as their applications remain in service.
Your organization needs to examine the software eco-system you’re using and include open source identification and management in your overall application security program. As well as examining custom source code for vulnerabilities, ensure that the open source you or your vendor companies use is not introducing hidden security vulnerabilities.