Regular readers of the Symantec blog may sometimes read blogs that mention a fraudulent file that is signed with a valid digital certificate or that an attacker signed their malware with a stolen digital certificate.

You may recall that the creators of Stuxnet, arguably the most notorious malware in history, signed it using the private keys of valid digital certificates of well-known companies.

Digital certificates are significant because a file with a digital certificate can be checked to see who authored it and to make sure it was not altered. Moreover, some versions of Windows display a dialog box when a file that has no digital signature is opened. If an attacker signs malware with the stolen private key from a digital certificate, Windows will execute the file in many cases, except if the file is downloaded from the Internet using a Web browser.

How does an attacker steal the private key from a digital certificate?

If a computer is infected by back door Trojan, the attacker may gain full access to the compromised computer and will be able to control it. The attacker will therefore be able to steal any information found on the computer.

An attacker can also steal both the private key and the digital certificate if he or she is interested in them. However, it is very hard for an attacker to check every compromised computer and if the attacker is successful in compromising several hundred computers, the task of checking every single one is made even harder. The more computers that are compromised, the harder the task becomes.

Gathered samples

I tracked malware samples that have functionality to steal both private keys and digital certificates from Windows certificate stores using the operating system’s functionality over a period of a month. During this time almost 800 unique sample files were gathered. The gathered samples consisted of some of the following malware:

• Backdoor.Beasty
• Infostealer.Snifula
• Downloader.Parshell
• Trojan.Spyeye
• W32.Cridex
• W32.Qakbot
• Infostealer.Shiz
• Trojan.Carberp
• Trojan.Zbot

Of those malware samples, many of them were Trojan.Zbot, also known as Zeus.

The following is a world map of all the gathered samples displaying infections by country:

Figure 1. World map displaying infections by country

As you can see, a large number of computers infected by the gathered malware appear to be in America.

How an attacker stores digital certificates

