KB2506014 kills TDL4 on x64
[An interesting snippet from my colleagues Aleksander Matrosov and Eugene Rodionov - DH]
Not so long ago, Microsoft released a security patch addressing the way Windows x64 operating systems check integrity of the loaded modules. In our recent report (The Evolution of TDL4: Conquering x64) we described a method used by the TDL4 bootkit to load its malicious unsigned driver on 64-bit systems, even though those systems have an enforced kernel-mode code signing policy. The new security update is intended to fix the “feature” (vulnerability) in x64 OS's (Windows Vista and later) exploited by TDL4.
On unpatched systems there are three BCD (Boot Configuration Data) options that determine the way the OS checks integrity of the kernel-mode modules:
- BcdLibraryBoolean_DisableIntegrityCheck – instructs the system to disable kernel-mode code integrity checks (used for debugging purposes, for instance)
- BcdOSLoaderBoolean_WinPEMode – instructs the system to disable kernel-mode code integrity checks (switched on when OS is loaded in preinstallation mode) ¬ exploited by TDL4
- BcdLibraryBoolean_AllowPrereleaseSignatures – instruct the system to use special prerelease digital certificates to verify digital signatures of kernel-mode modules.
On a patched system only two of these are left: BcdLibraryBoolean_DisableIntegrityCheck and BcdLibraryBoolean_AllowPrereleaseSignatures. BcdOSLoaderBoolean_WinPEMode BCD option is no longer used in the initialization of code integrity policy. The routine BlImgQueryCodeIntegrityBootOptions in winload.exe returns the value that determines code integrity policy. In the figure below the patched BlImgQueryCodeIntegrityBootOptions routine is presented.
Here we notice that BcdOSLoaderBoolean_WinPEMode is no longer used (as it was in the unpatched routine) and therefore TDL4’s trick of substituting kdcom.dll won’t work.
There is one mode module patched in the security update: kdcom.dll. This reinforces the conjecture that the security update specifically addresses TDL4 infection. As we already know, TDL4 replaces the kdcom.dll library with its own malicious component at boot time. The bootkit identifies kdcom.dll by the size of its export directory (it is compared with 0xFA):
In the patched version of kdcom.dll, the size of the export directory has been changed. If we look into its export directory (figure below) we notice that an exported symbol KdReserved0 has been added which is not present in unpatched library.
This function is added with only one obvious purpose: to increase the size of the export directory and as a result prevent the TDL4 bootkit from replacing it.
The security update won’t necessarily help users who have already been infected with the bootkit as TDL4 blocks the Windows Update service on x86 machines. As a result, infected x86 machines won’t be able to download and install the patch automatically. On an x64 OS things are rather different and the Windows Update Service is not blocked by the bootkit, so the security update can be downloaded and installed.
Although the patch helps with this particular case it doesn’t solve the problem in general. There are other ways of penetrating into kernel-mode address space on x64 operating systems, for instance, as in the case of the Chinese bootkit which is detected as NSIS/TrojanClicker.Agent.BJ (VirusTotal). This uses quite a different approach to load its unsigned driver.
Eugene Rodionov, Malware Researcher
Aleksandr Matrosov, Senior Malware Researcher
5 Responses to “KB2506014 kills TDL4 on x64”
Leave a Reply
- David Harley (770)
- Randy Abrams (437)
- Cameron Camp (103)
- ESET Research (61)
- Pierre-Marc Bureau (50)
- Stephen Cobb (49)
- Aryeh Goretsky (30)
- Paul Laudanski (17)
- Andrew Lee (15)
- Jeff Debrosse (14)
- Robert Lipovsky (11)
- Sebastian Bortnik (9)
- Dan Clark (8)
- Sébastien Duquette (5)
- Tasneem Patanwala (3)
- Peter Stancik (2)
- Righard Zwienenberg (2)
- C. Nicholas Burnett (1)
- Andrea Kokavcova (1)
- David Carnevale (1)
RSS
June 7th, 2011 at 12:13 am
Hello.
I am member of an antimalware comunity and I use to help people to remove nasty infections through a forum support. I wish to ask you two things I ever wanted to know from a trusted source: is the malicious MBR code successfully removed by formatting the hard drive? And, the second one: in the event an user have two or more hard drives, will the bootkit install its MBR code in any of hard drives aleatory, or does it needs to be the one which loads the OS?
Thanks in advance.
June 17th, 2011 at 1:35 am
MariaCristina, I’ll take the last question first. I think it would be seriously odd for malware to modify an MBR at random, but it might try to modify every MBR it can find on a system.
I wouldn’t use anything with an /MBR parameter for generic malware removal: if a good security program detects it, the chances are it will remove it properly, and if there’s a problem, you should be able to get help from the vendor. If malware messes about with the MBR, there’s a chance that replacing it will cause direct damage. Aryeh Goretsky, who knows MS internals much better than I do and has the certs to prove it, says this:
‘I think FIXBOOT (for a disk volume’s boot sector) and FIXMBR (for the
master boot record of a hard disk’s partition) replaced “FDISK /MBR”
sometimein the XP timeframe. I’m thinking that if a disk was infected
by a bootkit, I’d probably wipe the first sector of the disk before
repartitioning it just to be sure. This can be done via the command
line DISKPART utility.’
‘Of course, that assumes a wipe of the disk. A “FIXMBR” is probably a
better approach if they want to keep anything that’s on it.’
HTH.
June 30th, 2011 at 3:46 pm
Hello, David. Thanks for your response.
About Aryeh Goretsky's words, I'll assume that even formatting the disk, the MBR must be rewritten to ensure that any piece of code has not be left behind.
October 15th, 2011 at 5:02 am
Would you please let me know of the exact command to use to wipe the first sectors of a disk.There are discrepancies in the begining and end sectors of my disk.I don't think it is a hardware problem because it is happening to more than just one pc and I can only find the "FIXMBR" and "FIXBOOT" commands when I search online. Both my notebooks appear to be still infected after wiping them with different utilities as if they are write protected. Thank you for your help and time.
October 15th, 2011 at 5:16 am
I’m afraid I wouldn’t feel comfortable answering that question without a lot more information, and we really can’t offer one-to-one support through this blog. Apart from anything else, the bloggers here aren’t support specialists. You may be able to get better help via the support tab on the main eset.com web page, but I think you need help identifying the problem. Wiping the first sectors without knowing what the problem is could actually make it worse.