TDL4 rootkit is coming back stronger than before

a1234567mdy 发表于 2011-12-22 08:53

<a href="http://www.prevx.com/blog/172/TDL-rootkit-is-coming-back-stronger-than-before.html" target="_blank">http://www.prevx.com/blog/172/TDL-rootkit-is-c</a><a href="http://www.prevx.com/blog/172/TDL-rootkit-is-coming-back-stronger-than-before.html" target="_blank">omin</a><a href="http://www.prevx.com/blog/172/TDL-rootkit-is-coming-back-stronger-than-before.html" target="_blank">g-back-stronger-than-before.html</a> 
(Blog post has been updated to add some technical informations)
After some months since the <a href="http://www.prevx.com/blog/164/TDL-exploits-Windows-Task-Scheduler-flaw.html" target="_blank">last
blog post</a> 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 <a href="http://www.prevx.com/blog/155/x-TDL-rootkit--follow-up.html" target="_blank">TDL4 which is
infecting the Master Boot Record</a>, patching in real time the Windows's Boot
Configuration Data and the kdcom.dll kernel debugging module. As already written
in the <a href="http://www.prevx.com/blog/154/TDL-rootkit-x-goes-in-the-wild.html" target="_blank">previous
blog post</a> 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.


<div align="center"><img src="http://pxnow.prevx.com/content/blog/ldr16_1_.jpg">
</div>
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.


<div align="center"><img src="http://pxnow.prevx.com/content/blog/ldr16_2.jpg">
</div>
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.

页: [1]

Chinaunix's Archiver

TDL4 rootkit is coming back stronger than before