Windows stores digital certificates in a certificate store. Program code often uses the PFXExportCertStoreEx function to export certificate store information and save the information with a .pfx file extension (the actual file format it uses is PKCS#12).The PFXExportCertStoreEx function with the EXPORT_PRIVATE_KEYS option stores both digital certificates and the associated private keys, so the .pfx file is useful to the attacker.

The code shown in Figure 2 opens certificates stored using the CertOpenSystemStoreA function, so it chooses the most common system certificate store.

The PFXExportCertStoreEx function exports the content of the following certificate stores:

• MY: A certificate store that holds certificates with the associated private keys
• CA: Certificate authority certificates
• ROOT: Root certificates
• SPC: Software Publisher Certificates

In the example below, the MY certificate store information is saved with the password “Pass” in .pfx file format. As the PFXExportCertStoreEx function is called with the EXPORT_PRIVATE_KEYS option, it exports both digital certificates and the associated private key.

Figure 2. Example of code exporting certificate store information

The code performs the following actions:

1. Opens the MY certificate store
2. Allocates 3C245h bytes of memory
3. Calculates the actual data size
4. Frees the allocated memory
5. Allocates memory for the actual data size
6. The PFXExportCertStoreEx function writes data to the CRYPT_DATA_BLOB area that pPFX points to
7. Writes data

When it writes the content of the certificate store, there is no decryption routine; it just writes exactly what is in the certificate store.

Only one of the malware samples gathered waits for the attacker's command to steal certificate stores. The other malware samples all steal certificate store information when the computer starts running. This would therefore suggest that almost no attackers actually check the compromised computer before stealing the certificate stores.

What password does the attacker use?

In the preceding example (Figure 2), the attacker used “Pass” as the password when writing the certificate store data to a file. Other attackers were seen to use “Password”, “0”, “12345” and so on as the password. What about in the case of Trojan.Zbot?

Figure 3. An example of an encrypted password

The password is encrypted and is unreadable without decryption; the attacker encrypts data to hide it from antivirus vendors.

Figure 4. The _decrypt_password code

The code inside the red box in Figure 4 is the main decryption code. Although the code in the samples varies, all the samples have the same password: “pass.” The attacker obtains the private key from the .pfx file through a batch process and having the same password makes the task easier for the attacker.

The signing process is not difficult

Stuxnet is not a special case. We often see reports that an attacker signs malware using the private key from a stolen certificate.

Microsoft distributes a signing tool bundled with Windows DDK, Platform SDK, and Visual Studio. If an attacker can steal the content of the certificate store, the attacker can then run Sign Tool (signtool.exe) and digitally sign malware. If one knows where to look for the Trojan.Zbot source code, they can get it, configure it, and distribute it. Sign Tool can also be obtained by anyone; technical ability is irrelevant for stealing certificates.   

How can private keys be protected?

One way to protect private keys is to create a network for developing software that is completely segregated from the internal company network and to use different passwords for both networks. If malware compromises a computer on the company network, it cannot gain access to private keys. 

Developers should also only sign code by using the test certificate until they are ready to ship the software. If digital certificates are stored on a computer that is compromised by malware, the private keys may be stolen.

While storing private keys in a file on a computer is not recommended, there may be situations where it is unavoidable. If so, limit the number of computers that store private keys and restrict access to as few users as possible.

The private key and digital certificates should be kept in a secured location, such as a safe or locked room, and ideally on an encrypted device, like an IC card or a USB token (not a USB memory stick) or hardware security module (HSM). If that is not possible, digital certificates and private keys should be archived and protected by a strong password. Only when absolutely necessary should a private key be stored on portable media and it should eventually be removed from that media and stored offline.

Symantec also offers a service to protect private keys called Extended Validation (EV) Code Signing. More information on EV Code Signing can be found here. If you would like to learn more about security best practices for code signing, please see the white paper located here.

Symantec will continue to monitor the malware and malicious techniques outlined in this blog. We also recommend that users do not run suspicious programs and keep their operating system and antivirus software up to date.

Another Certificate Authority has been caught out having issued certificates that were being used to impersonate Google. Does the SSL padlock not mean we are safe anymore?

Digital certificates and certificate authorities have been much in the news recently. Attacks–such as those used by Stuxnet, Duqu, and other malware–involving stolen certificates show an increasingly worrisome new security trend.

Certificate authorities have been targeted several times in the recent past with some success. There is a large chunk of known malware signed by apparently legitimate companies that appear to have authored malware, adware, and/or potentially unwanted programs. As a matter of fact, a very significant percentage of recent malware executables (as high as 5 percent) purport to be, or are, signed with some sort of certificate. Even in the case of mobile malware, signed executables have appeared because issuers have failed to see the malware in the files before approving them. This attention to certificates by malware authors seems to validate that they are indeed the “keys to the kingdom.”

A few days ago, we first saw a new attack that turned out to be variants of the infamous ZeroAccess rootkit, launched by digitally signed installers and uninstallers. In the cases observed so far, the signed application is a valid program–such as the installer for recent Flash Player versions, as shown below.

As eager as vendors are to patch vulnerabilities, users are likewise eager to keep themselves protected. This gives the malware author an opportunity to prey on this (real or perceived) fear and, with that, the assumption by the user that whatever is signed must be trustworthy. The challenge for malware authors is how to supply victims with a legitimately signed, unmodified application that supports their nefarious purposes?

The answer lies in the imported DLLs (Dynamic Link Libraries) and their references. In 1998, the Lorez virus used a simple trick.[1] It infected the Kernel32.DLL module of Windows by copying it to the Windows folder from its usual known location. On startup, Windows would load this DLL instead of the original, clean file, because LoadLibrary() API first searches in the current directory for library files.

This attack got a lot of attention last year when it was newly “discovered,” and Microsoft issued a possible fix using a registry key.[2] This registry entry was supposed to control the operating system functions and prevent this behavior. One of the issues (in rare cases) with this fix is that it can potentially break the functionality of some applications.

In the past, it appears that the DLL preload method was targeted by early variants of this malware to allow installation with legitimate applications. Below we see what appears to be a fix implemented by a well-known browser to bypass illegitimate DLLs that have been placed in the same directory to take advantage of this condition.

In more recent variants we see that dummy functions have been added to the DLL that bypass this check:

Now, even more recent versions look to be taking aim at the trust model that certificates use.

Below we see how the ZeroAccess package may look in a designated folder on a test machine.

The actual malware file pretends to be msimg32.dll. Known variants of this module are detected by McAfee as ZeroAccess.dr. The Flash Player installer is indirectly referencing the “msimg32.dll” via its imports. See dependencies below:

When the user executes the installer, the malicious, mimicked DLL will load. This DLL preload issue is due to the system’s normally looking at the current directory for any DLL dependencies necessary for the executable. If it can find the module in the current directory, it will load it–moving to the defined path only as necessary. As we already stated, this is far from the first time anyone has seen this happen.

To a user, the reputation of the signed file looks correct, as most likely there are millions of users for it. However, when the two files get packaged together by the attackers, the ZeroAccess rootkit will be installed from the extra DLL. (This DLL is not signed in the variants we have observed so far.) Once executed, the installation begins, and code is injected into svchost.exe, which in turn will run ping.exe and inject extra code into it. So what we see is that a legitimate, trusted file is abused to allow behavior blocking and the bypassing of the personal firewall. ZeroAccess is now installed as a by-product of the trust placed in a signed application. Let us be clear: This issue lies not with any particular vendor, but with the usage of a signed executable that compromises the user’s trust in the signature itself.

ZeroAccess is known to be very difficult to remove from system. It has a variety of techniques to fight against antivirus and security products, and can do so generically. Previously, we discussed how the rootkit can generically kill AV and security products, using user mode APC calls from kernel mode.[3] This attack is very serious, and successful against most targets.

This version of ZeroAccess uses another neat trick to also generically target certain security products. Once ZeroAccess is loaded, it prevents the execution of several security products by mimicking a load error. Upon execution, the user will see an error message similar to this:

Several installers and uninstallers have been observed, with variants of ZeroAccess. Those that we are aware of can be cleaned with the free McAfee Labs tool RootkitRemover, which is available for download.[4]

Once RootkitRemover detects the threat, it will report a manner similar to what we see below, as it replaces known files with itself in the Windows drivers directory.

References

1. “Breaking the Lorez,” Peter Szor, Virus Bulletin, October 1998 (available at www.peterszor.com/lorez.pdf)
2. Microsoft Knowledgebase Article on DLL load control: http://support.microsoft.com/kb/2264107
3. “Asynchronous Harakiri++,” Peter Szor and Rachit Mathur, Virus Bulletin, October 2011
4. Free ZeroAccess removal tool from McAfee Labs, RootkitRemover, available at http://vil.nai.com/images/562354_4.zip

Mozilla has revoked the signing privileges of another certificate authority for issuing weak and incomplete SSL/TLS certificates.

DigiNotar, the Dutch certificate authority which hackers compromised and used to generate hundreds of bogus web security certificates, has filed for bankruptcy. Read more…

Microsoft has reissued a security update to remove DigiNotar’s certificates from Windows XP and Windows 2003 after a mistake in last week’s Patch Tuesday failed to remove most important certificates that were being abused. Read more…