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!



Friday, March 21, 2014

Brian Krebs: The Movie!


This is so 'brill', I have to point it out for your fun and enjoyment:

Brian Krebs, of Krebs On Security, has reached such a level of fame for his coverage of the 'Black POS' malware Target et al. account robbery scandal that Sony Pictures Entertainment has taken notice:

Sony seeks to make a movie about the Target hack reporter
Krebs writes that he would be "delighted" to help pick the leading man.
by Casey Johnston - Mar 21 2014, 1:43pm EDT, @ArsTechnica
Sony Pictures has purchased the movie rights to the story of the reporter who brought the Target credit card hack to light. The Hollywood Reporter writes that the company bought the rights to the New York Times story "Reporting From the Web’s Underbelly," a profile of security reporter Brian Krebs.
Krebs broke the news of the hack back in December, when approximately 40 million [sic] credit card numbers were stolen, reportedly as a result of a malware-carrying phishing e-mail. The Times wrote about Krebs' coverage of the hack in February. . . .
Sony Pictures Plans Movie About Yours Truly
by Brian Krebs - March 21, 2014, @KrebsOnSecuity
Sony Pictures is reportedly planning to make a big screen movie based at least in part on my (mis)adventures over the past few years as an independent investigative reporter writing about cybercrime. Some gumshoe I am: This took me by complete surprise. . . .
Both articles are worth a read. Enjoy!

Click on Brian's picture below to learn more about him and his terrific work:

… Now, if only Sony would make a movie about their own music CD root kit malware scandal. That I'd love to see. It too affected millions of customers.


BTW Grumbling About ArsTechnica, Again (0_o)

ArsTechnica got the count of stolen Target accounts wrong. The most recent published number, direct from Target, is 110 million stolen accounts. NOT '40'. That includes the initial discovery of 40 million PLUS an additional 70 million EQUALS 110 million stolen Target accounts. I hope ArsTechnica correct their error.

The editorial verification of facts over at ArsTechnica is often dreadful and, dare I say, unprofessional. ArsTechnica already knows my opinion on the matter. Shame on you again ArsTechnica. You didn't do your homework. Lazy, lazy, lazy…


--> And no, I take no pleasure in outing ArsTechnica's failings. Instead, I wish ArsTechnica took pleasure in verifying their facts before publishing. If not for Dan Goodin's excellent reporting on computer security, I'd probably ignore the place. :-Q


Wednesday, March 19, 2014

The FAKE iOS "Tor Browser":
Delete Now


UPDATE! [2014-03-21 @~12:40 AM ET]: According to The Register, Apple has at last pulled the FAKE 'Tor Browser' from the App Store. Hurray. If you haven't deleted it from your iOS devices, please do so immediately.

Tor Project claims 'fake' Tor Browser sat in iOS App Store for months
Team Onion raises a stink over shady app which Apple ignored – until this afternoon
As of 1545 Pacific Time, the miscreant app is no longer available through a direct link and does not appear in search results. Earlier in the day, however, both direct links and search results brought up the Tor Browser application in question. 
As we have come to expect, Apple did not respond to a request for comment on the matter.
~ ~ ~ ~ ~ ~ ~

Original Article:

Dan Goodin @ArsTechnica today posted a revelational article about a FAKE "Tor Browser" that was snuck past Apple's App Store vetting system. If claims prove to be true, this is profoundly bad and discouraging.

Fake Tor browser for iOS laced with adware, spyware, members warn
Title available since November raises questions about App Store vetting process.
"Tor Browser in the Apple App Store is fake," a report ticket published two months ago on the Tor website by high-ranking volunteer Phobos stated. "It's full of adware and spyware. Two users have called to complain. We should have it removed."
The ticket went on to say that Tor officials notified Apple of the fake Tor Browser app app in December. In the intervening time, the app has remained available, touching off a series of exchanges among Tor members about how to respond. Ars was unable to confirm the claims of adware or spyware. Still, the incident highlights the lack of transparency in the way that Apple vets the reliability of security apps and responds to complaints of rogue titles.
. . . 
Early Wednesday [today], some two months later, yet another Tor member wrote: "I think naming and shaming is now in order. Apple has been putting users at risk for months now." 
. . . 
This article will be updated if Apple officials, who are routinely silent on such matters, respond to our request for comment. 
I'll be keeping track of the situation. Apple's stumbling and bumbling regarding security has been a real bummer this winter. Pestering Apple in public has proven to be the best method of getting them to shape up and get serious. Consider this my bit of naming and shaming.

