Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Vulnerabilities / Threats

1/4/2013
04:13 PM
Connect Directly
Google+
Twitter
RSS
E-Mail
50%
50%

Errant Google Domain Traced To CA's Mistakes

Certificate authority Turktrust details internal errors that led to phony digital certificates

Turns out the phony Google.com digital certificate that sounded alarms among browser vendors and security experts yesterday came out of a series of missteps by the Turkish certificate authority (CA) and may have only affected users at a Turkish government agency.

A convoluted series of unfortunate events within CA Turktrust led to the existence of a legit-appearing Google domain and the potential for some serious fraud via man-in-the-middle attacks, prompting Google, Firefox, and Microsoft all to block the "*.google.com" domain as of yesterday.

The anomalous domain was not the result of a data breach, according to Turktrust, which mistakenly issued two certificates that ultimately led to the phony Google one. Turktrust traced the incident back to a 2011 audit that required a software migration and moving certificate profiles between a production system and a test system. The Turktrust incident is yet another red flag about the flawed digital certificate authority system, which has suffered a black eye over the past two years with breaches at Diginotar, Comodo, and RSA.

[Following breaches at Diginotar, Comodo, and RSA, digital certificate technology has been deeply tarnished. See Salvaging Digital Certificates.]

"This is probably not a [major security] event, but it points out the problems of this system. It really needs some modification," says Wolfgang Kandek, CTO at Qualys. "The browser vendors are really on the spot to do something [about certificates]."

Turktrust says the accidental issuance of two unauthorized certificates can be traced back to 2011, when certificate profiles on its production system were moved to its test system in preparation for an audit. A few more certificates were added to each system, and the tests were finished by June 30, 2011. "It was the unfortunate event that the production system was patched with the profiles in the test system, which had happened to contain 2 wrong profiles and lacked 3 correct profiles," Turktrust wrote in a blog post. "The wrong profiles were only used on August 8, 2011 to issue those two faulty certificates which were certainly not intended to be sub-CA certificates."

After another round of fixes and tweaks to the certificate profiles that summer, Turktrust passed its audit by KPMG in November 2011. "Therefore the problem had been fixed once and for all although the unfortunate event that the certificates were mistakenly issued remained hidden," the CA says.

One of the two certs was revoked before it was enacted, but the second one was spotted signing the fraudulent "*.google.com" certificate on Dec. 6, 2012. "Before the December 6, 2012, the certificate was installed on an IIS as a web mail server. On December 6, 2012, the cert (and the key) was exported to a new firewall. It was the same day as the issuance of the fraudulent certificate (*.google.com). The firewall was said to be configured as MITM. It appears that the firewall automatically generates MITM certificates once a CA cert was installed (http://www.gilgil.net/communities/19714). The second certificate was immediately revoked as soon as it was brought to TURKTRUST's attention by Google on December 26, 2012," Turktrust says.

The CA says the phony Google cert doesn't appear to have been issued for nefarious purposes. But a Reuters report today cites sources that claim a Turkish government agency may have employed the fake domain in order to monitor its employees.

The errant cert was first discovered on Christmas Eve, according to Google, when Google Chrome detected and blocked it. "We investigated immediately and found the certificate was issued by an intermediate certificate authority (CA) linking back to TURKTRUST, a Turkish certificate authority," blogged Adam Langley, 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."

Google then blocked the second errant cert and alerted browser vendors. Microsoft says Turktrust created *.EGO.GOV.TR and e-islam.kktcmerkezbankasi.org): the *.EGO.GOV.TR subsidiary CA was used to issue a fraudulent digital certificate to *.google.com. Microsoft updated its certificate trust list to remove those certs, and Mozilla also revoked those certs and suspended Turktrust's root certificate.

Qualys' Kandek says a secure CA infrastructure depends on the CAs not making mistakes and employing proper security. "This [case] is a good example of the problem we have on our hands right now. Anyone can issue these certs. The protections are best practices and honesty," he says.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Kelly Jackson Higgins is the Executive Editor of Dark Reading. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise ... View Full Bio

 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
DarkReadingTim
50%
50%
DarkReadingTim,
User Rank: Strategist
1/8/2013 | 4:17:56 AM
re: Errant Google Domain Traced To CA's Mistakes
Another problem at a certificate authority. What do you think, readers?- Can CAs be salvaged, or have you given up hope?
--Tim Wilson, editor, Dark Reading
COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/6/2020
Ripple20 Threatens Increasingly Connected Medical Devices
Kelly Sheridan, Staff Editor, Dark Reading,  6/30/2020
Another COVID-19 Side Effect: Rising Nation-State Cyber Activity
Stephen Ward, VP, ThreatConnect,  7/1/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
The Threat from the Internetand What Your Organization Can Do About It
The Threat from the Internetand What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15350
PUBLISHED: 2020-07-07
RIOT 2020.04 has a buffer overflow in the base64 decoder. The decoding function base64_decode() uses an output buffer estimation function to compute the required buffer capacity and validate against the provided buffer size. The base64_estimate_decode_size() function calculates the expected decoded ...
CVE-2019-19935
PUBLISHED: 2020-07-07
Froala Editor before 3.0.6 allows XSS.
CVE-2020-11882
PUBLISHED: 2020-07-07
The O2 Business application 1.2.0 for Android exposes the canvasm.myo2.SplashActivity activity to other applications. The purpose of this activity is to handle deeplinks that can be delivered either via links or by directly calling the activity. However, the deeplink format is not properly validated...
CVE-2020-15028
PUBLISHED: 2020-07-07
NeDi 1.9C is vulnerable to a cross-site scripting (XSS) attack. The application allows an attacker to execute arbitrary JavaScript code via the Topology-Map.php xo parameter.
CVE-2020-15029
PUBLISHED: 2020-07-07
NeDi 1.9C is vulnerable to cross-site scripting (XSS) attack. The application allows an attacker to execute arbitrary JavaScript code via the Assets-Management.php sn parameter.