Be a real security pro - Keep your private keys private

One of the many unusual characteristics of the Stuxnet malware that was discovered in 2010 was that its files were distributed with a valid digital signature, created using authentication credentials that belonged to two unrelated legitimate software companies. Normally the signature would verify that the program was issued by the company listed in the signing certificate, and that the contents of the program had not been tampered with since it was signed. By using other companies’ authentication credentials to sign their own files, malware distributors are able to make it appear that their files have come from a more trustworthy source.

Since then, malware signed with poorly secured or stolen credentials has been relatively rare. Most digitally-signed malware uses code-signing certificates that have been paid for and obtained directly from the certification authority (CA) that issued them. These CAs would be unaware the certificates were intended to be used for nefarious purposes. For example, recently the fake antivirus family Rogue:Win32/FakePav reappeared after being inactive for more than a year. Prior to the period of inactivity, FakePav’s executables were not digitally signed, but the new variants have been. After a few days using a single certificate, FakePav switched to a different certificate, issued in the same name as the previous one, but by a different CA.

However, in the past month or so, the use of stolen certificates has become more common. In particular, Rogue:Win32/Winwebsec, another rogue calling itself Antivirus Security Pro, has been distributed signed with credentials stolen from at least twelve different software developers.

Figure 1: Antivirus Security Pro user interface

A related family, TrojanSpy:Win32/Ursnif, has also been distributed with files signed using stolen credentials. We have observed Winwebsec downloading Ursnif, a trojan that monitors web traffic, and steals sensitive information, including passwords. Earlier variants of Ursnif were also capable of stealing certificates and private keys, but this functionality does not appear to be present in the latest versions. Instead, it appears to have been added to certain samples of PWS:Win32/Fareit.

Figure 2: Fareit steals certificates

PWS:Win32/Fareit is a Trojan that mostly steals passwords from a user's FTP client, but sometimes also downloads and installs other malware, such as Winwebsec and Win32/Sirefef.

Figure 3: Relationship and interactions between Fareit, Sirefef, Winwebsec, and Ursnif families

The stolen certificates were issued by a number of different CAs to software developers in various locations around the world. The table below shows details of some of the certificates used to sign Winwebsec samples. Note that the number of samples column lists only the digitally-signed Winwebsec samples that we have a copy of – there may be many other samples that we have not received. But, it gives an idea of the magnitude of the problem. Interestingly, one of these certificates was issued only three days before we started seeing malware samples signed with it, which suggests that the malware’s distributors are regularly stealing new certificates, rather than using certificates from an older stockpile.

Figure 4: Certificates used to sign Rogue:Win32/Winwebsec samples

For those of you who are software developers, Microsoft has a document that describes the best practices for code-signing.  Although that document was written in 2007 and contains a few references to operating system tools that have since changed, all of the recommendations of appropriate security procedures for obtaining and storing code-signing certificates and private keys, and for digitally signing your software, remain as relevant as ever.

Just as it is important to keep your house and car keys secure, securing your code-signing private keys is essential. Not only is it inconvenient, and often expensive, to have the certificate replaced, it can also result in loss of your company’s reputation if it is used to sign malware. The document recommends keeping private keys physically secure by storing them on a securely-stored hardware device such as a smart card, USB token, or hardware security module. Certainly, no system used to store code-signing credentials should ever be used for web browsing, and it is vital that these systems run a regularly updated antivirus solution, and that any file you sign has been scanned for possible virus infection beforehand.

If a system you use for signing has been infected with Win32/Fareit or other malware, and you suspect your private keys have been compromised, you should contact the CA that issued the credentials immediately.

David Wood
MMPC

SHA1s:

d330699f28a295c42b7e3b4a127c79dfed3c34f1 (PWS:Win32/Fareit with certificate stealing capability)
006c4857c6004b0fcbb185660e6510e1feb0a7a3 (Digitally-signed Winwebsec)