Wake up Apple! Please.


Saturday, March 15, 2014

iOS 7 Random Number Generator
Not Random Enough


Seriously Apple? You have a device that is able to pull from a variety of sources of random data, and you didn't use that data in your random number generator? Why?

Researcher: iOS 7 security at risk from weak random number generator
Predictable and observable random number generator 
present in iOS 7
All mobile operating systems require what is called an "Early Random pseudorandom number generator (PRNG)" to give the operating system some security from kernel exploits. Researchers have revealed that the new one implemented in iOS 7 is vulnerable to brute force attacks, and can be relatively easy to predict, making security exploits somewhat easier to develop, if left unpatched.
. . .
While researching the matter, Mandt found that "we found that an unprivileged attacker, even when confined by the most restrictive sandbox, can recover arbitrary outputs from the generator and consequently bypass all the exploit mitigations that rely on the early random PRNG." 

Sources of actual random data on iOS devices:

- The compass
- The accelerometer
- The fingerprint of the user
- The white balance detected by the camera
- The number of files on the device
- The last phone number called
- The last website visited in Safari
- Audio noise detected by the microphone
- The current power level of the battery
- The proximity sensor
- The ambient light sensor
- The date and time

In other words: Get seriously random Apple!


Wednesday, March 5, 2014

Apple Falls Down Keeping XProtect Up-To-Date

UPDATE: Great news. Apple has caught up with the missing malware protection in XProtect. Check out Thomas Reed's follow-up article here:

Missing malware added to XProtect
Posted on March 14th, 2014 at 9:47 AM EDT

My conclusion: If pestering Apple in private does not succeed, pester Apple in public. Thank you to the folks at Apple who DO care. Thanks also to Thomas Reed for spearheading this issue and getting it done.


[Correction, recantation added 2014-03-06 2:00 am. Apple has indeed revoked all Trojanized developer security certificates. Thank you Apple.]

My Mac security colleague Thomas Reed has posted an important article today about some old and obvious holes in Apple's XProtect security system, built into OS X 10.6.8 through 10.9.x. Thomas is one of the most meticulous and patient people I know, terrific at software evaluation.

If you're a Mac professional, please read Thomas' article:

Time to re-evaluate safety of Mac OS X

What Thomas has discovered going on, or rather FAILing, with Apple's XProtect is alarming:

• XProtect is not protecting Mac users from a considerable number of malware currently in the wild, despite having been provided with samples of that malware.

That's a bad strike against Apple security.

Please note that neither Thomas nor I are into FUD and doom mongering. I'm exactly the opposite. But when Apple pulls a face plant on Mac security, it's time to get ticked off and active.

Folks here already know I consider Apple's web documentation team to be CRAP.

After reading Thomas' evaluation, I now I also consider Apple's security team to also be CRAP.

Please DO YOUR JOB keeping Macs secure.

Thomas ends his post wondering if it's time to suggest Mac users install anti-malware software. I use it, and occasionally find it useful. For example: It discovered a version of the CoinThief Trojan on one of my Macs. I had inadvertently downloaded it from MacUpdate before anyone knew what it was.

What I recommend:

Free anti-malware:
1) ClamXav - Donationware. OS X 10.6 - 10.9.
2) Sophos Anti-Virus 9 Home Edition - OS X 10.6 - 10.9.

Commercial anti-malware:
1) Intego VirusBarrier - Currently for $39.99 bundled with NetBarrier as 'Mac Internet Security 2013'. Yearly signature updates cost extra. Demo available.
2) Sophos Endpoint AntiVirus - Designed for Enterprise users. Versions available for OS X 10.4 - 10.9. Contact Sophos for pricing. Demo available.

Reverse firewalls:
1) Little Snitch - Currently $34.95.
2) Intego NetBarrier - Included with VirusBarrier in the 'Mac Internet Security 2013' package @$39.99.

I recommend all of the above because they are all great software. Also, their developers are terrific supporters of the Mac platform, to whom I am most grateful.

There are plenty of other reasonable solutions. Be sure to read both user and expert reviews before trying them, as there are abysmal solutions well worth avoiding. (Hint: Avoid MacKeeper and Symantec Norton AntiVirus, IMHO).

Note: I get paid nothing for recommending anything or anyone.