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 Turkish domain registrar.
In a blog post published today, Google said that on Dec. 24, 2012, its Chrome Web browser detected and blocked an unauthorized digital certificate for the “*.google.com” domain.
“We investigated immediately and found the certificate was issued by an intermediate certificate authority (CA) linking back to TURKTRUST, a Turkish certificate authority,” wrote Adam Langley, a Google software engineer. “Intermediate CA certificates carry the full authority of the CA, so anyone who has one can use it to create a certificate for any website they wish to impersonate.”
Langley said that Google responded by Chrome on December 25 to block that intermediate CA, and then alerted TURKTRUST and other browser vendors. “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. On December 26, we pushed another Chrome metadata update to block the second mistaken CA certificate and informed the other browser vendors.”
Separately, Microsoft has issued an advisory with a bit more detail, saying it is aware of active attacks using one of the fraudulent digital certificates issued by TURKTRUST Inc.
“This fraudulent certificate could be used to spoof content, perform phishing attacks, or perform man-in-the-middle attacks. This issue affects all supported releases of Microsoft Windows,” the software giant warned.
According to Microsoft, TURKTRUST Inc. incorrectly created two subsidiary CAs (*.EGO.GOV.TR and e-islem.kktcmerkezbankasi.org). The *.EGO.GOV.TR subsidiary CA was then used to issue a fraudulent digital certificate to *.google.com. This fraudulent certificate could be used to spoof content, perform phishing attacks, or perform man-in-the-middle attacks against several Google web properties.” [link added]
It’s not clear yet whether this was an attack against Turkish residents, or if the targets were more widespread geographically. The domain that Microsoft mentioned in its advisory — kktcmerkezbankasi.org — is not resolving at the moment. But according to a screen shot of the domain’s home page taken by Domaintools.com on March 14, 2012 (see image above), the site represented itself as the Central Bank of the Turkish Republic of Northern Cyprus (TRNC), a financial institution established in Northern Cyprus in 1983.
In any case, compromises like this one can lead to colossal security failures. An attacker with certificate authority signing ability can sign certificates for virtually any domain. The TURKTRUST incident harkens back to another similar compromise that happened around the same timeframe. In September 2011, Dutch certificate authority Diginotar learned that a security breach at the firm had resulted in the fraudulent issuing of certificates. A follow-up investigation suggested that the attacker who penetrated the Dutch CA DigiNotar last year had complete control of all eight of the company’s certificate-issuing servers during the operation and he may also have issued some rogue certificates that have not yet been identified. Diginotar later declared bankruptcy.
Microsoft has pushed out an update that addresses this weakness and removes the fraudulent certificates from the list of trusted certs in Windows. According to Microsoft, the update should be automatically deployed to users on Windows 8, Windows RT, Windows Server 2012 and devices running Windows Phone 8. An automatic updater of revoked certificates is available for Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2, from this link. Windows XP and Windows Server 2003 customers can grab the update via Microsoft Update (it’s not immediately clear from Microsoft’s advisory whether users of other Windows versions can obtain the update from Microsoft Update as well).
Update, 3:57 p.m. ET:A previous version of this story incorrectly named TURKTRUST as an institution run by the Turkish government. The above copy has been corrected.
Update, 4:16 p.m. ET: Firefox browser maker Mozilla just published a blog post noting that it, too, was revoking the fraudulent certs.
Just a quick fix; the company is NOT tied to the government (http://www.turktrust.com.tr/en/hakkimizda.html). It is a private institution.
Yep, thanks. I caught that as well as I re-read that page about the company. I believe I misread it earlier to state that it was run by the Turkish armed forces. The above copy has been corrected.
Thanks for the quick update, Brian. 🙂
hey burak, isnt it Pollyannaism ?
yeah it’s a private institution but it has founded by a foundation (TSK Elele) which aims to help Turkish war veterans. That foundation has so close connection with Turkish army and the managers and founders of the foundation are retired Turkish officers.
This shows how totally clueless and unprepared government and military organizations are for cyber attacks. Public PKI is broken and should not be used to secure any sensitive information.
And not to forget, this is a fatal mistake by TURKTRUST and I hope that they will bear the consequences for that.
As a long time reader of your blog (happy anniversary) I think the posts like the previous one (clicknloan) should be somehow edited/removed, besides they are ‘spam’ they can lead to malicious sites.
Thanks for keeping (your) web clean 🙂
As you can see, the spam post has since been removed.
But shouldn’t there be a “report” button next to each post?
Should we rush to warn our security-illiterate friends and relatives about this?
That each and every time they connect to a Google domain via SSL, they should check that the cert isn’t from TURKTRUST?
Is there an illustrated, step-by-step tutorial for visually checking SSL certs that we could refer such benighted souls to?
No, any modern web browser will take care of this for you.
Just make sure your friends and relatives update their web browser to the latest version (Chrome and Firefox will do this automatically).
(Replying to Jonas as well as Christoph)
According to the Mozilla blog post linked in Mr. Kreb’s post,
The breach was first reported at large on January 3rd, so that leaves a five day window of vulnerability for Firefox (and presumably Seamonkey) users.
What about Android users?
What about Safari?
As far as OS patches, as of this posting, Ubuntu at least has not issued anything.
If your friends and family keep their OS, web-browser and browser plugins up-to-date then they are safe from now on regarding this certificate issue and their computers/browsers will warn them in case they should ever encounter these certificates.
Having said that, the malicious *.google.com SSL certificate could have been “in the wild” for well over a year.
So, if you have friends and family that are involved in the political or legal battles between northern and southern Cyprus, they should definitely change their passwords.
This is an example of why the CA trust model is broken, not just for this single instance, but for all public HTTPS websites. There must be thousands of these bogus certs out there that have not been found. THOUSANDS.
If you care about real security, using non-public private/private keys seems to be the only way.
I was in Turkey in late Oct’12 and I only used NX to connect back home to my desktop and did all my surfing and other day-to-day things over that connection. The ssh-keys prevented any concerns from this … assuming any Turks were even attempting to corrupt the network traffic.
Seems that my paranoia while traveling was founded.
BTW, outside the main tourist areas, none .. ZERO … of our USA-based credit cards worked. Bank fraud is a huge issue in Turkey, well beyond the normal USA and main European levels of fraud according to a friend in the banking industry there.
@JohnP:
You are right that the PKI trust model based on CAs is essentially broken but on that basis you can hardly trust surfing via your US-based PC (remotely with NX or sitting at your desk at home) than any malware-free device somewhere else in the world.
Pretty much all of the big names in the CA system have had breaches leading to forged/stolen certificates of varying significance at one time or another, and that’s just the ones that we know about. Peter Eckersley from the EFF published some interesting research about this: https://www.eff.org/deeplinks/2011/10/how-secure-https-today.
What we urgently need to do is find a secure alternative that offers some “trust agility”, whereby we can choose to revoke our trust in a particular source of authenticity without a huge chunk of the internet vanishing, as it would at the moment if, for example, we chose not to trust Comodo (not an unreasonable thing to do, some might say). Something like Moxie Marlinspike’s Convergence system would fit the bill but it has effectively been blocked by the likes of Google and the vested interests of the major CAs. His talk about this Blackhat 2011 is required listening (and also both interesting and entertaining): https://www.youtube.com/watch?v=Z7Wl2FW2TcA.
As for those here stating that this or that browser offers protection or keeping your system up to date with certificate revocations makes you safe that is essentially nonsense. These things offer only partial protection and when a CA or a reseller is hacked or controlled by a malicious party and that is not known publicly we are all vulnerable.
Ssh keys really aren’t an answer, they help old users of a given computer but don’t help new users. If you’re attacking a system, you could probably use heuristics and decide which users are likely to have not seen the key before and therefore will default trust.
Plus, the error message for hosts-changed-keys is absolutely incomprehensible. If you think that the SSL bad Cert for self signed case has a bad message, you haven’t seen anything, just try dealing with key changes for ssh-hosts where someone has to rebuild their systems (like FreeBSD?) for normal users.
While the CA-PKI model isn’t perfect, the alternatives are significantly worse.
No process is perfect, everybody makes mistakes. The number of mistakes by Registrars and Hosting entities far exceeds the countably few made by CAs. Indeed, the CAs aren’t perfect, but if we have 1 a year, that’s really minor when compared to all of the mistakes and failings of Registrars, DNS and hosting entities.
I personally have my email address attached to a random domain as an administrative contact. I have absolutely nothing to do with the domain, but I can’t get the incompetent Registrar to do anything about it.
The absolute *last* thing I want is for Registrars to be responsible for Trust.
@timeless:
I’m not sure how or if you could fail to understand the nature of the problem more comprehensively:
(i) if a CA is covertly compromised the potential is that any and all “secure” traffic on the internet is vulnerable i.e. catastrophic – in comparison the consequences of mistakes/compromise at registrars and hosting companies is minuscule in scope;
(ii) contrary to your assertion there are well documented cases of CAs and/or their resellers being compromised with alarming regularity (never mind the equally catastrophic circumstances caused by a CA issuing an Intermediate CA certificate in error, as in this case) – see the EFF link above;
(iii) in addition to errors and malicious activity there is the problem of poor practice: of the 650+ CAs around the world there are plenty of low-rent outfits who do little or no validation when issuing certificates and even the big players are guilty of this as the number of secure domains increases and margins on the certificates issued decrease;
(iv) as users of the CA system of trust (individuals up to the largest corporations) we have no sanction against badly behaving CAs and neither do the browser vendors: our only option is to revoke the certificates of, say, Comodo (as a whole string of their resellers were compromised in 2011) in which case up to a quarter of the internet’s secure sites go dark for us – an unusable nuclear option;
(v) your reference to registrars, hosting & DNS services is pure FUD – proposed systems like Perspectives and Convergence are nothing to do with passing our trust to another unaccountable group of corporations, rather they are all about being able to flexibly decide where we place our trust online.
Sorry. I had written a longer message which had mentioned that Google Chrome’s system which detected this problem is an example of an incremental improvement which in some ways is quite similar to Perspectives. But that message was eaten by something when I posted it and I was in a hurry to repost the gist.
A lot of people request DNS-SEC which is what I was warning against in that comment.
Yes, it’s true that a certificate which trust but shouldn’t totally voids your safety until the situation is corrected.
But while Perspectives can help certain use cases, there are many UCs and attacks where it won’t help. It won’t help if you’re in a territory where you can’t reach any Perspective servers (I’ve been in such situations). It won’t help if the server you’re visiting is close to the right server and has never had a good certificate – many people start their browsing with insecure pages, so if your start page being insecure has its content tampered such that the link for the secure site you wish to visit is slightly different from the proper secure domain, but leads to a secure domain w/ a bogus, then Perspectives hasn’t helped you (the CA system may or may not have helped you, depending on how good the validation system is and whether you insist on EV — TURKTRUST had its EV bits revoked because of this incident).
@timeless:
Fair points: neither Convergence nor DNS-SEC are panaceas. But then the main proponents/developers of both have never characterised them as such, indeed they are complimentary and also in themselves incremental improvements (albeit large increments) in internet security.
I hope you will look into Convergence more though as it has the potential to cover the vast majority of secure traffic (assuming that some of the large players like Google resource it as it scales). In the case you cite, users travelling the world will probably have local and regional contacts through whom they can locate sources of trust (“Notaries” in Convergence’s terminoligy). Naturally this will not happen overnight but the beauty of Convergence is that as it develops early adopters can use it alongside the current CA system.
Microsoft autoupdate just kicked in on my windows XP desktop with KB2798897 to fix this. More info below.
http://support.microsoft.com/kb/2798897
Thanks for the heads-up, Brian! I installed that Microsoft Update without any problem. 🙂
Since Opera requires a successful revocation check in order to show a site as secure, Opera users should not be affected by this.
The certificate, that did not include revocation information due to a programming error did not work at all because of this error.
http://my.opera.com/rootstore/blog/2013/01/04/erroneous-certificates
Very good information from Opera.
Interesting move on their side to remove the “EV” seal from TURKTRUST-issued certs.
Very interesting.
Perhaps the other browsers can learn from Opera here?
And, in the meantime, perhaps we should all start using Opera for sensitive SSL transactions?
its a good thing we have all this “trustcenters” with the highest standards in security.
//sarcasm off 😉
even if i repeat myself, but the SSL system is horribly broken
You can use SSLCop http://www.security-projects.com/?SSLCop to avoid problems with these Gov-CAs 🙂
Any word on whether this affects Safari and if so whether Safari received a similar unannounced upgrade?
In general, Apple is rather slow (there are worse entities, anyone running Symbian or Bada or WebOS or Maemo/MeeGo or possibly even Android [specifically if the Operators have anything to do with the update process] — but only amongst bit players).
You can check to see when Apple released the DigiNotar update for comparison:
http://threatpost.com/en_us/blogs/apple-removes-diginotar-certificates-safari-090911
I personally just paid to update a computer from 10.6.8 to 10.8.2, so I look forward to actually getting a security update for this when Apple gets around to it…
@JohnP: I am having a hard time trying to swallow what you are telling about Turkey at large. Unfortunately your generalized commentary is not true.
Credit card fraud is lower than many European states here (e.g. http://www.fico.com/landing/fraudeurope/Evolution_Europe.html). In fact Turkey was one of the leading states to adopt Chip&Pin etc.
I do a lot of international trade with US based companies and their representatives (when here) can pay with almost any of their cards.
Maybe you should ask a few more of your colleagues. 🙂
best.
-bd
It’s probably worth explaining why entities like TURKTRUST exist in CA root lists…
The reason that TURKTRUST is trusted is because it would be impossible for a US based entity to establish any reasonable level of assurance that an entity is who it says when certificates are created (you can of course replace US with EU or NAm – it wouldn’t change anything). Thus entities are certified to establish trust within areas or regions.
Similarly, browser vendors really don’t want to be in the business of managing trust down to the server level / per legal entity level. And if they were in that business people would complain about a Cabal…
@Burak DAYIOGLU: I used poor phrasing and apologize. I cannot edit that post to make it better.
Since we do not read Turkish, the exact error from the reader was unknown and the waiter’s English was not sufficient to explain.
I contacted my 3 USA-based banks during the trip to resolve the issues with our credit cards being accepted there. None had a solution. None of our banks provide Chip-n-Pin cards at that time though I have requested one from each institution when available. These were MC, Visa, Amex cards.
When we ventured away from the major tourist locations in either European or Asian parts of Istanbul, our credit cards were not accepted, never. A friend who works for a Turkish bank explained that fraud concerns were the reason our cards were not accepted. It seems that liability is different in Europe and Turkey for _signature-based credit cards_ than in the USA. I don’t know if that is true, just what has been explained and what I’ve read online. The attempted transaction amounts were all under US$200 and most were under $75 at restaurants. It is embarrassing to take a friend’s family out to a nice meal, but not be able to pay over a credit card issue.
The odd thing is that these same credit cards were used in 5 different European countries outside tourist areas a few months earlier without issue. For both trips, the banks were notified of the travel plans. Since returning, each has worked without any denials in the USA too.
To clarify, the fraud concerns in Turkey appear to be for non-Chip-n-Pin credit cards, hence the reason why they are generally not accepted.
The FICO.com link provided actually shows that credit card fraud in Turkey has increased slightly between 2006 (13.29M Euros) and 2011 (13.43M Euros). It is lower in dollar amount than MOST other countries in Europe according to that link.
In an effort to create a apples to apples comparison, I looked up the populations of Spain and Turkey to normalize the data for a per capita comparison. I used the CIA factbook July 2012 population estimates. Spain had 47M people and Turkey had 79.7M people. A napkin calculation shows that Spain has much, much, much higher per-capita fraud levels than Turkey. If my calculations are correct, about 25x Euro/person fraud levels greater in Spain than Turkey. That seems like a huge difference. Someone please check the calcs.
Thank you for pointing that out that Turkey is a relatively low-fraud area in Europe.
A travel partner received a new USA-based credit card recently that does have the chip-n-pin built in. I don’t know if it followed the EMV standard, but that is likely. His older cards were also refused outside the tourist areas in Istanbul.
Anyway, I should not have said that “bank fraud is huge in Turkey” – my last statement of that post cannot be proved as fact, so it should be retracted completely.
I apologize, the error is certainly mine.
@Ian McNee: I agree with your comments, mostly.
If I understand your point correctly, I disagree that surfing virtually through a US-based computer using a VPN while overseas is in some way just as secure as surfing directly using an overseas network. It really comes down to trust in the internet provider where your traffic leaves an encrypted state.
Do I trust my USA-based business ISP more than some random hotel or wifi-hot-spot or government owned telecom ISP? YES!
@JohnP : “our credit cards were not accepted”
question is whether authorisation was sent by acquirer/merchant to the issuer (and then your issuing bank in USA declined it)
OR
authorisation was declined (or not sent at all) by acquirer/merchant
… answering this, you know whom to blame 😉