Heartbleed: SSL and your Web Security

If you are reading this post, chances are you are pretty much interested in the web as much as we do. And if you are not so savvy, an added knowledge will do you no harm.

This article actually deviate from the regular ICT advisory post, its more like an alarm and a core security advise.

I’d like to start with a few explanation and define some terms to make things easier. Now assuming you were to check your email; you simply enter www.gmail.com into your browser’s address bar and that is it, actually the ideal URL to input on your address bar should have been http://www.gmail.com. Not to worry, you have being doing the right thing, your browser has already been configured to recognised the short form of your URL and automatically prefix with the HTTP stuff. If you actually tried that, you will soon notice that instead of the http:// prefix, its https://. So what’s the ‘s’ its stand for secure. In lay man’s language whichever site you visit having the ‘s’ has taken extra caution in ensuring communication between the site and your browser is secure and exposed to online sniffers.

I’m sure you must have been warned about this on your bank’s internet page not to exclude a host of sites that have anything to do with private transactions. Basically this is how it works; there are a couple of web security companies who provide the service of securing traffic and activity on a website, all is needed if you are a web developer is to subscribe to the service.

An intro to OpenSSL:

OpenSSL is an open-source implementation of the SSL[Secure Sockets Layer] and TLS[Transport Layer Security] protocols. It is free even for commercial use and maintained by the OpenSSL project. A lot of security and web utility companies make use of OpenSSL for managing activities and traffic that are deemed secure.

The Real Digest:

A serious vulnerability which has been dubbed HeartBleed occured in the OpenSSL library. The bug was discovered by two Google security techies: See the info below from the OpenSSL blog

OpenSSL Security Advisory [07 Apr 2014]

========================================

TLS heartbeat read overrun (CVE-2014-0160)

==========================================

 A missing bounds check in the handling of the TLS heartbeat extension can be

used to reveal up to 64k of memory to a connected client or server.

 Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including

1.0.1f and 1.0.2-beta1.

 Thanks for Neel Mehta of Google Security for discovering this bug and to

Adam Langley <agl@chromium.org> and Bodo Moeller <bmoeller@acm.org> for

preparing the fix.

 Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately

upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS.

 1.0.2 will be fixed in 1.0.2-beta2.

How it works:

You read about secure data between your browser and the website, but what really happens when the data meant to be protected become an easy target and at risk. That is how the Heartbleed bug works. The bug allows remote attackers to steal the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. Allowing attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users in effect rendering the whole essence of encryption useless.

How widespread could it be:

The truth is most web servers run on softwares powered by Apache and Nginx. The combined market share of thes two on active internet sites is over 66%, mainly because they are open source. Also OpenSSL is used to protect for example email servers (SMTP, POP and IMAP protocols), chat servers (XMPP protocol), virtual private networks (SSL VPNs), network appliances and wide variety of client side software. Now you see how rampant the bug could be.

A couple of operating systems are also affected

• Debian Wheezy (stable), OpenSSL 1.0.1e-2+deb7u4
• Ubuntu 12.04.4 LTS, OpenSSL 1.0.1-4ubuntu5.11
• CentOS 6.5, OpenSSL 1.0.1e-15
• Fedora 18, OpenSSL 1.0.1e-4
• OpenBSD 5.3 (OpenSSL 1.0.1c 10 May 2012) and 5.4 (OpenSSL 1.0.1c 10 May 2012)
• FreeBSD 10.0 – OpenSSL 1.0.1e 11 Feb 2013
• NetBSD 5.0.2 (OpenSSL 1.0.1e)
• OpenSUSE 12.2 (OpenSSL 1.0.1c)

How can you be affected?

Your popular social site, your company’s site, commerce site, hobby site, site you install software from or even sites run by your government might be using vulnerable OpenSSL. Many of online services use TLS to both to identify themselves to you and to protect your privacy and transactions. You might have networked appliances with logins secured by this buggy implementation of the TLS. Furthermore you might have client side software on your computer that could expose the data from your computer if you connect to compromised services.

1. Change your login information on every website you use frequently
2. Check your card for fraudulent activities – this should be in the long term

 And for Web developers

If you don’t run a site that uses HTTPS (which lets your users connect securely using their web browser) then you don’t have to worry about this. If you do have HTTPS enabled on your site, even if you aren’t transmitting sensitive information, you need to respond to this threat immediately. Here is what you need to do about HeartBleed as a website owner:

If you use a hosting provider then you usually don’t control your site at the operating system level. So check with your webhost provider to find out if they were vulnerable and if the issue has been fixed.

If your hosting provider was vulnerable to HeartBleed then you need to ask them if they have revoked and reissued their SSL/TLS site certificates. The reason they need to do this is because the SSL/TLS private keys for your site may have been read from server memory and compromised.

If they haven’t fixed it then they need to fix it urgently because it has been 2 days since the public (and some are saying irresponsible) disclosure of HeartBleed.

All the same, you should take the following precautions on your website:

• Change all admin and database passwords.
• Revoke and change all security keys
• Advise your users to change their passwords and login information.

The reason for this is because your server memory was temporarily readable by any attacker and they may have read user passwords or other sensitive info from your memory. For example.

Hopefully, the web community has responded well to this threats and most soft wares have been updated to ward off further threats. If you have followed the steps outlined below, then you really do not have cause to be worried.

Please feel free to share your comments on any other online security threats. Do checkout the links below