Are compromised certificates the root of all Evil?

I returned from holiday to find another attack vector has raised its ugly head. Reading the latest news, at least two hundred fraudulent SSL certificates (and oossibly over five hundred) have been issued from a trusted root certificate authority (CA). In this case, it appears that Diginotar, the Dutch trusted third party has been breached and spoof certificates for common domain names including google.com have been issued. This follows on from a breach at Comodo earlier in the year.

What are the implications of this? Well the Diginotar root certificates are included within the trusted root authority stores of all common browsers, meaning that the fraudulent certificates would have been trusted when creating a SSL connection. These can be used to create encrypted tunnels to spoof sites where sensitive information could be transmitted, or leading to potential Man in the Middleattacks.

There has been a scramble among the leading providers to remove the Diginotar certificates from trusted stores. Microsoft and The Mozilla Foundation have reacted quickly publishing security updates, and Google have also updated Chrome, by adding the issued certificates to a blacklist. No news yet on Safari.

What does this mean? Well it means the hackers are getting better and more sophisticated as the counter measures themselves have improved.

The certificate model used for e-commerce has always been one area of concern. Once a root certificate is added to the trusted root store, it is difficult to remove and the model of certificate revocations, based on a Certificate Revocation List (CRL) has always relied on end user intervention, even when it is available; consequently is rarely used. The better technology, Online Certificate Status Protocol (OCSP), which provides real-time validation of a certificate is available now in browsers, but not all, and not always by default. However in either case, if the breach wasn’t discovered, the certificates wouldn’t have been revoked, so the response from the CA would have been positive.

So for end-users it adds another level of confusion. Now, even if they connect to a site which apparently provides a trusted secure link, they must confirm that this trust hasn’t been established through a Diginotar root Certificate Authority – either by validating the certificate chain, ensuring that the relevant security updates have been installed or OCSP validation is enabled.

Once again the hackers have found a weak link – and Diginotar have some hard questions to answer. The initial report on the breach states that the hackers obtained full domain administrator rights to the domain where the CAs were located. The password for this account was described as “weak” and the compromise of this one password led to full access to the CA estate.

Malicious software has been discovered on the servers, which could have been picked up by Anti-Virus software – if only it had been installed. Not only that but the web server software was stated to be outdated and not patched.

In addition there appears to be no central secure logging server, meaning that local logs are likely to have been compromised. Although the Payment Card Industry Data Security Standard (PCI DSS) does get bad press occasionally for being prescriptive and dogmatic, if Diginotar had gone through a Level 1 Service Provider PCI DSS audit, each of those weaknesses should have been identified and resolved. For example:

• PCI DSS 8.5 requires that strong passwords are in place
• PCI DSS 6.1 requires a patching policy involving maintaining upto date software with installation of security patches
• PCI DSS 6.2 requires a process to identify new security vulnerabilities when they are discovered
• PCI DSS 5.1 requires anti-virus software on all systems commonly affected by software (including servers)
• PCI DSS 10.5 requires secure audit trails held centrally

I suspect I could go on finding controls which would have failed.

Looking at the current PCI DSS service provider lists there don’t appear to be any SSL certificate authority providers on the Visa Europe Service Provider list, and currently no requirement at this time. Since these SSL certificates are commonly used for e-commerce, perhaps Visa Europe and Mastercard should consider asking these companies to undergo such an audit to provide some level of confidence to the general user community.

Certainly all providers of root certificates which are added to trusted root stores should have undergone some form of security audit. If I was a provider of a root certificate I think I would be running a risk assessment and validating and increasing my security to an appropriate level. Being centre stage to the hacker community is never a comfortable place to be.