Prevx Blog
(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.
In the last couple years there have been three major players who dominated the scene in the field of the kernel mode rootkit development. They are Rustock rootkit - with its latest build discovered in the wild in 2008 - MBR rootkit - firstly discovered in January 2007 - and TDL rootkit, which can be considered the most advanced kernel mode rootkit to date, able to infect both x86 and x64 versions of Windows operating system.
In mid 2009 another player quietly started targetting Windows and its kernel, slowly becoming more than "yet another rootkit". ZeroAccess rootkit, also known as Max++ rootkit, showed since its beginning a very good code development and interesting features, like exploiting the NTFS file system's feature called junction (a folder symbolic link actually) to create fake folders able to kill most security software when they tried to get access to such folders.
Since 2009 the rootkit evolved until the last release that strongly resembles the TDL3 rootkit in many features, like the implementation of a hidden volume where it stores its configuration data and other infection files. TDL3 creates an hidden drive by formatting last sectors of the hard drive with its own TDL file system and then encoding it using RC4 encryption. ZeroAccess instead creates a new file inside system32\config folder. This file will be mounted by the rootkit as a hidden volume, it'll be formatted using the NTFS filesystem and encrypted using RC4 encryption as well.
In both situations the system won't be able to directly access to the hidden volumes, so every file stored inside those volumes will be hidden from security software and from the operating system.
We have analyzed the rootkit dropper and published a video on YouTube that shows how to unpack it to better analyze the rootkit code.
The technical analysis of the rootkit can be downloaded from the link below:
Yesterday the long awaited fourth version of Mozilla Firefox was publicly released and the Mozilla download counter already hit more than six millions of downloads in less than 24 hours. Mozilla Firefox 4 arrived a bit later than the other major competitors - Microsoft and Google - who already updated their relative browsers a couple weeks ago.
Among the top three browsers, Firefox is the latest one that achieved the full compatibility to the HTML5 standard - even though at this time HTML5 could be considered all but a definitive standard. It features a new JavaScript engine called JägerMonkey, full hardware acceleration, crash protection feature implemented by keeping all the various browser plugins out of the main browser process and putting them in a separate process called plugin-container.exe, a brand new user interface and other interesting features.
The Firefox roadmap has been quite long, with the release of twelve beta builds and two release candidates. Today, Firefox is ready to fight against Chrome 10 and Internet Explorer 9 in the surfing performance, system performance, web page compatibility and user customization fields. Sadly, in the security field Firefox lacks of what in my opinion can be considered a really critical feature: a proactive security sandbox. By looking at the browser process architecture, it's easy to spot that Firefox inherited the old architecture of Firefox 3.x, without any major change.
We focused many times in our blog about the potential risk when surfing the web, the high chance to run into a fake or compromised webpage containing an exploit able to execute malicious code on the victim PC. Last, but not least, the 0day flaw discovered in Adobe Flash Player fixed a couple days ago by Adobe with a new update to the player.
One of the challenges in the security industry is preventing exploit codes from getting executed and mitigate them whether they are able to get executed. I usually like to think about this concept this way: the big challenge is the proactive prevention of exploit code from damaging the system, then I usually think about two sub levels in this field, a proactive step and a reactive step. In the proactive step I usually put all the techniques that try to prevent exploits from getting executed, like Data Execution Prevention, Address Space Layout Randomization, SafeSEH, GS cookie protection. In the reactive step I put technologies able to handle the potential executed exploit and mitigate it so that it can't harm the system.
We have seen many times how a misconfigured proactive layer together with a poor software coding style helped attackers to infect victim's PC with nasty malware. Even if the user is running in a limited account, banking trojans like SpyEye, old ZeuS, Carberp can still infect the system and steal sensitive data.
This is why during these years there has been a huge development of tools able to put the browser session in a sandbox, a monitored section which would be able to prevent potential malware dropped by exploit to get outside the limited sandbox.
Google has been the first company to implement a sandbox feature in its Google Chrome, a sandbox framework compatible with Windows 2000 to Windows 7. All the browser tab sessions are divided in separate processes, each one of these stripped of all user privileges and put in a limited job object. This effectively helps Chrome in protecting the user from possible exploits that could be run against Chrome or browser plugins like Adobe Flash Player.
Then Microsoft implemented a sandbox-like feature starting from Internet Explorer 7, by using the new User Account Control and Mandatory Integrity Control features included in Windows Vista and Windows 7. The browser starts in protected mode and every browser process is run at low integrity level. All browser extensions and ActiveX controls run inside the low-integrity process. All processes run at low integrity level have highly limited access to system resources, registry and disk locations. This means that a potential malware dropped by an exploit could still be executed, but it couldn't easily go too far in the system because of the highly reduced privileges.
What about Firefox? I expected to see something similar in this fourth release, though as far I can see nothing about it has been implemented by Mozilla. Firefox sets up the main browser process firefox.exe and another child process called plugin-container.exe, which will contain all the browser plugins. Both processes are executed at medium integrity level, with the privileges of the user who executed the browser session. This could result in a situation where a possible malware executed by an exploit would run with standard user privilege, not so good actually.
While I think the proactive step based on exploit prevention is important, I strongly consider the reactive step a critical feature that should be implemented as well, in a perspective of a multi layered protection system able to mitigate as much as possible a potential malware. Mozilla had a project called Electrolysis (also known as e10s) already scheduled, that should allow Firefox running separate processes to display browser's tabs. The sandbox feature looks scheduled inside this project, though the roadmap is still to be defined.
Moreover, Firefox 4 is compatible with Windows XP and this is a very good news. The problem is that, while Windows XP can take advantage of Data Execution Prevention (DEP), XP lacks the more important Address space layout randomization (ASLR) feature from later versions of Windows, which helps DEP work more effectively. This means that a sandbox would be really useful to protect customers against web exploits.
Sure, there are a huge number of Firefox extensions that could help the browser in mitigating exploit attacks, most notably the very effective NoScript extension. NoScript actively helps in preventing exploits from working because it acts as a script firewall, preventing scripts from unauthorized Web sites from loading. Though I must admit that it's hard to me thinking about the average Joe using NoScript extension.
I think that Firefox 4 is a great browser, totally able to compete with Internet Explorer 9 and Google Chrome. I would have like to have seen in Firefox 4 a sandbox-like approach like Chrome and Internet Explorer, that would definitely help users stay safe while surfing the web.
We have talked in the last blog post about how SpyEye trojan evolved during the time, illustrating some of its technical features and the encryption algorithm used by the trojan to decrypt the configuration file. Yesterday we have uploaded a new technical video that shows how to unpack this new variant of SpyEye in just few minutes with the help of a free debugger.
While SpyEye goes ahead and quickly becomes yet more widespread after the SpyEye-ZeuS joint-venture, we should focus on another threat which is silently raising its status in the ranking of the infostealing trojan family.
Carberp quietly appeared in Q3/Q4 2010 (even if some traces of its code could be found in the months before) and immediately showed great potential. It appears that the team behind this trojan has been very active as of late.
This trojan shows great potential and a modular architecture used to easily and quickly expand its features. All plugins downloaded from the C&C are encrypted with a custom encryption algorithm to evade from classic antivirus scanners. Its features include a module able to disable a list of antivirus software and an antivirus-like module that cleans the infected PC from other infostealing trojan families.
We have written an in depth analysis of the Carberp trojan, illustrating all the technical features of the malware. The paper can be downloaded from the link below:
