“Who’s your Verisign?” — Malware faking digital signatures

Troj/BHO-QP is a rogue Browser Helper Object (BHO) which masquerades as a Flash Player extension from Microsoft, when in fact the BHO is a backdoor agent installed alongside QQ game automation freeware.

The BHO has been seen installed as a file named directdbres.dll. The DLL spoofs Microsoft product information and is registered as “FlashPlayer.Class” component — forging the fields displayed in the “Manage Add-ons” window of Internet Explorer options. Even more devious is the tactic to install a rogue “VeriSign Class 3 Code Signing 2009 CA” certificate as a Trusted Root Certificate Authority, which allows the BHO to avoid the taboo of being declared “Not verified”. To make their DLL appear “trusted”, the malware authors have simply (a) generated a rogue Verisign certificate, (b) used the rogue Verisign certificate to issue another rogue certificate, for Microsoft this time, and (c) signed the DLL using the key for the fake Microsoft certificate. Installing their fake Verisign certificate on a victim’s computer is the final piece of the puzzle to ensure their malware appears to be a genuine Microsoft product.

Also notice how management of the BHO is restricted to administrators only (i.e. “This add-on is managed by your administrator” in the bottom left corner of the image) . The dropper sets the Group Policy registry entry HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Ext\CLSID\{<clsid of the BHO>} to 1 to ensure the add-on is enabled, but unmanagable from the browser interface (see “How to manage Internet Explorer add-ons in Windows XP Service Pack 2”).

So how do you distinguish the rogue Verisign certificate from the legitimate one?

The fact that a root certificate is installed by the same software it is supposed to verify should immediately raise suspicion. Tools like Sysinternals sigcheck can be useful, but only if run from a clean machine — once the rogue certificate is installed on the system, they won’t be able to help.

There are several details about the certificate itself that strongly indicate its illegitimacy. Examining the openssl x509 output for the rogue certificate reveals:

1. the rogue Subject is only identified by a Common Name (CN)
   Subject: CN=VeriSign Class 3 Code Signing 2009 CA
   while the genuine Verisign certificate has additional fields including Organization (O), Organizational Unit (OU), Country (C), etc.
2. the rogue certificate is its own Issuer
   Issuer: CN=VeriSign Class 3 Code Signing 2009 CA
   while the genuine Verisign certificate has “Class 3 Public Primary Certification Authority – G2”
3. the rogue certificate is version 3 but is missing many typical x509 v3 extensions, and especially lacks any reference to a certificate revocation mechanism, such as a CRL or OCSP provider
4. the rogue’s signature algorithm hash is MD5
   Signature Algorithm: md5WithRSAEncryption
   while the genuine certificate uses sha1WithRSAEncryption
5. the rogue’s validity period is similar to that of a root Certificate Authority (CA) certificate
   Validity
Not Before: Sep 30 16:00:00 1999 GMT
Not After : Jul 16 16:00:00 2036 GMT
   A root CA certificate is only intended for issuing other intermediate CA certificates and is not typically used to issue certificates for other purposes. An intermediate CA certificate is then used to issue code signing and SSL certificates to an organization, which typically have a shorter lifespan. For instance, the genuine VeriSign Class 3 Code Signing 2009 CA certificate is valid for only 10 years.

But these certificate details could be spoofed just as well. To be certain of a certificate’s legitimacy (or illegitimacy), just go straight to the source and ensure the certificate fingerprints match.

The malware authors are certainly targeting a vulnerable audience — folks already looking to take shortcuts by automating their gameplay — who are probably even less likely to scrutinize the software they have downloaded to serve that purpose. But regardless of the would-be victims, this technique, in addition to the fraudulent SSL certificate abuse we have already seen, serves as another reminder that the mere pressence of a digital signature does not mean that something is legitimate.