On April 12, 2011, KB2506014 was released to address a vulnerability affecting Windows Vista and later operating systems running on the AMD64 platform. Malware was exploiting the vulnerability to load unsigned drivers and stay resident in kernel mode.
Backdoor.Tidserv (a.k.a. TDL4) is one such threat that is patching operating systems’ loader files on-the-fly in order to ensure that its advanced rootkit capabilities work. As may be expected, Tidserv attempted to work around the KB2506014 patch, as noted in the following code snippets taken from the ldr16 entry of the threat’s encrypted file system:
Here, the hooked int13 (the 16-bit disk operations interrupt) attempts to identify the moment when the operating system loader reads the kdcom.dll file from disk, then identifies which version it reads (either x86 or x64) and replaces it with the corresponding rootkit loaders ldr32 and ldr64.
Further down, just after the /MININT parameter patch, the code was updated to also patch the STATUS_INVALID_IMAGE_HASH (0xc0000428) error code that was returned from winload.exe to an invalid value (0xc428). This is meant to throw off the digital signature enforcement for kdcom.dll.
But, let’s see how that works in real life, as well as what it takes to actually get infected. For those purposes we collected the latest Tidserv samples (released on 2011-05-03) and set up a Windows 7 SP1 x64 computer with default settings running on it. Even from the start, the threat kindly asks the user (through the user account control (UAC)) to allow it to run as an administrator:
Who would say “Yes” to an unsigned installer? Hopefully, not too many of us; however, if the user clicks “No,” the threat retries and another UAC window is displayed in the hope it will convince the user that there is no other way to continue. It takes an average of about 16 “No” clicks in order to actually stop the threat from asking to run with administrative privileges and hence prevent it from installing.
Once installed, the threat immediately reboots the computer in order to load itself into kernel memory, since it can only bypass the digital signatures enforcement at boot time—or at least that’s what would be expected.
Even with the unknown error reported, the system loader detected the on-the-fly changes made by the rootkit loader and therefore started the System Repair mode. However, it will not touch the infected MBR, since it only expects that files were affected.
The process repeats itself at reboot, since the infected MBR loads once again, only this time the repair process fails:
While the hooks placed during the MBR infection take precedence over the operating system loader, in theory the hook code can, on-the-fly, patch any protection the OS loader might employ. But, it seems it’s not the case here and the threat should undergo more changes before being able to bypass the driver signing policy.
The good news is that the threat is effectively prevented from running. The bad news is that the system is rendered unusable.
This brings back memories of the DOS era, when there were no hardware protection mechanisms in place. This resulted in a “fair” battle between malicious code and antivirus products, usually leading to victory for the one that had the privilege of being the first to the post.
From this point of view, for the time being, malware still has a fair chance because even the most modern operating systems still need to start up from good-old 16-bit mode. However, there is an end to that privilege—namely, by enforcing the requirement that only signed code will boot through the BIOS.