Recent events have highlighted that certification — and the lack of accountability in code signing and SSL certificates — have become a major issue.
Having an SSL certificate is a way for website owners to prove to their sites' visitors that they really are the genuine owners. Most Internet users and even major Internet companies implicitly trust the Certification Authorities (CAs). CAs sell SSL certificates for the encryption of web traffic, which enables secure transactions such as online banking and shopping across https connections.
However, the current certification system dates from the 1990s and has not scaled well to the sheer size and complexity of the Internet today. In addition to the major certification companies such as Verisign, GoDaddy and Comodo, there are hundreds or even thousands of regional CAs that are basically resellers for the larger companies.
Comodo recently announced that a hacker had gained entry to its systems by obtaining the password and username of one of Comodo's Italian resellers. The hacker, who has since publicly claimed that he is from Iran, issued nine rogue certificates through the company. The certificates were issued for popular domains like google.com, yahoo.com and skype.com.
It just boggles the mind that a small reseller in Italy can issue a certificate for google.com in the first place. You would think that would trip some sanity check somewhere. It didn't.
What can you do with such a certificate? If you are a government and able to control Internet routing within your country, you can reroute all, say, Skype users to a fake https://login.skype.com address and collect their usernames and passwords, regardless of the SSL encryption seemingly in place. Or you can read their e-mail when they go to Yahoo, Gmail or Hotmail. Even most geeks wouldn't notice this was going on.
In August 2010 Jarno Niemel�, Senior Researcher at F-Secure, started investigating a case of identity theft also involving Comodo, after discovering a malware sample that was signed by a code signing certificate. He tracked down the company mentioned in the certificate, and found a small consulting firm.
Niemel� contacted the company and asked whether they were aware that their code signing certificate had been stolen. Their response was that *they did not have any code signing certificates*. In fact, they didn't even produce software and therefore had nothing to sign. Clearly someone else had obtained the certificate in their name; they had been a victim of corporate identity theft.
With the help of the victim and Comodo, Niemel� discovered that the certificate had been requested in the name of an actual employee and that Comodo had used both e-mail and phone call verification to check the identity of the applicant. Unfortunately, the fraudster had access to the employee's e-mail and Comodo's phone call verification had either ended up with the wrong person or had failed due to a misunderstanding.
In fact, the compromised employee had also received a phone call from Thawte, another CA company. When Thawte asked if she had requested a code signing certificate in the company's name, she answered "No". Thawte then aborted the certification process.
This case shows that the malware authors will try multiple CAs until they find a way in.
When scammers have access to a company's e-mail, it is very difficult for a CA to verify whether the request coming from the company is genuine. It is likely that we will see more cases where an innocent company with a good reputation is used as a proxy for malware authors to get their hands on valid certificates.
Certification Authorities already have measures to pass information about suspicious certification attempts, and other kinds of system abuse. However, these systems are maintained by humans and are thus fallible. We have to accept the fact that with the current systems, certificates are not fool proof.
