Turkish Registrar Enabled Phishing Attacks Against Google

tsu doh nimh writes "Google and Microsoft today began warning users about active phishing attacks against Google's online properties. The two companies said the attacks resulted from a fraudulent digital certificate that was mistakenly issued by a domain registrar run by TURKTRUST Inc., a Turkish domain registrar. Google said that on Dec. 24, 2012, its Chrome Web browser detected and blocked an unauthorized digital certificate for the '.google.com' domain. 'TURKTRUST told us that based on our information, they discovered that in August 2011 they had mistakenly issued two intermediate CA certificates to organizations that should have instead received regular SSL certificates,' Google said in a blog post today. Microsoft issued an advisory saying it is aware of active attacks using one of the fraudulent digital certificates issued by TURKTRUST, and that the fraudulent certificate could be used to spoof content, perform phishing attacks, or perform man-in-the-middle attacks against virtually any domain. The incident harkens back to another similar compromise that happened around the same time-frame. In September 2011, Dutch certificate authority Diginotar learned that a security breach at the firm had resulted in the fraudulent issuing of certificates."

Comments

Why should I have trusted these people?

[Anonymous Coward]

I know this must sound Xenophobic, but I have gone into the SSL certs list lately and disabled a bunch I would never trust. Turkish, Russian, etc.

Some of them I was frankly surprised that Mozilla, Google, Microsoft, Apple etc would trust. There are literally a few hundred in most devices. Who vets them? Also shouldn't there be a better way then for a user to wade through hundreds of certs (some in languages they dont know).

Honestly curious why this is set up this way, it seems so inefficient and insecure.

Re:Why should I have trusted these people?

[GiganticLyingMouth]

Honestly curious why this is set up this way, it seems so inefficient and insecure.

Hah, welcome to the internet. But seriously though, a lot of the protocols in use weren't designed with the current form of the internet in mind, so looking at them now it's almost amazing that the internet is as functional as it is. The web is built on trust, which made sense back in its infancy. Not quite as much anymore however. for example, just a few months ago google was effectively inaccessible to a portion of the world, entirely by accident

Re:Why should I have trusted these people?

[hobarrera]

Following that line of thought, why should the rest of the world trust US-based CAs?
I mean, I'm pretty sure the NSA and a couple of other agencies can request that CAs emit certificates to them and force them to keep their mouth shut about it.

Re:Why should I have trusted these people?

[petermgreen]

Honestly curious why this is set up this way, it seems so inefficient and insecure.

I remember watching a video on it somewhere and iirc at the time the main concern when https was introduced was evesdropping and protection against MITM attacks was very much an afterthought.

By the time everyone realised that the model of having CAs whose financial interests are to issue a cert without asking too many questions and any one of which could declare a server trusted to serve content for a url was fundamentally broken it was too late to do much about it :(

Re:Why should I have trusted these people?

[John Hasler]

If you are dealing in state secrets you shouldn't trust any CA. If, on the other hand, you just want to keep thieves from cleaning out your bank account you needn't worry about any major government: they have more direct ways of getting your money.

Re:Why should I have trusted these people?

[TheLink]

They shouldn't automatically trust them.

I'm pretty sure the NSA and a couple of other agencies can request that CAs emit certificates to them and force them to keep their mouth shut about it.

I use Certificate Patrol: https://addons.mozilla.org/en-us/firefox/addon/certificate-patrol/
Makes that attack a bit harder.

Re:Why should I have trusted these people?

[tlhIngan]

I know this must sound Xenophobic, but I have gone into the SSL certs list lately and disabled a bunch I would never trust. Turkish, Russian, etc.

Some of them I was frankly surprised that Mozilla, Google, Microsoft, Apple etc would trust. There are literally a few hundred in most devices. Who vets them? Also shouldn't there be a better way then for a user to wade through hundreds of certs (some in languages they dont know).

Honestly curious why this is set up this way, it seems so inefficient and insecure.

Well, the question is - what if you're Turkish? Or Russian? Or <other_country>?

Does that mean you have to ask Mozilla to produce a special version of FireFox for Russia with the Russian CAs in it? Ditto everyone else? I'm sure the Turks or the Russians have to use certificates issued by their national CAs.

I suppose it would be handy, to go to the Firefox download page and have to answer 20 questions to figure out what OS you want, what language you want, and what CAs you want to trust, then click Download to get that specific version. (Hell, most people would probably click "Select All" and then Download and be done with it).

Of course, life would be so much simpler if we could just ignore everything except en-us. Dealing with unicode encodings is hard enough, let's just use ASCII and declare everyone else should too...

Re:Why should I have trusted these people?

[gessel]

The certificate system is badly broken on a couple of levels. Most obvious and relevant to the OP is that there are 650 root CAs that can issue certs, including some state-run CA's by governments with potentially conflicting political interests or poor human rights records.

It is useful to think about what we use SSL certs for:

1) Establishing an encrypted link between our network client and a remote server to foil eavesdropping and surveillance.

2) To verify that the remote server is who we believe it to be.

Problem 1 is by far the most important, so much more important than number 2 that number 2 is almost irrelevant, and fundamental flaws with feature 2 in the current CA system make even trying to enforce verification almost pointless. Most users have no idea what SSL verification actually means or what any of the cryptic (no pun intended) and increasingly annoying alerts warning of "unvalidated certs" mean anyway.

What I find most annoying is that the extraordinary protective value of SSL encrypted communication is systematically undermined by browsers like Firefox in an intrinsically useless effort to convince users to care about verification. I have never, not once, ever not clicked through the warnings on a web site to access it. And even though I often access web sites from areas that are suspected of occasionally attempting to infiltrate dissident organizations with MITM attacks, I still have yet to see a legit MITM attack in the wild myself. But I do know for sure that without SSL encryption my passwords would be compromised - how many of us get spam from friends with Yahoo accounts? Yahoo still does not SSL encrypt login by default and so accounts are regularly compromised by spammers. Encryption really matters and is really important to keeping communication secure. Anything that adds friction to encryption should be rejected.

