分类： 网络与安全
2011-08-19 06:35:49
(Blog post has been updated to add some technical informations)
After some months since the last blog post about the TDL rootkit, we have to come back and write again about this nasty threat that is targetting both 32 bit and 64 bit versions of the Windows operating system, succesfully bypassing all the security countermeasures implemented in the 64 bit version of Windows that should prevent the loading of unsigned drivers and every kind of patch to the Windows kernel.
We wrote many times about this rootkit and its features until the last release called TDL4 which is infecting the Master Boot Record, patching in real time the Windows's Boot Configuration Data and the kdcom.dll kernel debugging module. As already written in the previous blog post about TDL4, this rootkit is able to bypass the Windows Driver Signing security enforcement by patching the Windows Boot Configuration Data and swapping the BcdLibraryBoolean_EmsEnabled value to the BcdOSLoaderBoolean_WinPEMode one.
This swap tells Windows to load itself in WinPE mode, thus disabling the driver signing checks and allowing unsigned drivers from being loaded in kernel mode. Winload.exe is the Windows executable responsible of loading the Windows kernel along with its needed libraries like hal.dll, kdcom.dll etc. When loading such modules, Winload.exe reads the Boot Configuration Data to understand whether it has to check their digital signatures or not - the BcdOSLoaderBoolean_WinPEMode flag (and a couple more flags). After Winload.exe loaded the Windows kernel, it forwards the system loading procedure to the kernel itself.
Here it is the behavior exploited by TDL4 until last April, a design flaw that allowed it to effectively overwrite kdcom.dll module with its own module used to load the rootkit driver and disable kernel debugging. Then, after the rootkit driver has been loaded, the rootkit prevents Windows from actually booting in WinPE mode.
Winload.exe, if executed in WinPE mode, would usually pass the /MININT parameter switch to the Windows kernel, telling it to effectively loads Windows in WinPE mode. To avoid this, the rootkit intercepts the /MININT string and changes it to IN/MINT. The Windows kernel doesn't recognize such string and loads Windows normally, with driver signing security feature enabled again.
This trick allowed TDL4 rootkit to succesfully infect x64 versions of Windows. Until this April, when Microsoft silently released the KB2506014 patch which is described by the company itself as follows: "Microsoft is announcing the availability of an update to winload.exe to address an issue in driver signing enforcement. While this is not an issue that would require a security update, this update addresses a method by which unsigned drivers could be loaded by winload.exe. This technique is often utilized by malware to stay resident on a system after the initial infection".
Microsoft patched Winload.exe behavior and kdcom.dll module. The first one is now checking the Windows kernel and its dependencies modules's code integrity and digital signature disregarding whether the system is being booted in WinPE mode or not. The second one has been patched to evade the TDL4 signature scan which was able to detect when kdcom.dll was being loaded by the system. TDL4 rootkit was checking kdcom.dll's PE export directory data size; if they were equal to 0xFA, then TDL4 assumed the file was kdcom.dll and began the infection routine. Microsoft patched kdcom.dll module and changed the export directory size to 0x110 to evade from TDL4 scan.
TDL4 authors didn't wait too long and just released an update to its TDL4 rootkit code, making a number of important changes that are able to bypass the patch issued by Microsoft and a number of TDL rootkit scanners available online. Looks like this new TDL4 dropper is still in development stage because there are some bugs in the dropper code.
This new release of TDL4 rootkit implements specific code to disable the driver signing security routine. As written before, since the last Microsoft patch Winload.exe is checking the digital signature of the kernel and its relative modules. If the integrity check doesn't succeed - i.e. with the patched rootkit's kdcom.dll - the security routine returns the status error C0000428, which is STATUS_INVALID_IMAGE_HASH. If the routine returns this error, winload.exe stops the system bootup and shows a security error.
To bypass this security check, the rootkit now intercepts these digital signature check routines and patches them so that instead of returning the NTSTATUS error C0000428, they'll return the NTSTATUS error 0000C428, which is a non-existant error code. Winload doesn't recognize such error and goes ahead with the system bootup, effectively loading an unsigned tampered module. The rootkit patches the behavior of Winload function I_CheckImageHashInCatalog, used to verify if the module hash matches the images in a specific Windows signed catalog.
During the bootup process, Winload loads the Windows kernel and its modules. To load each module, Winload calls its function BlImgLoadPEImageEx which then invokes the function ImgpLoadPEImage. Inside this last function Winload validates the module which is being loaded, by calling ImgpValidateImageHash function. The validation procedure checks if the file is digitally signed or whether its calculated hash is present in one of the digitally signed catalog files. These catalog files contain a list of files determined to be trusted, sorted by their file hash. To verify the digital signature, Winload calls the function MinCrypL_CheckSignedFile, to verify the module hash Winload calls the function MinCrypL_CheckImageHash. Inside this last function it's located the function which is going to be patched. MinCrypL_CheckImageHash walks a _LIST_ENTRY structure called g_CatalogList, where are listed all the system catalog files and each catalog file is inspected by a call to the function I_CheckImageHashInCatalog. I_CheckImageHashInCatalog is the function being patched by TDL4 rootkit so that it will never return the NTSTATUS error 0xC0000428; this will result in considering the malicious file being included in one of the signed catalog files, thus it'll pass the security check.
To intercept kdcom.dll load, TDL4 rootkit has been updated to the new kdcom's export directory size value 0x110, neutralizing the Microsoft patch.
To avoid being detected by some specific online public TDL4 rootkit scanners, the TDL4 team updated their miniport disk driver hook, changing how the rootkit devices are linked to the rootkit driver and the real hooked miniport driver. As we already know, TDL4 rootkit steals the driver object of the last miniport driver and hijacks the disk driver's DR0 device, attaching it to its own filtering device. By walking the rootkit driver's chain of devices, it was trivial to get a pointer to the real hooked miniport driver object. This geometric structure helped many tools in spotting the presence of the TDL rootkit active in the system. Current TDL4 release removes every reference to the hooked miniport driver object, bypassing many antirootkit TDL4 detection routines.
The team behind TDL4 rootkit is still alive and is working quietly to keep its creature up to date and always able to bypass all known security restrictions. Even if the rootkit development cycle drastically changed and slowed down since the TDL3 period - mostly because of a major change in the development team - who is handling the rootkit development is still trying to keep the malware alive and effective against security software. Sadly the first x64 compatible Windows kernel mode rootkit has not yet disappeared, it is coming back stronger than before.
