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
Stay Updated
Follow us to stay updated on all things McAfee and on top of the latest consumer and mobile security threats.
