On Thursday, news broke that a fraudulent digital certificate issued for the domain google.com by an intermediate certificate authority (CA) connected to Turkish certificate authority, TURKTRUST had reportedly been seen in active attacks.
Because Intermediate CA certificates have the full authority of the CA, attackers could use it to create a certificate for any website they want to impersonate and could spoof content, perform phishing attacks, or perform man-in-the-middle attacks.
“Microsoft is aware of active attacks using one fraudulent digital certificate issued by TURKTRUST Inc., which is a CA present in the Trusted Root Certification Authorities Store,” an advisory from Microsoft on Thursday noted.
While Microsoft explained that TURKTRUST incorrectly created two subsidiary CAs (*.EGO.GOV.TR and e-islam.kktcmerkezbankasi.org), of which *.EGO.GOV.TR was used to issue the fraudulent digital certificate to google.com, many questions remained on the details on how this happened.
On Friday, TURKTRUST shared additional information on critical points about the root cause of the incident behind the signing of the fraudulent *.google.com certificate which they say occurred on December 6, 2012.
According to a post from the Turkish certificate authority:
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,” the firm explained.
TURKTRUST said that following the incident, system had been updated on October 17, 2011 and went through a successful ETSI TS 102 042 audit by KPMG on November 2011.
While Microsoft said it was aware of active attacks using the fraudulent digital certificate issued, TURKTRUST said that its available data “strongly suggests that the *.google.com cert was not issued for dishonest purposes or has not been used for such a purpose.”
Additionally, TURKTRUST said there was no data pointing to evidence of a security breach on its systems.
Finally, TURKTRUST made note of following issues:
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 new 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 firewall 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.
