ADDITIONAL Information Security Review, 3b/2011. 28 November 2011 On vulnerabilities in the certificate system

ADDITIONAL Information Security Review, 3b/2011 28 November 2011 On vulnerabilities in the certificate system 1

CERT-FI Information Security Review 3b/2011 On vulnerabilities in the certificate system This additional CERT-FI information security review focuses on vulnerabilities found in certificate systems and information security incidents affecting certification service providers. The review further specifies and delves deeper into the issues discussed in the information security review 3/2011. Included in this article are recommended measures and practices for end-users, data administration units and application developers, aimed at ensuring their own information security and that of other parties. The certificate system s security has been compromised Several certification service providers issuing server certificates have been subjected to intrusion attempts and successful data breaches over the year. Access rights obtained by the intruders have been used to generate server certificates in the name of third parties such as Google. At the moment, we have no certain knowledge of the intended use of these fraudulently obtained certificates. There has been speculation that certain states intelligence agencies were involved. The presence of technical and process-related vulnerabilities in the certificate system has been demonstrated on prior occasions. Certification service providers have signed certificates without ascertaining the applicant s true identity and position. Checkups of certificate validity and their annulment are unreliable, causing problems when certificate key pairs fall into the hands of outsiders. Operating systems and applications rely on a large number of root certification authorities, which are assumed to be reliable, even though the majority of users never need the certificates signed by these authorities. Experience has shown that not all certification service providers can be considered trustworthy. There are no reliable technical measures for annulling a relationship of trust. The events of the past year have brought these problems to light. Vulnerabilities in the system have been systematically exploited, resulting in the information security of a large number of users being compromised. As currently implemented, the security provided by certificates is insufficient. What is more, no major improvements can be expected without a complete certificate system overhaul. This document details the information security breaches and threats that have become public knowledge and dispenses advice that will help users, IT management and application developers to utilise the security features of the existing certificate system in order to protect their environments. 2

ComodoHacker case In 2011, several successful system breakins that targeted certification service providers were perpetrated. The common thread was that the perpetrator attempted to create authentic server certificates. In some cases, the intruder succeeded, while even managing to hide the data breach. The perpetrator and customer remain unknown. A hacker using the alias ComodoHacker has publicly claimed responsibility for the break-ins. The user of this alias states that it is backing the government of Iran against the Arab Spring uprising. Neither the identity nor the nationality of this party is known: it is not even known whether an individual or group is using the alias. The first system break-in to come to light targeted a US root certification authority named Comodo. On 23 March 2011, the company released a statement in which it claimed that the user ID of a person working for a subcontractor had fallen into the hands of an outsider. This user ID was used to create nine server certificates, including ones for the addresses www.google.com and login.skype.com. The company detected the data breach within hours of the incident and annulled the fraudulently obtained certificates. Since annulment of certificates alone may not be sufficient to prevent misuse, major software companies such as Microsoft and Mozilla brought forward the release of updated versions of their products, preventing the use of unreliable certificates. In mid-june 2011, the Israeli certification authority StartSSL was subjected to an attempted system break-in. Similarly to the other attacks, the attacker attempted to gull the CA into issuing certificates for services owned by other parties. According to StartSSL, this attempt failed. At the end of August, it was revealed that an attack on the Dutch company DigiNotar had resulted in the creation of authenticseeming certificates for all Google services. This sequence of events began on 28 August, when an Iranian user enquired about the Chrome browser s odd behaviour, in an error description submitted to a support forum. It transpired that an Iranian operator named Pars Online was routing traffic to Google servers, through intermediary servers equipped with apparently authentic server certificates issued by DigiNotar. This incident came to light because the Google Chrome browser is programmed to display an alert if a server is signed by a CA other than those predetermined by Google. DigiNotar was not included on the list in question. DigiNotar systems had signed the certificate on 10 July 2011, meaning that the system break-in had occurred at least one and a half months prior to the event. DigiNotar only admitted to the incident s occurrence in the face of public pressure. Later, it became clear that the company had gone so far as to actively attempt to cover up the incident. A security review ordered by the Dutch government revealed that the certification service providers information security had been based on extremely deficient practices. It is still unclear how DigiNotar had been able to deceive system auditors in the past. DigiNotar had been accepted onto a list of CAs trusted by major browser producers, after passing an audit performed by a well-known firm of consultant auditors. Since then, the Dutch government has assumed control of DigiNotar s business operations and cancelled all of its certificates. The USbased company Vasco, which had acquired DigiNotar in January 2011, declared the company bankrupt around a month after the detection of the system break-ins. As in the case of Comodo, the annulment of DigiNotar certificates required action by software producers. There is no procedure for annulling root CAs within the certificate system itself. A suspected data breach concerning GlobalSign CA came to light on 5 3

