Wednesday, April 16, 2014

Heartbleed Bug Week Two:
Affected Website Testing and
'The Other Shoe'


[UPDATED 2014-04-18 ~11:30 AM ET. AgileBits has created a lovely Heartbleed testing page I recommend. It offers advice as well as results. Thanks to my friendly colleague Al Varnell for pointing it out!]

[UPDATED 2014-04-17 ~11:00 AM ET. A link to Mashable's list of affected websites was added.]

This is week two of the Heartbleed bug and its ramifications. A lot has been learned. A lot is still happening. A lot more problems are still to come.

I'm extremely disappointed that few websites have directly addressed this problem and kept their customers informed. Apparently, security is still considered a minor inconvenience to website administrators, with a wide variety of responses to the Heartbleed security hole, as you'll see ahead.


Thankfully, there are now some very good resources for finding out whether specific websites remain affected. Here is a list of six pages I know of where you can test any website against the Heartbleed bug. Try them in the order of usefulness I've provided below. If one test errors out, try the next one.

Thanks to Brian Krebs for getting the ball rolling collecting these sites. I'll add more to this list as I find them. Note that using these test pages can be annoying and disconcerting. On some test pages, I ran into errors of various sorts about 50% of the time.


Fortunately, lists of FAILed websites are showing up on the net, saving us some time and trouble. Here is one at Github, listing affected websites as of April 8th, 2014, the day after the SSL security hole was made public. Scroll down its page to 'Overview' to see the list:

NOTE: Many of the sites on this out-of-date list have now been patched! Yahoo, for example, made a big deal out of patching its website in a hurry.

Mashable has also provided a listing of affected websites here. Note that it is also out-of-date:

At the time I wrote this article, many sites had still not been patched. Here's one unhappy example:

Click to enlarge the image for viewing

This bank kindly patched their German website, but NOT their Turkish website! Ouch!

And so forth.


So! Are we ready to change our passwords at all the websites that verify as having patched their OpenSSL implementations?

Yes! Do it!

But! There's another problem! Remember how I pointed out last week that phishing is going to result from the Heartbleed bug? The phishing problem may become doubly bad:


Because, as I pointed out last week, Heartbleed can allow the cleartext robbery of website security certificates, ALL security certificates at affected sites MUST BE REVOKED and REPLACED.

Why? Because with a stolen SSL security certificate, a hacker can pretend to 'officially' BE the website from which the certificate was stolen! That's VERY bad and will lead to lots of troubles. It's also ignorant, lazy and cheapskate of the website's administrators.

It turns out that remarkably few websites have so far revoked their potentially stolen security certificates! Welcome to our modern world of bad biznizz. :-P Insert your favorite expletives here: [_____]

Let's use an example!


Use a GOOD web browser that actually CHECKS Internet security certificates for credibility. One such browser is good old Apple Safari! Bravo Apple! Each time you visit a website, Safari checks the security certificate for that website against a number of factors. One of them is whether that certificate is on a Certificate Revocation List (CRL).

When you visit a website that has had its security certificate revoked, you get a message in Safari!

This past week, mentor Steve Gibson very kindly set up the perfect place to show what it looks like when you run into a revoked security certificate. Travel here to see Steve's demonstration:

In a box, slightly down the page, you'll see his test page link. Click on it:

What you'll see in Safari is:

Click to enlarge the image for viewing


If you then click on the 'Show Certificate' button, you will see this:

Click to enlarge the image for viewing


Therefore, you hit the 'Cancel' button and leave the site. There's something profoundly wrong with it, danger, danger. Do not go there. Thank you Safari!


Let's say we live in Turkey and get an email we believe is from the Istanbul branch of  HypoVereinsbank, where we have all our life savings stored. The email message says something like:

Dear Valued Customer, 

We are offering a new 5% back on purchases feature to select account holders. To sign up for this new perk, please log into your account and click the 'Join the 5% Back Club' button on the  page.

Hurry now! Limited time offer! Don't let this deal pass you by! Prices do not include shipping and handling.
Great! A deal! They offered up the link to their website within the message! How convenient.

[If you check out the actual web address behind 'HypoVereinsbank account', you'll find that I've faked a different IP address that is NOT HypoVereinsbank! In reality, I've provided a LAN IP link that goes nowhere on the Internet, making in innocuous. But I could put anything there. Note that I am NOT picking on HypoVereinsbank in Turkey. I'm only using them as a valid example of a bank that had not patched the Heartbleed bug at the time of this writing.]

So we click the link to We're sent to the FAKE website for the bank. We're presented with everything looking just perfect and fine. Safari sees NO problems! The stolen, unrevoked certificate is presented to Safari, all his happy.


Then we log in, our ID and password are stolen, we possibly get asked a bunch of other personal identity questions in order to sign up for the FAKE 5% Back Club offer. We have been PWNed.


It's important that ALL Heartbleed bug affected websites revoke their old security certificates and get new certificates. ALL.

Enough of that nightmare for today.

CONCLUSION, for now:

1) Check out what websites have been affected by the Heartbleed bug.

2) Check out whether those websites are NOW patched.

3) Change your password there ASAP.

4) Keep an eye out for potential phishing scams using stolen security certificates.


Hopefully we'll see forced revocation of security certificates via certificate authorities against all websites that have been affected by the Heartbleed bug. That move would save we Internet users a lot of grief.




  1. In Google Chrome, there is a way to enable CRL checking: go chrome://settings/, scroll and click "Show Advanced Settings", then check the box labeled "Check for server certificate revocation."

  2. Or you can activate checking in all browsers, etc. using KeyChain Access