Certified uncertainty

Just when we thought we understood what was happening with the Stuxnet rootkit the plot thickens. As I reported in my original story, the rootkit component and several other pieces were signed with a legitimate digital certificate from Realtek Semiconductor.

A lot of other researchers have covered this story, but I think some of the important details have been neglected or scattered about. First, the certificate that was used to sign the malware expired on June 11th. I will explain the significance of this later. Second, this particular component of the threat was signed on January 25th, 2010. This implies the perpetrators of this attack have been planning their strategy for quite some time.

There was a lot of fanfare on Saturday when Microsoft and Verisign announced that they had worked together with Realtek to revoke the certificate in question, implying that this somehow improved the safety and security of users. One of our researchers, Mike Wood, who will be presenting a paper this year at Virus Bulletin on the use of certificates by cybercriminals, helped me out by looking into the specifics of how Windows treats signed drivers and DLLs.

Mike came to two conclusions. One was that a driver signed with a certificate during its validity period will never expire. That the signing certificate is now expired is irrelevant because the rootkit was signed when the certificate was valid.

Second, Mike determined that the conclusion I had drawn in this week’s Sophos Security Chet Chat was incorrect. I thought that when the certificate was revoked this would prevent drivers that had been signed by it from loading into Windows. This is only partially true; it will only prevent drivers from loading that were signed after the certificate was revoked. This means all existing copies of Stuxnet that are in the wild will still happily load.

Why revoke the certificate at all? I have no clue. It accomplishes absolutely nothing as far as I can tell, except giving the appearance that the powers-that-be are taking actions to protect us. I contacted Verisign’s public relations department this afternoon for clarification, but I have yet to receive any response.

As if that weren’t enough drama, Eset blogged this morning about another variant of this malware that has been signed with another compromised legitimate certificate, belonging to JMicron Technology. The date of compilation is July 14th, the day before the world found out about the previous variant. In an interesting twist, it turns out that JMicron’s offices are in the same office park as Realtek Semiconductor.

Sophos detects this alternative version as Troj/Stuxnet-D as well as detecting malicious shortcuts as Troj/Cplink-A. We have created a central location for information about this vulnerability and the related threats. You can bookmark http://www.sophos.com/cplink for links to all the latest information.

Microsoft has updated their knowledgebase today to include an easy-to-use “Fix it” download that implements their mitigation advice. This download will disable the rendering of icons to ensure your copy of Windows will not be infected. Before you use this fix I recommend checking out the screenshot I posted yesterday showing the effect it has on a standard Windows 7 installation.