In March this year hackers managed to break into the computer systems of a company affiliated with Comodo, one of the leading distributors of the SSL certificates which enable websites to prove their authenticity. Fortunately the hackers were not able to complete their likely goal of setting up fake sites but the incident raised some unsettling questions about online trust and security in the 21st century.
Here, we’ll have a look at exactly what happened and what lessons can be learned to ensure that the internet’s authentication infrastructure is made more resilient in future. We’ll also discuss what individual internet users, certificate authorities (CAs) and firms can do to protect themselves from such threats.
What are SSL certificates?
The Secure Socket Layer (SSL) protocol was originally created to ensure secure transactions between web servers and browsers. Web sites which want to operate on the web need to request a certificate from a third party certificate authority (CA), such as Comodo. These certificates, which include the information of the web site owner and a cryptographic key, are issued by the CA and then used by the site to prove to a user’s browser that the site is authentic, meaning that user can then visit that site.
So what happened?
It appears that what happened in this incident is that a hacker managed to break into a Comodo affiliate, or registration authority (RA) in Italy, and used stolen user name and password credentials to request nine SSL certificates in seven different domains. The compromise was detected within hours and the certs revoked immediately, but they could have been used by the hacker to host fake phishing sites claiming to be original versions of sites like Yahoo or Google email log-in pages.
If hosted, they could have been used to harvest individual’s log-in credentials in order to monitor their communications, for example. The nine certificates in question were for the following domains: login.live.com, mail.google.com, www.google.com, login.yahoo.com, login.skype.com, addons.mozilla.org and Global Trustee.
How did Comodo respond?
Comodo explained that it responded quickly to the break-in, and revoked the certificates, meaning they couldn’t be effectively used. It also reassured that no hardware or any other part of the authentication and online trust chain was compromised.
In addition, Microsoft, Google and Mozilla all issued updates so users of their browsers would be notified if they tried to visit a site which was authenticated by one of the dodgy certs.
Panic over then, but the questions remain about the underlying system for authenticating web sites, as well as the security employed by Comodo and its partners which allowed the hacker to break in. How can we trust websites’ authenticity again?
Who was responsible?
Comodo was quick to brand the attack highly sophisticated and carried out by the Iranian authorities. The IP address of the initial attack came from an ISP in Iran, and one of the certificates deployed on another IP address was also assigned to an Iranian ISP, the firm revealed. It also discounted financially-motivated cyber criminals as the domains targeted were not those of banks or other potentially lucrative sites.
“It does not escape notice that the domains targeted would be of greatest use to a government attempting surveillance of internet use by dissident groups,” noted a post on Comodo blog site.
“The attack comes at a time when many countries in North Africa and the Gulf region are facing popular protests and many commentators have identified the Internet and in particular social networking sites as a major organising tool for the protests.”
Finally, Comodo noted that to actually make the fraudulent certificates work, the hacker would have had to be able to direct internet users to the fake sites rather than the legitimate ones, which would have required government level resources to control the DNS infrastructure over an extended period of time.
A lone hacker?
Soon after the Comodo response, a lone pro-Iranian hacker claiming to have carried out the attacks posted a lengthy explanation of how they achieved their goals. Although it is difficult to validate whether this person is who they say they are, the resources necessary to carry out the attack indicate that this individual is likely to at least have had some help from government. However, even if not directly state-sponsored, such attacks from so-called hacktivists [hacking for some goal other than financial self- interest] are no less dangerous, and internet users are right to be concerned about the security implications.
What can be done?
According to the self-styled ‘Comodo Hacker’, access to Comodo affiliate InstantSSL.it was easier than it should have been. Soon after hacking the firm’s web server the attacker was able to view a user name and password in plain text which they then used to access the relevant account and send the certificate signing requests to Comodo.
We don’t know for sure whether this is all true, but what we can say is that the hacker clearly targeted the registration authority because its systems were both less well protected than the CA, and also provided a way to enter into the certificate request process. Without more details it’s difficult to suggest explicit steps which should be taken to make the system more resilient.
However, this should be a wake-up call to all CAs and RAs to look carefully at their authentication systems and indeed the entire trust chain, to tighten up any avenues where hackers may be able to prize their way in. They can be sure that the cat is well and truly out of the bag now and hackers across the globe will be looking to emulate this break-in.
What should CAs do in future?
Comodo is doing the right thing by improving security around its RA accounts with the roll-out of hardware token-based two factor authentication and IP address restriction. These measures may well have locked out the attacker had they been implemented in the first place. However, the Comodo hack has in reality not told us anything we didn’t already know about the risks inherent in the SSL certificate system for verifying web sites.
The problem is the relationship between the certificate authority and the browser. Browsers are programmed to trust hundreds of CAs, but when the system is abused that trust can quickly break down, because all the sending and signing of certificates and cryptographic keys between web servers and browsers becomes irrelevant if those certs were fraudulently issued.
At the moment there are two systems to prevent SSL cert abuses, Certificate Revocation Lists (CRLs) and the Online Certificate Status Protocol (OCSP), but neither are ideal. CRLs are lists served up by the CAs every week or so of the certs they have revoked, which the browser can then check. However, these lists are large, unwieldy, hard to manage and require a lot of bandwidth.
OCSP is a more modern replacement for CRLs where the client queries the CA every time it sees a new certificate. However, this system expects the user to cache the results, and it also requires the user to announce to the CA what sites they want to visit, making privacy an issue. Both systems are problematic because if the CA is down it could result in the browser refusing all SSL certs or accepting anything that is signed.
While there are no clear alternatives to this system readily available, a start would be creating a smoother, more automated process to revoke fraudulent certificates of the type obtained by the Comodo hacker.
What can internet users do?
There is very little an end user can do in the face of such an attack which strikes at the heart of the trust relationship they hold with their favourite web sites. The only thing to be done is ensure you are patched and updated with the latest version of the browser. In the case of the Comodo hack it would have alerted if you were directed to a web page validated with a fake SSL certificate.
What can the web site owner do?
Aside from pressuring their certificate authority to improve authentication processes with their RAs and make revocation of fraudulent certificates a smoother and more automated process, web owners could think about engineering a plan B into their SSL cert set-up. Investing in a back-up set of certificates from a different CA could be a good move in case their primary authority suffers a major compromise.
Ultimately, this attack was pretty small scale and no one was really affected, but it should be a wake-up call for the entire industry. The SSL Certificate-based system is only as strong as its weakest link, and this Comodo incident has shown that there are plenty of weak links.