CIO

How to stay protected for Heartbleed and other OpenSSL flaws

Heartbleed wasn't just an interesting Internet security story. It was a sign that one of the most fundamental building blocks relied on by many large companies was significantly flawed. Even more staggering was the revelation that the OpenSSL open source code library, that is responsible for SSL communications between systems, had another flaw that went undetected for over a decade.

OpenSSL is an open source code library. It is used by applications that use SSL and TLS to encrypt communications between systems. In simple terms, when communications are encrypted an application refers to the OpenSSL library to ensure that the communications have been correctly encrypted.

Unfortunately, there was a flaw in OpenSSL's logic that made it possible for a malicious party to access data that users thought was secured. This included private keys, session cookies and passwords.

Heartbleed is listed in the Common Vulnerabilities and Exposures system as CVE-2014-0160. This is a widely used system for tracking information security issues.

There's no doubt that Heartbleed is a significant issue but it is worth noting a few things. Not all SSL and TLS traffic is at risk. The Heartbleed issue is not the result of a bug in the SSL and TLS protocols.

So, only systems using OpenSSL are affected. These account for about 17% of the entire Internet making Heartbleed the most widespread security bug identified.

That means servers and applications running software made by Microsoft were not vulnerable to Heartbleed as they use a different code library for securing SSL and TLS communications.

Similarly, applications using GnuTLS and Mozilla's Network Security Services, are unaffected. And although Heartbleed was identified at about the same time as the Apple "GoTo Fail" bug, that was an unrelated flaw in Apple's SSL/TLS validation code.

Another bug in OpenSSL called the CCS Injection Vulnerability, designated CVE-2014-0224 in the OpenSSL bug tracking system, was identified in June 2014. Like Heartbleed, it affects one in every six servers on the Internet and, potentially hundreds of millions of users as OpenSSL is used by some of the most popular sites on the Internet. Incredibly, this flaw was present in OpenSSL for about 15 years.

Page Break

The Anatomy of Heartbleed
To understand what risks the Heartbleed presents to your business it's important to understand what the problem really is.

Heartbleed is the name of a specific flaw that was found in the OpenSSL library of open source programs. This library of programs provides programs and systems with a way of using the SSL and TSL communications protocols. This distinction is important, as it's OpenSSL and not the protocols themselves that are flawed.

Many programs send a repeated signal to systems that they operate with so that the other system knows everything is working correctly. This is called a heartbeat. Think of it as being like the bing a cardiogram machine makes in a hospital telling everyone that the patient's heart is beating correctly.

Heartbleed is a memory-handling flaw in the OpenSSL software that allows up to 64kb of data to be intercepted with each heartbeat. In other words, there was a small data "bleed" with each heartbeat. Hence the name, Heartbleed.

By reading this piece of data, hackers could eavesdrop and capture information such as passwords, private encryption keys and other data that could then be used to compromise systems.

For example, if a malicious party exploited Heartbleed to capture an encryption key they could use to execute a man-in-the-middle attack to capture and decrypt data.

If a website used a cookie that was protected with SSL when used in communications between a user and a server, that cookie could be intercepted and the user's identity for that service could be hijacked.

For example, if a user was accessing a business system that used OpenSSL, a hacker could steal the cookie and then log-in to that system using the data in the cookie and carry out some malicious activity, pretending to be the exploited user.

What does all this mean? Any system that relied on OpenSSL to secure data transmission using SSL and TLS was vulnerable to attack. Once a malicious party had access to the data that leaked through Heartbleed, they could use it infiltrate systems and exfiltrate data.

How did Heartbleed happen? After all, it's an open source code library that is looked at by many people. Surely someone must have noticed that there was a problem?

There's a maxim in open-source development that says "given enough eyeballs, all bugs are shallow". In other words, when there are lots of programmers involved in a project, as is the case in open-source development, bugs are found and remedied quickly as the number of people looking at the code is so large.