September 2011, when the user of the alias ComodoHacker, the perpetrator of the previous attacks, openly boasted about the matter. Issuance of GlobalSign certificates was momentarily suspended. Investigations revealed that only the company Web servers had been hacked. On 13 September 2011, issuance of certificates was resumed after a few days investigation. Older cases Vulnerabilities in certificate system processes have also been exploited for identity fraud purposes in older cases. For instance, in 2008, an information security specialist was able to obtain Live.com certificates from Thawte. More recent cases Two new information security problems concerning certification service providers have become public knowledge since the ComodoHacker case. On 3 November 2011, it was revealed that an Entrust subcontractor named DigiCert Malaysia had issued 22 certificates utilising 512-bit keys, which are considered insecure. These certificates did not include information on the certificate annulment service or their purpose of use. However, there is no evidence that these certificates were used for fraudulent activities, or that they were obtained through fraudulent means. DigiCert Malaysia certificates have been deleted from browser root certificate lists. The fact that browser root certificate lists include a major, similarly named certificate seller based in the US has only added to the confusion. Measures prompted by these cases In the cases of Comodo and DigiNotar, the majority of major browser and OS producers quickly released updates eliminating the newly distrusted root certificates. Their actions were somewhat more rapid in the case of DigiNotar than in the Comodo case. Updates were made available two to eight days after the detection of the system break-ins. Although no actual mechanisms exist for annulling root certificates, the situation can be rectified by releasing software updates that eliminate distrusted certificates. However, software updates may entail significant delays with regard to both the release of updates and their installation in systems. In practice, the attacker has the potential to continue exploiting any fraudulent certificates it has obtained for a long time afterwards. Even before the Comodo case, the information security community was generally aware of the risks inherent in the certificate system. However, there have been no practical alternatives to the system. As in the case of many other technologies, X.509 certificates and the SSL/TLS (Secure Sockets Layer, later termed Transport Layer Security) protocols are used much more extensively than was imagined when the standards were drafted. These protocols have been adopted for many entirely new applications; in the design stage, insufficient account was taken of threats that are now viewed as significant. The KPN operator s certificate service temporarily suspended certificate sales on 4 November 2011, when a DoS attack tool was found on the company s Web server during an audit. This data breach may have occurred as long as four years prior to its detection. According to current knowledge, the actual certificate systems were not compromised. 4

