Monday, April 28, 2014

Adobe Flash Player v13.0.0.206:
Critical Out Of Band Update,
Exploit In-The-Wild


Today Adobe released a critical, out of band update of Adobe Flash Player. The new version is There is an exploit of previous versions of Flash in-the-wild. Update immediately please.

Adobe's security bulletin can be found here:
These updates address vulnerabilities that could potentially allow an attacker to take control of the affected system.
Adobe is aware of reports that an exploit for CVE-2014-0515 exists in the wild, and is being used to target Flash Player users on the Windows platform. Adobe recommends users update their product installations to the latest versions. . . .
These updates resolve a buffer overflow vulnerability that could result in arbitrary code execution (CVE-2014-0515).
At this point, the exploit is only on Windows OS computers. But it can easily be exploited on other platforms as well.

[Cross fingers that Adobe managed to compile this version correctly for ALL supported versions of OS X. (0_o)]


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.



Wednesday, April 9, 2014

The 'Heartbleed Bug' OpenSSL Security Hole:
A User's Best Practice Response


It's two days after knowledge of the OpenSSL 'Heartbleed' security hole hit the streets. Every blog remotely interested in computer security is posting about it. It may be the biggest FUBAR blunder in recent computer history. But it may amount to much-ado-about-nothing. I suspect it will result in scattershot severe damage to a moderate number of Internet users.

Because of my manifesto for this blog, I'm not going to go into the guts of the problem. If you're interested in exactly what's going on, I suggest you read Dan Goodin's articles about the Heartbleed bug and watch Steve Gibson's 'Security Now!' podcast number 450, 'How the Heartbleeds'.

Critical crypto bug in OpenSSL opens two-thirds of the Web to eavesdropping
Exploits allow attackers to obtain private keys used to decrypt sensitive data.

Critical crypto bug exposes Yahoo Mail, other passwords Russian roulette-style
OpenSSL defect still exposing sensitive data even after patch is released.

GRC Security Now! Episode Archive

Before I get to the best response to this mess, let me list a few useful points about the situation:
  • The security hole is two years old.
  • It affects HTTPS encrypted connections to Internet servers.
  • The problem is at the server side, NOT the client side. There's nothing Internet users can do about it. Server administrators are responsible for patching.
  • Only one branched version of OpenSLL is affected.
  • Sadly that branch of OpenSLL is predicted to be used on ~60% of Internet servers.
  • It exposes a chunk of memory space that may or may not hold important data.
  • All the worries are about hackers stealing potentially important data from that exposed memory space.
  • That important data could include security certificates, user IDs and passwords.
  • There is no clear evidence that the security hole was maliciously created. It appears to merely be a coding blunder.
  • Yes, there may be justified paranoia about the code blunder being deliberate, as with Apple's recent 'GoTo Fail' SSL security hole.
  • Few of us will ever never know if the code blunder was deliberate. Therefore, don't let the FUD get you down. Return to balance and forge ahead.


--> Change all your Internet website passwords.

BUT: Wait until each individual website has verified they've patched their version of OpenSSL.

In other words, there is no point in changing your password at a website that has not patched this security hole. Zero! Nada! It might still be exposed to hackers, so what's the point.

This solution is incredibly frustrating. I entirely sympathize. I'm NOT looking forward to this process. I loathe and resent this situation. Who wouldn't? But this is the solution for Internet users.

Responsible websites will notify you via email or their home page to let you know when they've patched the security hole. Or, they'll notify you to let you know if there server is not affected. One or the other. Stay away from irresponsible websites that don't directly address this situation.

The PHISHING Effect: This situation will be exploited by phishing rats. You will receive faked emails claiming to be from websites you use. They will offer links where you can change your passwords in response to this bug. Those links will be fraudulent and lead you to fake versions of websites. Those fake websites will ask you for your ID, password, credit card numbers, ad nauseam. This will be a nightmare.

PLEASE read my recent article about Phishing. It will teach you one quick and easy method of identifying phishing scams:

An article by my colleague Topher Kessler will provide you with further information about phishing:

~ ~ ~ ~ ~

Q: Do we REALLY have to change all our passwords?

A: YES, except when a website verifiably notifies you that they did NOT have the Heartbleed bug. Otherwise, expect they have it or had it. Contact them and ask what's their situation.
~ ~ ~ ~ ~

Q: Do we REALLY have to wait until a website notifies us to change our password?

A: YES. If you haven't heard from a website regarding the Heartbleed bug, contact them and ask them what's their situation.
~ ~ ~ ~ ~

Q: What about websites where I don't use HTTPS?