According to security consultant Dan Klein one of the problems was a lack of discipline in the developer community. He recently said, “When you look at the Heartbleed bug, and you look at the SSL code, it’s incomprehensible, uncommented and untested. There are no unit tests. Why aren’t the tests there before the code is released?”


Featured Zone: Symantec : Architecting a Cyber Resillient Organisation

Download the Internet Security Threat Report 2014

Hear from Ajoy Ghosh(GM Security & Risk @ Transport for NSW) on "the State of Security Intelligence"

Read about the Top 10 Tips for Cyber Resillience


Page Break

The CCS Injection Vulnerability

The CCS Injection Vulnerability was discovered in June 2014. According to a security advisory issued by Zimbra "an attacker using a carefully crafted handshake can force the use of weak keying material in OpenSSL SSL/TLS clients and servers. This can be exploited by a Man-in-the-middle (MITM) attack where the attacker can decrypt and modify traffic from the attacked client and server".

The important thing to note about the CCS Injection Vulnerability is that is requires both the server and the client to be running versions of OpenSSL that have not been patched against the vulnerability. So, if either party involved in the SSL/TLS-encrypted data exchange has been patched against the vulnerability then the flaw cannot be exploited.

In that sense, while a significant issue, its impact is not likely to be a great as Heartbleed's.

How do you know if you're Vulnerable?

Any system that is using an unpatched version of OpenSSL is vulnerable to Heartbleed and the CCS Injection Vulnerability.

A fix for Heartbleed was issued on the same day that it was made public. The patched version is designated 1.0.1g.

One of the challenges that you're faced with when looking at Heartbleed and the CCS Injection Vulnerability is understanding where your points of weakness really are.

Internal Systems

If you have developed or deployed your own systems using OpenSSL then you need to patch them. Third party applications and some operating systems are also vulnerable.

For example, Red Hat Enterprise Linux was affected but patches were issued by Red Hat. Similarly, some versions of SUSE Linux were also affected and have been patched.

Cloud Services

As well as reviewing your internal systems, it's critical that you check all of your key service providers.

By now, most major SaaS providers have updated their systems. But carrying out thorough due diligence means checking more than just paperwork.

You should carry out your own testing of external providers.

There's a handy detection tool, created by Trend Micro, so you can test your service providers for Heartbleed vulnerability.

End Users

Although end user systems weren't the primary focus of Heartbleed that doesn't mean they weren't vulnerable. Systems running Windows aren’t affected as they don’t use OpenSSL. Apple's OS X was similarly unaffected but for different reasons. Although OS X, which is based on Unix, uses OpenSSL, it uses version 0.9.8 rather than the vulnerable 1.0.1.

Android devices running 4.1.1 carry the Heartbleed flaw unless they've been specifically patched. Lacoon Mobile security has produced a video showing what it looks like when Heartbleed is exploited on an affected Android device.

Page Break

Solutions

Solving the problems that Heartbleed and the CCS Injection Vulnerability have created requires a multi-faceted approach. It's not enough to just load an updated version and expect the patched OpenSSL code to protect you.

The reality is OpenSSL is a piece of computer code. And humans who can make mistakes create all computer code. That means part of the solution to the flaws in OpenSSL comes back to basics.

Code Reviews and Audits

OpenSSL is a just one example of an open source software library that is broadly used for important functions. The reason Heartbleed and the CCS Injection Vulnerability had such a massive impact is that the code wasn't checked thoroughly. It was edited by many different parties over a period of time, poorly commented and not adequately tested.

Companies that rely open source code need to conduct their own thorough reviews and testing. Heartbleed has shown that it is no longer acceptable to believe that the crowd will do this for you.

Many eyes did not find the flaws in OpenSSL. Finding bugs requires eyes that are looking for the vulnerabilities specifically. Duirng his presidency in the 1980s Ronald Reagan was famous for his adoption of the Russian proverb "Trust, but verify". It's advice that we should heed when it comes to open source software.

One potential solution businesses could consider is the use of bug bounties. Employ a team of hackers to find the flaws in your systems and pay them for what they find.

