Security Laboratory

Security Laboratory


The Certificate Signing Trust Model Under Stress As An Industrial Security Model


By Stephen Northcutt
Certificate Signing Trust Model Stressed

The Certificate Signing Trust Model Under Stress As An Industrial Security Model

A common part of the security model for industrial IT applications is to never accept or run a program or driver that has not been signed by the appropriate publisher. However, while it appears to be strong protection against malicious code, in fact it is not. Microsoft uses a concept called Authenticode and encourages software publishers to sign their code. They only accept certain root certificates, for a list click here. If you take time to look at the list, you will see there are quite a large number of these root certificates. What is one of these is breached? Then it is possible to accept signed code that appears to be from a reputable vendor that is actually malicious. One of these root authorities on the list is Comodo. In March 2011, a hacker was able to post proof that he was able to produce 9 certificates via a Comodo Trusted Partner in Italy. A list of the fraudulent certificates can be found here, but they include Skype, Google, Yahoo, Mozilla and Live.com.

This is not a new problem. Back in March 2001, Microsoft Security Bulletin MS01-017 warned of fraudlent Microsoft certificates issued by Verisign. In 2003, ISS published a vulnerability report stating under certain conditions, Authenticode could be deceived and fail to prompt the user to accept the certificate allowing automated install. In the industrial world, we were shocked to learn that drivers used in Stuxnet, the attack against Siemens PLCs primarily in Iran, were signed, first by Realtek Semiconductor and then by JMicron. Qakbot, malware that is designed to attack financial systems, also managed to have a valid signature for several weeks. F-Secure researcher, Jarno Niemela published that several vendors working together have found 384,935 examples of signed malware, spyware, adware and similar. Further, if you have ever purchased shareware, there is a better than even chance you purchased it from Digital River; they found over 295 examples of rogue or malware signed by Digital River.

Obviously the current model is flawed and does not provide industrial systems much protection. So what can be done? One proposal is to create a DNS Certification Authority Authorization (CAA) Resource Record. This would allow an organization that had a domain name such as SANS.org to specify which certificate signing authorities were authorized to create certificates for that domain. If SANS specified Comodo as the root authority, a SANS.org certificate signed by Verisign would fail. This would reduce the risk caused by the fact that the number of authorities that are accepted as root by Microsoft Authenticode is very large, so the chance of one of them being compromised or not being careful is statistically significant. There is probably a lot more that needs to be done, but this could be an important first step.

Links were valid as of May 27, 2011
http://msdn.microsoft.com/en-us/library/ms537359%28v=vs.85%29.aspx
http://social.technet.microsoft.com/wiki/contents/articles/windows-root-certificate-program-members-list-all-cas.aspx
http://blogs.comodo.com/it-security/data-security/the-recent-ra-compromise/
http://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html
http://www.amug.org/~glguerin/opinion/revocation.html
http://news.cnet.com/2100-1001-254586.html
http://www.microsoft.com/technet/security/bulletin/ms01-017.mspx
http://xforce.iss.net/xforce/xfdb/13422
http://news.softpedia.com/news/New-Stuxnet-Related-Malware-Signed-Using-Certificate-from-JMicron-148213.shtml
http://www.symantec.com/security_response/writeup.jsp?docid=2009-050707-0639-99
http://www.f-secure.com/weblog/archives/Jarno_Niemela_its_signed.pdf
http://tools.ietf.org/id/draft-hallambaker-donotissue-02.html