A: SHAME on any website that doesn't use HTTPS! Contact the website and ask them why they don't protect their users with encryption. In this day and age, there is no excuse for not using HTTPS. None. Zero! Not kidding. I could rant for ages about irresponsible websites. 
~ ~ ~ ~ ~

Q: But doesn't the Heartbleed bug mean SSL/TLS/HTTPS isn't perfect and still might leak my private data?

A: Sadly, yes. But that's because we're still in what I call 'The Stone Age Of Computing.' Decades from now they'll look back on us with pity. Poor we who put up with user abuse and coding insecurity. We are 'the bleeding edge'. It hurts.

Meanwhile: SSL/TSL/HTTPS is the best we've got for now. Even with this nasty little Heartbleed bug, it's profoundly better than no encryption at all.

The Future Is End To End Encryption. 
Everywhere on the Internet. 
At all Times. 
Guaranteeing our universal right to privacy.

It's just taking us a painfully long time getting there. And yes, our own governments' undermining of that process is deliberately hurting its progress. But We The People forge onward, despite the crooks, kooks and treasonous criminals who abuse us. It is ever so with humanity. That's not going to change.

Brave faces!
Brave hearts!
Brave spirits!
We persist ever forward into positive change and sanity.



Wednesday, April 2, 2014

Phishing For Suckers of the Mac User Variety


Over the past couple weeks, there has been an all out effort to phish-for-suckers, especially Mac user suckers. I received one of these phishing emails myself!

Here is what it looks like:
From: Customer Support <>
Subject: Update Your Account
Date: March 31, 2014 6:30:20 AM EDT
To: blah@blah.blah
Reply-To: Customer Support <>
Dear Customer, 
We have recently updated our website database and new security feature has been added for effective order and shipping. Please Click, to update your account information within 24hours.  
Apple Team
I have altered the source email address ;-) and removed the hidden URL linked to ''.

How To Detect Phishing URLs

Using Apple Mail, the quick and easy way to check if the link in a suspect email his bogus is to hover your Mac's cursor over the URL found in the email. The result is that the ACTUAL URL appears on screen. Then you can see if they match. If they don't, you know you're being Phished. Here I have applied this method to the Phishing example above. Click on the image to enlarge it for viewing:

Here you can see the cursor hovering above (not clicking on!) the link in the phishing message. The yellow box appears below your cursor, containing the ACTUAL URL hidden beneath the FAKE URL. In this case I can see that the fake link does NOT go to Apple at all. Instead it goes to some unknown server in another country (.nl refers to the Netherlands). I've grayed out most of the actual link for your protection.

When you discover a secret URL deviating from and hidden behind a fake URL label, you know you're being phished. Needless to say, DO NOT click the phishing link!

How Are Secret URLs Hidden Behind Fake URLs?

Here is the HTML command being used by the phishing rats:

"<A HREF="URL" TARGET="_blank">TextOfLink</A>"

Ignoring the coding details, there are two important parts of this command:

1) The actual URL. I have placed the word URL above where the actual URL is placed into the command. For Apple, that could be "", placed within the quotes.

2) The Text Label For The URL. I have placed the phrase TextOfLink above where the text label is placed into the command. For Apple, that could simply be 'Apple' without quotes.

Where this command becomes dangerous is through the use of a URL as your text label. This is allowed! It's clearly a fault of HTML coding. For example, instead of using 'Apple' as the text label I could use anything I like, such as ''. In this example, someone would think they are going to '' but they're actually being sent to

Here are a couple code examples:

'You can visit Apple by going to!'

'You can verify your Facebook password by going to!'

The 'Real' link really goes to Apple. But the Phishing link does NOT go to Facebook! In this example, it also goes to Apple. But I could make it go ANYWHERE on the Internet I liked, while still fooling you that it goes to Facebook.

When you arrive at a phishing website, it has been setup to 'appear' to be real. This can be done by stealing all the graphics and design of the original website, such as Facebook, then uploading it to the faked phishing website. It looks like Facebook! But it's NOT Facebook. Having suckered you there, the phishing rats can then ask you to 'LOG IN' to your account. You log in, you believe. But they have just stolen your ID and password. You've been successfully phished.

Phishing websites can ask you ANYTHING. What's your birthday? What's your credit card number? What's your card's secret code? What's your maiden name? Where do you live? Etc. If you hand them the data, they abuse you. Typically, people's identities are sold to other rats who want to steal from you or pretend to be you for nefarious purposes. That's bad.

Further Details About Mac User Phishing

Topher Kessler, formerly of MacFixIt (which CNET has discontinued) has set up a new website for helping Mac users: He has an excellent article covering further details of the ongoing phishing of Mac users:

New phishing attempt mimics Apple support

You'll find that Topher uses the same example I provided above, which is helpful for understanding what's going on. He has also provided further illustrations. Thank you Topher!