Self-signed certs and community certs (like CACert.com) should be accepted without any warnings that might slow down a user at all so that every website, even non-commercial or personal ones have no disincentive to adding encryption. HTTPSEverywhere. Routers should be configured to block non-SSL traffic (and HTML email, but that's another rant. Get off my lawn.).

Verification is unsolvable with SSL certs for a couple of reason, some due to the current model, some due to reasonable human behavior, some due to relatively legitimate law-enforcement concerns:

Obviously the OP makes clear that the current model is badly broken because the vast majority of issuing companies have every reason to minimize the cost of providing a cert which means cutting operational costs and increasing the risk of human error. Though even at a well run notary, human error is likely to occur, especially as notaries in different countries, speaking different languages can issue certs for companies in any other location. Certificate issuance by commercial entities is fail. A simple error can, because registrar certs are by default trusted, compromise anyone in the world. One mistake, everybody is at risk. Pinning does not actually reduce this risk in advance, though rapid response to discovered breaches can limit the damage.

But even if issuance were fixed, it wouldn't necessarily help. Most people would happily click through to www.bankomerica.com without thinking twice. Indeed, as companies may have purchased almost every spelling variation and point them all toward their "most reasonable" domain name, it isn't unreasonable to do so. If bankomerica.com asked for a cert in tashkent, would the (or even should they) be denied? No - green bar, wrong site. Even if they were non-SSL encrypted, it isn't practical to typo-test every legit URL against every possible fake, the vast majority of users would never notice if their usual bank site came up unencrypted (no cert at all). This user behavior limitation fundamentally obviates the value of certs for identifying sites. But even a typo-misdirection is assuming too much - all of my phishing

root trust: the hole in PKI, SSL, TLS!

[louarnkoz]

Everybody thinks that if an "https" connection is securely established, if the browser displays a green light, then they are good. But it only proves that the other end of the connection showed a "valid" certificate, where "valid" is defined a "signed by one of the hundreds of authorities allowed to do so, or by any entity who somehow obtained a certificate with signing rights from one of these authorities."

We have seen attacks like that before, e.g. the "Comodo" hacker (http://arstechnica.com/security/2011/09/comodo-hacker-i-hacked-diginotar-too-other-cas-breached/). My bet is that we will continue to see more of these, because the attack surface is just too large.

Re:root trust: the hole in PKI, SSL, TLS!

[hobarrera]

HTTPS really means "probably more secure than plain text".
Regardless of it's efficiency, TLS/SSL/PKI is the best thing we've got, sadly. I've yet to see a mechanism that can replace it. A few can complement it, but that's just about it.

Re:root trust: the hole in PKI, SSL, TLS!

[KiloByte]

What you want is DANE. Sadly it's hardly supported in browsers at all yet, but it allows throwing out all the CA crap, replacing them with just three parties to trust: ICANN, your country's DNS registry, and your registrar.

Re:root trust: the hole in PKI, SSL, TLS!

[Rich0]

The irony is that plain text never pops up a security warning, but SSL does if the certificate isn't trusted. There is no attack that can be mounted on an untrusted SSL certificate that can't be mounted on plain text, and the latter is susceptible to additional attacks.

The whole system is in massive need of replacement.

Re:TURKTRUST's explanation

[thue]

In summary, they claim that a testing profile (which creates intermediate certificates) on a test system were accidentally copied to a production system, and in effect for two days. The MitM *.google.com cert is claimed to be have been automatically issued by a Checkpoint firewall once a CA cert is installed, without intention from the owner of the accidental CA cert.

So TURKTRUST claims it has all been an accident.

Re:What will be the wider response to this?

[Anonymous Coward]

Mozilla's response https://blog.mozilla.org/security/2013/01/03/revoking-trust-in-two-turktrust-certficates/

Re:TURKTRUST's explanation

[hobarrera]

I don't really care if it was on purpose or an accident. They clearly cannot be trusted as an Authority in security is they make this kind of mistakes.

Why do we have this proliferation of minor CAs?

[Rix]

They shouldn't have been issuing certificates trusted by default anyway. Pare down the CA list included by default in browsers since so many of them are no more authoritative than self signed certificates anyway. If someone wants to trust TURKTRUST, let them import them themselves. The vast majority has absolutely no reason to.

Re:What will be the wider response to this?

[sabri]

The response to DigiNotar was an quick and almost-complete revocation of trust of the DigiNotar root certificate.

And the response to that was that Diginotar went bankrupt.

Re:Multisigning

[starfishsystems]

What he's suggesting is having multiple certificates corresponding to one private key.

Ah, interesting. Having generated the key pair, you submit the public key as a cert signing request to multiple CAs. Then you would have a hot spare if one of the certs was revoked. It seems like a worthwhile idea.

But that's not what he's suggesting. You will end up with multiple server certs all right, but there is no way for a client to know that, so it can't undertake to validate all of them, which is specifically what he's suggesting would be a useful safeguard for the client. He requires an and operation and you're proposing an or. Nor is it useful to add some capability to assert multiple certs. If one of the certs is compromised, that's the one which a rogue server will assert is the only one. His proposal requires integrity of a single cert with respect to multiple signers, and X.509 doesn't provide for that.

It's not impossible in principle. Given a sufficiently large key pair, you could split the public key into pieces and have each CA sign one of them. Only if all certs validate will the client concatenate the complete public key and use it perform a handshake with the server. But it's not X.509 and I think we still have the problem of how the client is supposed to know to do this.