STE WILLIAMS

Anatomy of a certificate problem

An adware program called SuperFish hogged the cryptography news lately.

Lenovo tried a bit of an experiment by pre-installing this adware on some of its consumer notebooks.

The company was apparently under the impression that its customers would be pleased to have a free utility that brought them better-quality ads by peeking inside their secure transactions.

As it happened, many of its customers might never have even noticed SuperFish, were it not for the negative publicity that followed the revelation that the software had got its cryptography wrong.

SuperFish blessed itself with the right to give its own security “seal of approval” to your usual HTTPS sites, such as internet banking and webmail.

Unfortunately, it also allowed any and all cybercrooks to self-certify their own dodgy websites and malware downloads in a way that SuperFish would give them a seal of approval, too.

As a cynic might say, “What could possibly go right?”

Fortunately, because SuperFish wasn’t deliberately malicious, it didn’t try to hide itself or to prevent removal, so you could remove it easily with its own uninstaller.

And for those who preferred to get rid of it by hand, Naked Security and numerous other sites gave instructions on what to do.

Of course, it’s not only adware that is increasingly stymied by the use of HTTPS, where web traffic is encrypted all the way from your browser to the server at the other end.

Security software, if it watches out for malware in the web pages you visit, faces a similar challenge: how to spot pages that belong to crooks if they are wrapped inside HTTPS?

MiTM explained

The answer, for better or for worse, is a trick called keybridging, also known as decrypt-recrypt, or, more commonly, as Man in The Middle (MiTM).

When your browser connects to, say, https://example.com/, the security software intercepts the connection and “answers” it, either right there on your own computer, or in some gateway server between you and the internet.

The security filter then connects onwards to https://example.com/ and grabs the content on your behalf (that’s why this sort of software is called a “proxy”), using an HTTPS connection of its own.

That means the HTTPS replies from example.com actually terminate inside the security software, too, so your traffic is unencrypted, both outbound and inbound, with the result that the software can look inside it.

Strictly speaking, that violates the end-to-end encryption “promise” of HTTPS, and it also plays havoc with the HTTPS security certificate presented by example.com, which never reaches your browser.

To trick your browser into thinking it really did connect to example.com, the security software generates, in real time, a fake certificate pretending that it is example.com.

And to trick your browser into trusting that fake certificate, the security software adds itself to Windows as what’s known as a Trusted Root Certification Authority (see images below).

That means it can not only mint fake certificates, but sign them and therefore verify them at the same time.

Clearly, that means you have to trust man-in-the-middle security software a lot – it’s a bit like letting your accountants be their own auditors and sign off their own work.

The SuperFish problem

SuperFish’s problem was that it failed to protect the cryptographic material that it used on-the-fly to mint its fake certificates.

In other words, a crook on the other side of the world could sign his own web page or malware program with the same signing key that SuperFish was using on your computer.

And when your browser saw the crook’s digital certificate, it would say, “Hey, that certificate was signed by SuperFish, and I trust SuperFish, therefore I trust the crook!”

The PrivDog issue

It turned out that SuperFish wasn’t the only recent adware-related consumer product to implement MiTM and get things wrong.

At about the same time, towards the end of 2014, internet security company Comodo also tried a bit of an experiment by adding a MiTM-type component called PrivDog into its endpoint security product.

Comodo proudly promotes itself as “now the largest Trust Provider in the world.”

Its primary business is signing HTTPS certificates for you, after doing sufficiently diligent research to verify that you are who you claim.

In short, Comodo’s Certificate Authority (CA) division vouches for your certificate, and therefore vouches explicitly for your identity and implicitly for your trustworthiness.

It is this diligence by a CA that prevents crooks from making a certificate in the name of, say, big-bank.example and then getting it signed and verified as if it were the real thing.

PrivDog-in-The-Middle

But Comodo’s PrivDog wasn’t so careful with the certificates it generated on-the-fly for doing its MiTM.

Here’s what we saw:

So far, so good, albeit only up to a point.

As you can see above, Sophos deliberately paid a bit extra for a “green-aura” HTTPS certificate for Naked Security.

Called EVs, or Extended Validation Certificates, they are meant to give a visitor a bit more reassurance about the the website owner.

That’s because the CA is supposed to (and, in this case, did!) put additional work into checking up on the owner’s identity and right to operate the web server involved.

PrivDog’s minted-on-the-fly replacement certificate doesn’t meet EV criteria, so the product effectively downgrades Naked Security’s rating, supposedly in the name of improving security.

PrivDog’s “privacy upgrades”

It gets worse, because PrivDog sometimes created replacement certificates that effectively upgraded a website’s security rating, by inadvertently generating a trusted certificate as a placeholder for a dud one.

We tested this by visiting a website run by Hanno Böck, a German journalist who was one of the early investigators of PrivDog’s security problems.

He has a URL that uses a certificate signed by his own CA, one that is not trusted by any browser and should therefore produce a security warning.

If browsers didn’t produce security warnings for home-made certificates, then any crook would be able to mint a certificate in the name of any website.

Here’s what happened:

In short, a phishing site with an unvalidated, unverified certificate might end up looking legitimate to a PrivDog user.

PrivDog “re-mints” a certificate with an untrusted signer as a certificate with a trusted signer, namely PrivDog itself.

The fix

Fortunately, Comodo and PrivDog have now updated the software.

As far as we can tell, the latest version no longer has this security-sapping bug:

This sort of bug is a pretty bad look for a security company – particularly one whose main business is verifying the identity of the owners of HTTPS certificates.

It’s a bit like a notary public, who is supposed to certify documents and annotate them with his official stamp, handing out free copies of his stamp so you can quickly and easily certify your own documents at home.

Additionally, the makers of PrivDog probably didn’t do themselves too many favours by writing up this bug with the words:

A minor intermittent defect has been detected in a third party library used by the PrivDog standalone application which potentially affects a very small number of users.

What would have been so hard about saying, “Sometimes our product would let through untrusted certificates without a suitable warning, so we’ve fixed that bug”?

What to do?

If you have PrivDog installed, make sure you’re up to date!

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/GltmynmbEfg/

Comments are closed.