Move your development teams around so that they are not always working on the same applications. And consider rotating them through testing as well so that they learn how to find bugs and vulnerabilities. But getting them to think differently they will approach problem solving in new ways when they develop new code.

Periodically engage external auditors to review parts of your internally developed and externally sourced code. It might be prohibitive for them to review everything but getting them to look at something new every few months can be a good way to keep developers focused.

Using Red/Blue Teams  to probe and respond is also a good tactic. Again, this gets developers to think like hackers so that they develop code with security in mind from the outset and not as an afterthought.

Developer education

Organisations spend a lot of money on ensuring developers are up to speed with the latest programming techniques and that they have access to the best tools to do their job. It makes sense to divert some money into security training for developers.

By developing code that is secure from the outset, companies can avoid the cost of retrofitting security later. But this requires a change in how a lot of code is created. And that will require developers to develop with a different mindset where meeting security needs is just as important as meeting functional requirements.

Abstract security out of applications

This sounds counterintuitive after saying developers need to embed security more deeply into their development process. However, what we're are suggesting is that code that is known, tested and verified to be secure can be used by multiple applications.

For example, a common identity and access management platform can be used by all applications to ensure that the right users have access to the right data and processing options. If a problem is found in the security and access management software then it can be fixed once rather than having to fix every application.

Better testing

Flaws such as Heartbleed and the CCS Injection Vulnerability could have been detected much earlier had testing processes kept up with usage patterns.

The Internet was created during a time when hardware was far less reliable than it is today. It had to be able to survive the loss of large physical elements of the network. Today, the threats are different. The Internet needs to survive targeted attacks.

That means testing needs to have an increased focus on thwarting targeted attacks and not just ensuring business functionality is supported.

Page Break

Alternatives to OpenSSL

If the recent flaws that have been detected in OpenSSL have left you feeling a little bruised then perhaps you're open to considering some alternatives. However, it's important to note that while a shift away from OpenSSL may be warranted in your organisation, it doesn't abrogate your need to test and verify.

As the Heartbleed and CCS Injection Vulnerability flaws were not in the TLS and SSL protocols but in how OpenSSL implemented them, it's possible to consider alternatives for using these protocols. One is GnuTLS. It's also open-source, like OpenSSL, but implements the SSL and TLS protocols differently. There's an API for applications to hook into so it could be a viable alternative, albeit one that will require significant software engineering to implement in some cases, for companies considering a shift away from OpenSSL.

Another is Network Security Services (NSS) that is released under the Mozilla Public License. A number of popular open source and commercial applications use NSS such as Chrome, Open Office, Apache and Java.

Then there's the Microsoft stack of server and communications products. These provide another alternative as they use Microsoft's own implementation of the TLS and SSL protocols. One advantage of this solution is that Microsoft has an established process for releasing fixes and patches on Patch Tuesday each month. However, this might require a platform shift that could be prohibitively expensive and complex.

The Final Word

Heartbleed was an important milestone in information security. Although it caused massive disruption as companies scrambled to patch vulnerable systems and forced users to change passwords it can be viewed as opportunity to take stock and learn.

The reality is that many of the building blocks of our systems that rely on need to be reconsidered. OpenSSL was used by millions of people for many years. It will remain a significant part of many organisations' systems or many years. But we can no longer expect that it will be secure.

Any open source code that is being used in companies needs to be reviewed with a hacker's point of view, looking for potential security issues rather than whether the software satisfies functional requirements.

The entire development and testing process needs to be overhauled so that security is in the foundation and not an afterthought.

And, if necessary, it might be time for businesses to remove OpenSSL from their environments and deploy an alternative, while maintaining a "trust, but verify" posture.

This article is brought to you by Enex TestLab, content directors for CSO Australia.


Featured Event: ISACA Strategic Planning Event | 1st July | Sydney Rooms- darling Park | Register Today

CSO Perspectives Roadshow 2014 | Melbourne 2nd September | Canberra 9th September | Sydney 18th September | Over 33 Speakers , International Speakers, Workshops, & Giveaways Register today