Heartbleed Security Flaw – The Good, Bad and Ugly

It has been a week since the Heartbleed issues have caused a security nightmare across the Internet. The flaw named “Heartbleed” which affects OpenSSL, one of the most widely used open source software programs used to encrypt internet communications, allows hackers to steal credentials and mimic the secure communication between a browser and web server. The worse case scenario has been confirmed – that the SSL private keys to webservers can be compromised. The proper terminology of the security vulnerability is the “Man in the Middle” (MITM) attack and spoofing the website. Cloudflare, a content delivery network and distributed domain name server service, held a challenge (link) to steal the keys to their NGINX web server and two security specialists proved that it could be done.

Most organizations have gone through patching their web servers with the OpenSSL fixes and users have updated their passwords. The big question is: how does a major security flaw affect two thirds of the Internet using secure web browsing (HTTPS) with this vulnerability for a time period of 2 years without being detected? Since Heartbleed intrusions are hard to confirm, it is nearly impossible to find out whether you have actually been compromised during this period.

It seems like the short-term security response is to put “Band-Aids” on the Heartbleed. Organizations expect end-users to change passwords multiple times as they patch up the OpenSSL Heartbleed. However, the Internet is still left with the same problem of complex, weak, penetrable, common and ‘hackable’ passwords commonly used to access critical information. Will the next big security breach be in mobile?

Everyone knows that we are being inundated with usernames and passwords. Perhaps, this Heartbleed crisis provides fuel that accelerates a seriously needed overhaul of Internet security. Cyber-security will become more than Hollywood and TV shows and hopefully organizations will prioritize mobile, cloud and Internet security.

There are a few questions that come to mind in relation to the stability of our Internet Infrastructure:

  1. How vulnerable (or breakable) do Passwords continue to be?
  2. Are we asking users to update all passwords time and time again?
  3. Is the use of Username / Passwords outdated?
  4. How does the end-user know when all the sites have been patched and updated for security, prior to updating Passwords?
  5. What is the impact on the web, who has been compromised in last 2 years and what is the measurable damage?

There have been rumors that government agencies are involved with this security breach and that the flaw was deliberate or ignored for advantage. We don’t believe this is the case, but nonetheless, the issue has been explained as an “oversight” by the software developer who committed the code on December 2011 to the OpenSSL project. The heart beat (SSL/TLS) feature was meant as a performance enhancement introduced in version 1.0.1, which opened a ‘back door’ to the server’s memory.

The reality is that so much of the Internet security infrastructure is dependent on this particular cryptographic software, which is seriously under-funded as an Open Source project. There is a team of 5 people managing this code base and only one of them is full time. We are fortunate to have great security software developers donate their time to the project, however, maybe it is time for the Internet to contribute back to the OpenSSL project.

 

Questions:

The question of why Open Source software is supposed to be safer and how this issue persisted for 2 years without anyone knowing?
OpenSSL was created back in the 1990’s to build a common set of cryptographic libraries to allow software on the Internet to benefit from the security. It was difficult for many companies to build their own cryptographic libraries. The theory of having software reviewed by the entire open source community provides more scrutiny and eyeballs on the source code.

The reality is that numerous commercial products use OpenSSL but none of the funding goes back into OpenSSL. A generous few security developers that are able to donate their time to the project maintain the code base. Money doesn’t make for better code but does offer funding for security audits, face-to-face meetings, and free up the developers on OpenSSL to commit full time to the project.

In comparison, TrueCrypt, an open source application for on-the-fly encryption, recently raised $60,000 for a security audit of their encryption software.

Who has been impacted by this security flaw?
The security flaw affects all web servers using the OpenSSL cryptographic libraries. Since the majority of the Internet runs on Apache and NGINX, 66% of the web is susceptible to this problem. Secure web security is used by e-commerce sites, online banking, email, government agencies, and many more.

Google has responded that one version of its Android 4.1.1 is affected by the Heartbeat bug. This translates to millions of older devices running the software that takes time to update. However, the security vulnerability is not as large here as a web server’s since mobile device attacks are one to one.

Cisco and Juniper have confirmed that the Heartbleed flaw affects two dozens networking products. Both of these companies build servers, routers, and switches that provide the ‘plumbing’ for enterprises and the Internet.

What exactly is the impact of this security flaw?
With the security flaw in the protocol implementation of OpenSSL for SSL/TLS, the frightening aspect is that the server audits & logs do not capture the attack. The inherent nature of the flaw in the heart beat response of TLS is not verifying the length of the message, which causes the web server to send data (64KB) stored in the memory. This vulnerability is known as the “backdoor” into the server’s memory.

 

For a comprehensive Infographic of sites that are affected by Heartbleed and where one need to change passwords, see: http://venturebeat.files.wordpress.com/2014/04/lwg_heartbleed.jpg

Leave a Reply

Your email address will not be published. Required fields are marked *