How certificates are used Users can use certificates to ascertain that an online service provider is who it claims to be. Certificates are also used for verifying the authenticity of software and identifying users. As such, they are issued by trusted certification authorities (CA). In most cases, certificates are formed into a hierarchy, in which the top-level root certificate is used for signing the certificates of sub-cas that, in turn, sign the certificates issued. The branches of the certificate tree are separate, and annulling one branch (i.e. sub-ca) and the certificates under it does not affect other branches. Website certificates include information such as the certified website s domain name, various information on the party to whom the certificate has been issued, the certificate s CA-specific serial number, period of validity, information on the CA s Certificate Revocation List (CRL) and the location of the certificate status check-up service (Online Certificate Status Protocol, OCSP), the certificate issuer, the public key, and the certificate s purposes of use. In addition to specific domain names, the object of a certificate may be a domain name sub-network, email address or software developer. A list of trusted root CAs is integrated into operating systems and, in some cases, browsers. Browsers treat website-specific certificates issued by these parties as trustworthy.. Certificates are used, for instance, in encrypted SSL/TLS data communication connections (HTTPS). If a website s certificate is not signed by a CA included on the list of trusted root CAs or by a certificate signed with such a CA, browsers alert users to this fact. What made the attacks possible? Every root certificate is suitable for use as the signatory of all websites; root certificates do not have a hierarchy. Even if the service provider has obtained the certificate from a certain CA, a certificate issued by any other trusted CA is considered the equivalent of the real certificate. The information security of the 5 most vulnerable CA is the deciding factor. Changes in certificates presented by a certain website are not generally monitored in browsers or in a centralised manner. The DigiNotar case was only detected due to a feature of the Google Chrome browser based on which only certain CAs are accepted as issuers of certificates for Google s own websites. Cases in which the top level of the hierarchy, i.e. the root CA, becomes unreliable have not been taken into account in the design of the hierarchy. For instance, the certificate revocation list functionality can only be used for annulling certificates issued by the root CA. In practice, registration authorities (RA) and certificate retailers and subcontractors participate in the issue of domain names alongside CAs, complicating the situation. No restrictions concerning which certificates CAs and subcontractors may release are in use, even though this would be possible based on the specifications. For instance, the unauthorised certificates related to the Comodo case, mentioned in the introduction, were released by a subcontractor. The objectives of the attackers Falsified certificates can be used to carry out a man-in-the-middle (MITM) attack, hijacking the connection between a service and its user. Falsified certificates can also be used for eg. phishing, by using a website created by the attacker to steal information, such as user IDs and passwords. An attack on Web service users can also be carried out by falsifying name service data, if part of the website in question is downloaded from a thirdparty website. Most websites download data of this kind as advertisements and user statistics services, such as the Google Analytics service (https://googleanalytics.com/), from third parties. In order to carry out a MitM attack, the network infrastructure or name server must be under the control of the attacker, or the attacker must be in the same local area network as the victim. Open WLAN

networks, for instance, offer many opportunities for carrying out MitM attacks. In both the Comodo and DigiNotar cases, there has been speculation that the issued certificates were used for monitoring the email of Iranian users. Challenges related to certificate systems Browsers root certificate stores currently include outdated root certificates, which use short keys and unsafe algorithms, and certificates with extremely long validity periods. Root certificates and High Security Modules (HSM), including CAs secret keys, that have been included on a list of trusted certificates are in commercial demand among CAs, since inclusion on these lists is difficult. Browser and OS producers have defined specific requirements for those CAs that wish to be included on the root CA lists. In accordance with these requirements, the security of systems used for creating certificates must be ensured through audits, for instance. However, this was ineffective in the case of DigiNotar. According to reports published in connection with the investigation of the system break-in, the company s security measures were clearly insufficient, even though the company had passed the auditing process. Most certificates used by websites are signed by around 20 CAs. The number of root certificates included in browsers and operating systems is many times that number. For instance, clearly local CAs, which the majority of users will likely never need, are included. So-called Extended Validation (EV) certificates have never achieved much popularity. According to CAs, EV certificates are especially secure, since the certificate applicant s entitlement to the certificate is ascertained with particular care in connection with issuance. However, users are largely unaware of the difference between EV and regular certificates. Exclusion of non-ev certificates is impossible in applications, and would make little sense with regard to the market situation. In practice, it 6 constitutes no more than a marketing method for more expensive certificates. DigiNotar and Comodo were also selling EV certificates. Thus, selling EV certificates does not guarantee that a particular CA s information security is in order. Understanding the use of X.509 certificates requires familiarisation with the technology, even in the case of experts. With regard to applications with a mass user base, such as browsers, clear implementation errors have been made concerning certificate handling. It has been necessary to repeat these errors in new applications and certificates, in order to ensure backward compatibility. In addition, certificates are stored in browser caches in order to speed up use of applications this may extend the use of annulled certificates. Recommendations for IT management departments Evaluate the root certificates required by users in your organisation. Do not include blindly all certificates enclosed with the OS and browsers. Only add the necessary certificates to systems requiring special protection. Send users certificate information on websites requiring special protection when the certificates change. Identify any insecure algorithms whose deletion from the list of accepted algorithms has been recommended. When obtaining certificates, assess the credibility of the CA. Purchasing the most inexpensive certificate may result in additional future expenditure. Significant costs are involved in reliably maintaining the information security of your own certificate system. Do not use certificates whose CA is not included among those trusted

in users systems. Renew certificates before their expiry. In this way, you will avoid habituating your users to disregarding messages on certificate errors. Give thought in advance to what action you will take, if the issuer of the certificates used on your websites is subject to a data breach and its root certificate is annulled. Recommendations for users Activate your browser s advanced security features. Do not disregard error notifications on certificates, without identifying the reason for the notification. Keep your operating system and browser up-to-date. Be alert and take note if you are redirected to an insecure website, for instance. Recommendations for application developers Applications should not function in such a manner that, in the event of a certificate verification failure, they continue as before without consulting the user. Familiarise yourself with the operating principles of certificates before creating your application. Ensure that certificate chains are verified up to the root CA. Pay special attention to checking the Basic Constraints extension in all certificates within the chain. Implement certificate revocation list functionalities. Strive for a good balance between information security and the certificate error notifications displayed to users. Pay special attention to ensuring that browser UIs present users with error statuses and observations related to certificates 7 in a clear manner. Try to prevent the possibility to deceive users due to browser vulnerabilities. In the case of many devices, users cannot modify the list of trusted root certificates. Knowledgeable users are not provided with the means to improve their information security. With regard to update mechanisms, the option of determining accepted CAs within the application should be considered. The purposes of use indicated on certificates must be observed. Development outlook Users trust the assessments of application producers and operating systems, as to whether certification service providers are safe. The deletion process for root certificates that are no longer trusted must be accelerated. It is advisable that browsers use the operating system s central certificate directory, in which event the user will only need to perform a single update. Users should be provided with tools enabling them to easily browse, compare and edit the root certificate list of the various applications and OS. Trust forms the basis of the entire certificate system. Thus, it is of paramount importance that CAs act responsibly in the event of a suspected data breach, while also actively providing information on attacks and their impact. This would ultimately reduce the financial losses suffered by companies. Comodo, which acted responsibly, has continued operating, whereas DigiNotar was declared bankrupt. An obligation to notify customers of data breaches would provide an incentive for improving security. An increase in the number of self-signed certificates would result in users becoming blasé about notifications of certificate errors. Large companies may have the resources to create their own certificates in a secure manner, while also ensuring that the organisation s root certificates

are added to the list of trusted CAs. Smaller actors seldom have the resources or expertise required to implement a certificate system taking sufficient account of information security issues. In the future, certificates will also be used more frequently for verifying the credibility of executable applications. In addition to the Vista and Windows 7 operating systems, verification is used in all smart phone platforms. This means that software producers must also focus on the information security of certificates used for signing applications. Signed malware has already been used in numerous attacks, including the widelypublicised Stuxnet case. Components searching systems for certificates and the related encryption keys have been found in data-stealing malware. There have also been cases of malware inserting malicious code into the existing programme code in developer systems. New information security features related to certificates will be introduced to browsers at least in the form of addons. Google has introduced new information security features related to certificates, for instance in its Chrome browser. This is putting pressure on other browser producers to do the same. SSL/TLS-encrypted websites are used increasingly with mobile devices. Updating mobile devices is much more cumbersome for the user than updating a computer. In addition, updates are not made available quickly enough. The most-frequently used SSL/TLS protocol version is TLS 1.0. Over recent years, there has been some speculation regarding its level of information security. Even secure certificates are unable to protect an insecure transfer protocol. Implementation of later versions of TLS will become unavoidable at some point, but implementing encryption libraries that support these new versions will require investments from both server and customer software makers. In response to certificate system problems, developers have presented various new information security solutions. Some of these do not yet have established names. More than one of these solutions is likely to be taken into use, since they do not protect users from the same threats. It is to be hoped that these solutions require no great expertise from users; rather, they should also protect so-called ordinary users. The risk here is that the solutions only add to the complexity of an already complex certificate system. Solutions based on name server data: DNS Certification Authority Authorization (CAA) name service record: adding root certificate IDs that may issue certificates to the web site to DNS data. Inclusion of the DNSSEC chain in the website certificate. DNS TLSA name service record: inclusion of the correct certificate ID for the website in the DNS data. Being based on name server data, the two latter solutions require the implementation of the DNS name service security extension DNSSEC. Close integration with DNSSEC certificates alone is not altogether unproblematic, since the power to decide which are trusted CAs is transferred from the service administrator and users to the issuer of domain names. Service-end solutions: HTTP Strict Transport Security (HSTS): a procedure in which a web service may inform the browser that only encrypted traffic to the website should be allowed. OCSP Pinning or Certificate Status Request: a procedure in which a web service checks the status of its own certificate, then returns it to the browser as part of the reply. Application-end solutions: Certificate pinning or domain pinning: only accepting certain CAs as the issuers of the certificate of a service. 8

Localization of root certificate lists: root certificate lists only include the most common root certificates frequently used in the area in question. Centralised solutions: Convergence: a technology developed by the SSL/TLS researcher Moxie Marlinspike, in which trusted parties, i.e. so-called notaries are queried about the reliability of certificates. Notaries can be freely established: system users decide which notaries they will trust. Meta CA: a meta CA, replacing the browser and OS producers root certificate lists, in which browser and OS producers could trust. Centralised certificate directory: certificate directories, implemented using various technologies, to which the certificate used by a web service could be compared. Google, Tor and EFF SSL Observatory, for instance. The functionalities of the different scenarios are compared in table 1. Situations in which the user terminal is infected with malware have been excluded from the scenarios. Other situations, in which the attacker can insert its own content into the SSL connection, through means such as the website s XSS vulnerability or web service hacking, have also been excluded. 9

Table 1. Protection provided by the existing and proposed security features in various situations. Technology Deceiving the CA by means of false information First-time visit to an HTTPSprotected website Second visit to a HTTPSprotected website Dowgrading HTTPS to HTTP Other man-inthemiddle attacks SSLencrypt ed phishin g website 1) Disclosure of certificate key pair to a third party Break-in to CA systems Malicious CA Notes Certificate Revocation Lists (CRL) No Yes Yes No No No Yes No No OSCP No Yes Yes No No No Yes No No EV certificates Yes No No No No No No No No DNS CAA RR a) Yes No No No No No No No No HSTS OSCP Pinning DNS TLSA RR a) No 2) DNSSEC chain in certificate a) Certificate pinning No No No Yes No No No No No Only implemented at this time in the Firefox browser No Yes Yes No Yes No Yes No No Re-use of replies is possible. Yes Yes No Yes Yes No 2) No 2) No 2) Some security guarantees will be transferred to DNSSEC. No 2) Yes Yes No Yes Yes No 2) No 2) No 2) Some security guarantees will be transferred to DNSSEC. No Yes Yes No Yes Yes No Yes No Non-scalable, used in browsers Windows Update, Google websites. Convergence No Yes Yes No Yes Yes No No Yes Meta CA a) longer need to maintain No Yes Yes No No Yes No Yes No Browser producers no lists. Centralised certificate directory No Yes Yes No Yes Yes No Yes Yes a) Not yet in use. 1) The website is trying to mislead the user by using an address that resembles the genuine website s address. 2) However, DNSSEC may help. 10

