TurkTrust’dan Sahte Sertifika Açıklaması “Case Explanation by TURKTRUST”

Güncelleme-2: TürkTrust tarafından teknik detay açıklama Türkçe olarak resmi sitesine eklenmiştir. Aşağıdaki adresten erişim sağlanabilir.

http://www.turktrust.com.tr/kamuoyu-aciklamasi.html

—–

3 Ocak itibariyle  internete yayınlanan haberlerde[1] TurkTrust tarafından sahte Google sertifikaları üretildiği haberleri dolaşmaya başladı.  Daha önce yaşanan DigiNotar, Comodo gibi kötü örnekler olması nedeniyle olay bir kasıt mı yoksa ihmal mi sorusu gündeme geldi.

Bu saate(00:35) kadar yaptığım incelemeler sonucu sadece Google firmasına ait domainlere ait sahte sertifika üretildiğini ve bunun da TürkTrust tarafından yanlışlıkla/sehven verilen bir sertifika kullanılarak EGO tarafından oluşturulduğunu (muhtemelen EGO tarafindan kullanılan bir cihaz üretmiş olabilir, diğer senaryoyu düsünmek istemiyorum)belirledim.

[1]https://blog.mozilla.org/security/2013/01/03/revoking-trust-in-two-turktrust-certficates/

TurkTrust firması  tarafindan yapilan resmi aciklama asagidaki gibidir. Yakin zamanda daha detay teknik aciklamanin bağımsız firmalar tarafindan yapılarak yayinlanacagini umuyorum.

TurkTrust firması ile ilgili herhangi bir resmi bağım yoktur, sadece edindiğim  açıklamayı buradan yayınlıyorum. Firma ile iletisime gecmek icin [email protected] adresine e-posta gönderebilirsiniz.

—

Case Explanation by TURKTRUST

As an Electronic Certificate Service Provider (ECSP), TURKTRUST has been providing SSL certificate services since the year 2005. After having international audits for “ETSI TS 102 042 Management
System for Certification Authorities Standard”, TURKTRUST was granted the British Standards Institution (BSI) compliance certificate for this standard on December 20, 2011. The ETSI compliance
certificate is attached for more information.

During August 2011, there had been an unfortunate instance of having two SSL certificates issued mistakenly as intermediate CA certificates to organizations that should have instead received regular SSL certificates. As a matter of fact, TURKTRUST uses no intermediate CAs for SSL certificate issuance. End-user SSL certificates are only issued centrally by related TURKTRUST SSL sub-root certificates upon requests from end-user clients. As soon as the case was brought to TURKTRUST’s attention almost a week ago, an immediate thorough investigation has been started to identify the root cause.

It turned out that it was solely a faulty data migration operation, occurred during the course of a system upgrade before the successful ETSI TS 102 042 audit that took place in November, 2011. The cause was certainly not associated with any security breaches, attacks or hacking.

A detailed explanation of the root cause, the OCSP and CRL requests analysis and the immediate preemptive actions have been openly communicated with the browser representatives in the last few days. The system, databases and logs have also gone through an exhaustive analysis to find out if any other anomaly occurred during the period under consideration. The data revealed no anomaly at all, the instance was unique and restricted only to those two certificates.

Since the first ETSI TS 102 042 audit of November 2011, TURKTRUST certification services and systems have improved significantly, and a continuous assessment audit recently took place successfully. Hence, TURKTRUST is determined, as it has always been, to continue supplying customers more developed and continuously improving certification services.

Best Regards,

TURKTRUST Inc

—-

Güncelleme-1:00:57

Please find some critical points below about the root cause of the instance:

•        The case occurred in August 2011 during a software migration operation, before the first successful ETSI TS 102 042 audit which took place in November 2011. The sequence of events that led to the mistaken issuance of two certificates can be best summarized as follows:
•        Prior to June 2011, the certificate profiles on the production system were exported to the test system, containing a particular number of certificate profiles.
•        For the sake of testing purposes, 2 more profiles were added that contain CA extensions.
•        In the meantime, the production system was also updated to meet the need of demand to contain 3 more SSL certificate profiles. Hence the production system and the test system appeared to have different number of profiles by one, and the two sets matched only in the profiles at the date of the first data migration.
•        The tests were completed before 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.
•        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.
•        A certificate request on the 10th of August had called the use of one of the missing profiles, which was drawn to attention by a thrown exception. In order to fix this the whole set of certificate profiles was this time replaced to contain all correct profiles. Therefore the problem had been fixed once and for all although the unfortunate event that the certificates were mistakenly issued remained hidden.
It is assured that, this clearly identifies the root cause that led to the generation of faulty certificates. All related data resides in archives, and the sequence was all traced back to understand what really had happened. The system had been finally updated on October 17, 2011 and went through a successful ETSI TS 102 042 audit by KPMG on November 2011.
Although the system is now immune to any such kind of errors, further preemptive measures are implemented as described below:
One is a post process control for the certificates issued; the other is a run time control checking the certificate profile for end users.
Via the post process control, the validity period, basic constraints, CRL distribution point, Authority Info Access (AIA) and the other profile details are checked after certificate generation according to the certificate requirements coming from respective certificate policies before the certificate is delivered to the end customer. The post process control is planned as a separate and independent service from the certificate generation module of the CA software.
Via the run time control, the basic constraints are restricted to the end user certificates.
Both controls have already been implemented.
All OCSP requests and CRL data have already been analyzed to detect any anomaly during the entire period. The data revealed no anomaly at all.

The following issues are also worth considering at the moment:
1)        One of the mistakenly issued certificates has been revoked before putting into use upon the request of the customer.
2)        The other certificate was reported to sign a fraudulent certificate (*.google.com) on December 6, 2012.
3)        Before the December 6, 2012, the certificate was installed on an IIS as a web mail server.
4)        On December 6, 2012, the cert (and the key) was exported to a  commercial firewall. It was the same day as the issuance of the fraudulent certificate (*.google.com).
5)        The  firewall was said to be configured as MITM. It appears that the Checkpoint automatically generates MITM certificates once a CA cert was installed (http://www.gilgil.net/communities/19714)
6)        The second certificate was immediately revoked as soon as it was brought to TURKTRUST’s attention by Google on December 26, 2012.
7)        The available data strongly suggests that the *.google.com cert was not issued for dishonest purposes or has not been used for such a purpose.
8)        There is certainly not a bit of data to show an evidence of a security breach on TURKTRUST systems.

Yapılan SSL sertifika güncellemeleri incelendiğinde aşağıdaki domainleri kapsayacak şekilde(sertifikanın Subject Alternative Name kısmında) *.google.com icin sahte sertifika üretildiği gözüküyor.

*.google.com
*.android.com
*.appengine.google.com
*.cloud.google.com
*.google-analytics.com
*.google.ca
*.google.cl
*.google.co.in
*.google.co.jp
*.google.co.uk
*.google.com.ar
*.google.com.au
*.google.com.br
*.google.com.co
*.google.com.mx
*.google.com.tr
*.google.com.vn
*.google.de
*.google.es
*.google.fr
*.google.hu
*.google.it
*.google.nl
*.google.pl
*.google.pt
*.googleapis.cn
*.googlecommerce.com
*.gstatic.com
*.urchin.com
*.url.google.com
*.yo
utube-nocookie.com
*.youtube.com
*.ytimg.com
android.com
g.co
goo.gl
google-analytics.com
google.com
googlecommerce.com
urchin.com
youtu.be
youtube.com

TurkTrust’a geçmiş olsun.