The Heartbleed bug has already been heralded as one of the biggest security threats on the Internet. It exploits an encryption flaw in Open SSL – used by many hugely popular sites such as Gmail, Facebook etc.

What is the Heartbleed bug?

Heartbleed is a vulnerability discovered in a specific SSL implementation (OpenSSL) that allows an attacker to steal private data from the vulnerable server’s memory. It is not a vulnerability within the design of SSL.

Digital Rehab recommends that you change ALL your passwords immediately for these sites.

Your password information could have been exposed along with some of your sensitive account information.

Some Internet companies have rapidly moved to patch and fix their security while most have not yet.

Although changing your password regularly is always good practice, if a site or service hasn’t yet patched the problem, your information will still be vulnerable.

Also, if you reused the same password on multiple sites, and one of those sites was vulnerable, you’ll need to change the password everywhere. It’s not a good idea to use the same password across multiple sites, anyway.

To view an updated listing of what has been impacted by Heathbleed – please see Mashable’s table

LATEST UPDATE 17th APRIL 2014:

There has been a lot of press coverage over the last week about Heartbleed. As the vulnerable library, OpenSSL, is predominantly used in Linux and open source environments, there hasn’t been as much attention applied to those of us with Microsoft-centric investments.

Should you be running a Microsoft environment, here are some helpful tips:

• Microsoft software, like IIS, uses an SSL implementation called SChannel (“Secure Channel”), which does not exhibit the vulnerability. This does not mean that your organisation is unaffected though.
• The most common scenario to see OpenSSL in an otherwise Microsoft web stack is edge servers. That is, performing SSL termination at load balancers and cache servers. These are often deployed as hardware appliances, external site acceleration services, orcontent delivery networks. In many scenarios, I find that application teams are unaware of these extra infrastructure layers, and thus may erroneously declare their application as unaffected on an initial pass.
• Another scenario is embedded devices, and these are a usually harder to patch.
• Unfortunately, due to the nature of the potential attack, you will not find any record of an attack in your logs.
• If an affected version of OpenSSL is present anywhere in your data flow, you will need to at least patch and rotate SSL keys. You’ll also need to consider any secrets that have been present on the vulnerable node, such as user submitted data and passwords. This applies even if there are further layers of SSL behind the affected device (eg, terminate-and-forward scenarios that forward to SSL-based endpoints). Remember that if you are reusing a certificate across multiple services, such as a wildcard certificate, you will need to revoke and rotate all usages, not just the vulnerable nodes.