Information on the cases DigiNotar: http://www.cert.fi/tietoturvanyt/2011/08/ttn201108301049.html 30 August 2011 http://www.cert.fi/tietoturvanyt/2011/09/ttn201109060736.html 6 September 2011 http://www.cert.fi/tietoturvanyt/2011/09/ttn201109081615.html 8 September 2011 http://www.cert.fi/tietoturvanyt/2011/09/ttn201109141445.html 14 September 2011 Comodo: http://www.cert.fi/tietoturvanyt/2011/03/ttn201103241059.html 24 March 2011 Other documents related to the matter CA information security requirements: Mozilla: http://www.mozilla.org/projects/security/certs/policy/inclusionpolicy.html Microsoft: http://technet.microsoft.com/en-us/library/cc751157.aspx Apple: http://www.apple.com/certificateauthority/ca_program.html Opera: http://www.opera.com/docs/ca/ Cabforum s 'Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates' document: http://www.cabforum.org/baseline_requirements_draft_35.pdf The Dutch authorities have released information on the DigiNotar case: http://www.govcert.nl/english/service-provision/knowledge-andpublications/factsheets/factsheet-fraudulently-issued-security-certificatediscovered.html http://www.rijksoverheid.nl/onderwerpen/cybercrime/documenten-enpublicaties/rapporten/2011/09/05/fox-it-operation-black-tulip.html The Austrian CERT has drafted an assessment of the impact of the DigiNotar case in Austria: http://www.cert.at/static/downloads/specials/cert.at_report_diginotar_breach_publ ic.pdf https://vikina.ficora.fi/cert/draftit/varmennej%c3%a4rjestelm%c3%a4/tietoturvak atsaus-drafti?action=edit&editor=text Jarno Niemelä s presentation on the misuse of software signatures: http://www.f-secure.com/weblog/archives/jarno_niemela_its_signed.pdf 11