Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Google Security IT

Turkish Registrar Enabled Phishing Attacks Against Google 75

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."
This discussion has been archived. No new comments can be posted.

Turkish Registrar Enabled Phishing Attacks Against Google

Comments Filter:
  • by Anonymous Coward

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

  • by Anonymous Coward on Thursday January 03, 2013 @08:54PM (#42470455)

    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.

    • by Cryacin ( 657549 )
      Can't fly like an eagle if you're hanging round in Turkey. (ducks)
    • Re: (Score:3, Insightful)

      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 [arstechnica.com]

    • 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.

      • by John Hasler ( 414242 ) on Thursday January 03, 2013 @10:47PM (#42471371) Homepage

        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.

      • by TheLink ( 130905 )

        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/ [mozilla.org]
        Makes that attack a bit harder.

        • I do too, but it's a pain for *.google.com and similar properties, because they have concurrently use certs from two or more CAs. Thus when bouncing between random webservers for google, the cert appears to change. Trusting even the CA doesn't help as the CAs change. So I just look at the CAs themselves and the dates and sometimes investigate the details like key size and TLS mentions and email address; things a sloppy attacker may miss if they're trying to MITM me.

          • by TheLink ( 130905 )
            Yeah it needs to be able to track the last X certificates that you say "OK" too and don't give warnings for those.
      • I think that's the wrong line of thought which isn't very productive. I think the correct observation is that the end user isn't given an importunity to select what level of trust they want to have in which CA's by default.

        It would make more sense upon instillation of a browser/os/whatever to select how trustworthy you want to be, with the following selections:

        Trust most popular CA's.
        Trust most Trusted CA's
        Trust regionally trusted CA's
        Trust all CA's that are globally trusted ( the default right now)

    • 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 :(

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

      Moxie had some cool thoughts on the matter here [thoughtcrime.org]. And tried to create an alternative Convergence.io. Video too: http://www.youtube.com/watch?v=Z7Wl2FW2TcA [youtube.com]

      • Unfortunately, development for it has been abandoned for a while, and a good chunk of the time, the SSL notaries will be down, leading to tons of false warnings about invalid certificates.
    • by tlhIngan ( 30335 )

      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.

      We

      • by TheLink ( 130905 )
        Just go to Firefox's config stuff and "untrust" the CAs you don't trust.

        It's much harder to do this in IE because IE does not come with a full list of all the root CAs they will trust. CA's can get added automatically as long as a trusted CA has signed them.

        That said in practice there's not a big difference since many major CAs sign other CA's certificates. So if you trust Entrust, you can end up trusting CNNIC (China's main CA).

        I just use stuff like Certificate Patrol. However it does need to be cleverer a
    • How many of they ones that happened to be based in countries you trust have signed intermediary certificates for people you don't. No way of knowing, even Google/Mozilla/Microsoft don't know.
      The entire concept of security pegged on a few central authorities is naive.

    • Re: (Score:3, Insightful)

      by gessel ( 310103 ) *

      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.

    • by Lennie ( 16154 )

      Actually, the default lists (because of sub-CAs) trusts about 1200 organisations. At least that is what the EFF SSL Observatory found out.

  • by louarnkoz ( 805588 ) on Thursday January 03, 2013 @08:59PM (#42470507)
    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.

    • 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.

      • by KiloByte ( 825081 ) on Thursday January 03, 2013 @10:32PM (#42471265)

        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.

        • by Anonymous Coward
          The problem with that is many countries DNS registrars are run even more poorly than CA based system that need fixing, going from one busted system to another doesn't solve anything.
          • by Anonymous Coward

            But "fix my country's DNS registry" is an achievable goal, and so is "Move to a country whose DNS registry isn't fucked". Whereas "Fix all of the hundreds of tinpot CAs from everywhere in the entire world" is a game of whack-a-mole that we've been losing for more than a decade.

      • by Rich0 ( 548339 )

        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.

  • Fun times when I can actually see ./ turn slowly but surely into CNN / Fox. Way to make it sound like this was intentional etc. I guess Diginotar too enabled an attack on Google, eh?
    • by Anonymous Coward

      Dude, it's a turkey registrar. This is revenge for the many turkeys killed every year.

    • by gweihir ( 88907 )

      Way to make it sound like this was intentional etc. I guess Diginotar too enabled an attack on Google, eh?

      I think these people just do not want to see that the certificate system is broken by a design that ignores the constraints of the real world. It is rather obvious that you cannot trust hundreds of organizations to do this right all the time. The certificate system was designed and implemented by people that either do not understand the real world or did not care because they saw a commercial opportunity. Turktrust is just a victim of random chance, and at least they found out what went wrong. Not that anyt

    • by thue ( 121682 )

      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.

      • by hobarrera ( 2008506 ) on Thursday January 03, 2013 @09:47PM (#42470897) Homepage

        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.

        • by Rich0 ( 548339 )

          Agreed. The problem is that CAs are generally for-profit companies and they're optimized for making money. That usually means issuing the largest number of certificates in the least amount of time for the least amount of effort. They also have no inherent interest in privacy, so don't expect them to stand up to any kind of pressure to sign certificates for anybody who has influence over them (governments mostly, but that could also include insiders and partners).

          It isn't that hard to make a very strong C

          • They should worry a lot more about privacy/not screwing up.
            One problem like this is enough to kill the company. Forever.

            • by Rich0 ( 548339 )

              True, but the capital requirements for a CA are pretty darn low. So, if things go badly just declare bankruptcy, sell a copy of your procedures to a "new" company (with the same employees), and apply for WebTrust/etc. Sure it will set you back a few months, but it isn't like you have to buy factories and all that nonsense to start over.

  • by Anonymous Coward

    Why don't browsers require certificates to be signed by two (or more) independent authorities? That wouldn't eliminate this kind of attack, but it would make it significantly harder.

    • X.509 doesn't have this capability. The certificate has exactly one issuer.

      See http://tools.ietf.org/html/rfc5280#page-20 [ietf.org]
      • A certificate can (obviously) only have one issuer.
        What he's suggesting is having multiple certificates corresponding to one private key.

        This seems like an eminently sensible idea. Part of the problem is that the Certifying Authorities get "too big to fail" and it takes something pretty massive for a CA to have their authority revoked as doing so impacts a lot of users.

        If sites (at least those interested enough in HA to preemptively guard against the invalidation of a CA) could back their keys with mult
        • 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 specific
        • This seems like an eminently sensible idea. Part of the problem is that the Certifying Authorities get "too big to fail" and it takes something pretty massive for a CA to have their authority revoked as doing so impacts a lot of users.

          I wouldn't say any CA is "too big to fail". If Microsoft, Apple, Google, and Mozilla remove your root certificates, you are gone. And they can go beyond removing your root certificates; they can hardcode revocation of your root certificate into the SSL stack.

    • by leuk_he ( 194174 )

      Beside the fact that this technically is not yet implemented.

      The big problem would be: what if one of the 2 signatures fails? Trust one? Only trust if one signature is correct and that it contains what the other signature should be?

      And don't forget that a signature does not say that a site is secure. It only says that the site is who it says it is. It can still do evil things, and if it does it still might be very hard to track who the evil site is.

      And even then the browser implementation to handle failures

  • They at least they were able to find out what happened. I bet not all CAs can do that. No, the problem is that when you have hundreds of organizations, some will make mistakes. Especially when they are basically all commercial and feel the cost-pressure that comes with that. And some of these mistakes will get exploited by people that may or may not have contributed to the accident in the first place.

    No, the problem is not incidents like this one. The problem is that when you have more than, say, 10 people

  • by Rix ( 54095 ) on Thursday January 03, 2013 @10:00PM (#42471019)

    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.

    • by Anonymous Coward

      The CA cartel is bad enough as it is, let's not give the biggest CAs even more control over the market.

To be is to program.

Working...