A Certified Lack of Confidence: The Threat of Rogue Certificate Authorities

For more than a decade, computer generated digital certificates have made it possible to authenticate the identity of computer systems, data, and web sites by connecting a public key with an identity such as an owner’s name.  The process relies on trust.  “Secure” websites utilize such a certificate to validate their identity.  This digital certificate is usually procured from a company that will verify the identity of the company administrating the site.  The digital certificate issued to them will be validated by a trusted root certificate authority or by a server that is trusted by the trusted root.  This chain of certificates is called a certificate hierarchy.  A small group of trusted certificate authorities is installed on computers within the operating system.  These authorities include such names as Equifax, VeriSign, and Thawte.  So what happens when the system breaks down?

Last year a series of attacks took place against certificate authorities resulting in the issuance of many rogue certificates. These attacks began with an SQL injection attack against Comodo’s GlobalTrust and InstantSSL databases leading to the issuance of rogue certificates for addons.mozilla.org, login.skype.com, login.live.com, mail.google.com, google.com, and login.yahoo.com.  This was followed by an attack on DigiNotar where over 500 rogue certificates were issued including some wildcard certificates such as *.google.com which allowed the certificate to be used for any google.com site.  In response, DigiNotar was removed from the trusted list so that all the certificates it had issued were no longer valid.

Rogue certificates allow attackers to create illegitimate sites that are indistinguishable from real sites like eBay, Google or PNC because their certificate hierarchy can be validated.  Users then will be redirected to such sites through phishing or ‘”crucial  that man in the middle” attacks where a compromised host in-between the user and a legitimate site sends traffic to an illegitimate site instead.

Some viruses have used rogue certificates to make their content seem legitimate.  For example, fake AV, some Zeus variants, Conficker and more recently, Stuxnet and Duqu have used rogue certificates.  The threat of rogue certificates that McAfee lists rogue certificates as one of their ten threat predictions for 2012.

In the wake of attacks on certificate authorities, security professionals are speculating whether there are other certificate authorities that are compromised but do not yet know it.  The containment action against DigiNotar was extreme but necessary given the scope of the compromised certificates.  A significant disruption of e-commerce could result if other root certificate authorities need to be similarly revoked.

There are several ways companies can protect their users from the damage caused by the use of rogue certificates.  The most important action that can be taken is to install browser patches as soon as they are released because updates to root certificate authorities will be distributed through these patches.  To do this, revisit your patch management policy to determine optimal patch deployment intervals and minimize the number of time that machines are vulnerable to attacks.

Similar to server hardening and other security techniques that limit asset exposure, an examination and subsequent reduction of the number of trusted certificate authorities is important in assuring safe computer usage.  Some certificate authorities are region specific. Thus, they can be removed if sites in those countries are not utilized.

It is important to configure the Internet browser to check for certificate revocations.  Certificate revocation lists are maintained by certificate authorities who list the certificates that should not be trusted anymore.  Depending on the browser’s settings, it may be accepting revoked certificates.  Make sure the browser is set to treat certificates as invalid if the Online Certificate Status Protocol (OCSP) connection fails.

Firefox addons such as CertPatrol, Convergence or Perspectives routinely check certificates against a collection of network notaries or against a locally stored database of certificates to further validate certificate credibility.  These add-ons warn users when the certificates are different from those recorded elsewhere.  A change in a certificate is no guarantee that the certificate is a rogue certificate, but it is a warning sign that the certificate is potentially rogue.

Attacks in recent years have shown that the certificate trust relationship can be exploited to be used to impersonate legitimate sites and services.  The best way to assure actual service is to maintain current computer browser and operating system patches.  In addition to keeping patches current, reduce your potential exposure to rogue certificates by limiting the number of certificate authorities you trust and enforce certificate revocation checking.

 

 

Share Button

14 thoughts on “A Certified Lack of Confidence: The Threat of Rogue Certificate Authorities

  1. If one goes back and reads the actual documentation on X.509v3 the problem becomes clear. The certificate “subject” identity is established in the X.500 Directory, to support and verify the same subject attribute in the certificate issued by the CA. It would be pretty simple to determine that DigiNotar would not be authoritative for *.google.com, or in the case of the forged Comodo certificates earlier. Note there is a difference between a trusted certificate, falsely issued, or forged, and a stolen certificate.

    View Comment
    • Brett, Yes. Microsoft released a security advisory about it. See Microsoft Security Advisory (2718704)

      “Components of the Flame malware were signed with a certificate that chained up to the Microsoft Enforced Licensing Intermediate PCA certificate authority, and ultimately, to the Microsoft Root Authority. This code-signing certificate came by way of the Terminal Server Licensing Service that we operate to issue certificates to customers for ancillary PKI-based functions in their enterprise. Such a certificate could (without this update being applied) also allow attackers to sign code that validates as having been produced by Microsoft.”

      View Comment
  2. The entire system of trust needs to be reevaluated. Instead of just revoking a few certificates, they must be removed from the trust list of every browsers, thus revoking every certificate they ever issued.

    View Comment

Leave a Reply