Last week, the lab identified a curious set of spammed malware; files signed with a valid Authenticode code signing certificate.
This is something we've seen before. But this case seemed odd because the contact information appeared very genuine. Usually a valid but malicious certificate uses clearly bogus or dubious details.
I searched for a company that matched the name and address in the certificate and found small consulting firm that provides services related to industrial process control and optimization.
I contacted the company and asked them whether they were aware that their code signing certificate had been stolen. The case became more interesting to me when they responded that they do not have any code signing certificates. In fact, they don't produce software — so they don't have anything to sign. Clearly someone else had obtained the certificate in their name; they had been victim of identity theft.
I investigated the case with the help of the victim and Comodo, the Certification Authority that had signed the fraudulent certificate. I discovered that the certificate had been requested in name of an actual employee and that Comodo had used both phone call verification as well as e-mail. The fraudster had access to the employee's e-mail and the phone call verification either ended up with wrong person, or there was some misunderstanding. So the phone check offered no prevention this case.
Comodo has revoked the fraudulent certificate and any files signed with that certificate will be blocked automatically.
Also during the investigation I learned that the compromised employee had received a phone call from Thawte, another CA company. Thawte asked if she requested a code signing certificate in the company's name, to which she had answered "no", and Thawte then aborted the certification process. So it seems that the malware authors tried multiple CAs until everything fell into place in gaming the application process.
This case gives cause for serious concern about the trustworthiness of code signing in general.
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. Mistakes will also happen in the future. It is very likely that we'll see more of these cases in which 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, and we have to accept the fact that that with current system, certificates are not 100% proof of a file's origin.
The current situation of a single entity being served by several certification authorities is not good from a security point of view. Certification Authorities should have similar process as with domain names where a single domain name, for example f-secure.com, can be hosted by only one registrar at a time.
Also, code signing or SSL certificates should be allowed to be signed by only one CA at the time.
So if someone would like to get certificate in name of F-Secure they would only be able to get that from the same CA where F-Secure currently gets its certificates, which has an existing business relationship with F-Secure, and thus any new certification requests would be verified from existing business contacts. For this to be possible, the CA would need to have a central information resource.
The current model of any CA being able to issue a certificate in any name is simply not ever going to be secure as there are way too many possibilities for scams and social engineering.
For those interested in hearing more about code signing abuse, I will be giving
a presentation at T2 Information security conference in October.
Signing off,
Jarno
On 25/08/10 At 12:46 PM
Google 
Facebook 
Twitter 
Myspace 
Linkedin 
Yahoo 
Digg 
Del.icoi.us 
Windows Live 
Furl 
Reddit 
Blogger 
Technorati 
Rain Concert 
