Windows DLL load hijacking

This blogging is to demonstrate DLL  Pre-loading/hijacking bug in Windows.
The basis of this exploit is the way in which Windows works and how it loads DLL files used by many applications, if an application calls a DLL without specifying an absolute path Windows will conduct a search for the DLL file in various set locations. This is being abused by computer criminals.

The Microsoft Security Response Center has written about the issue :

    "Loading dynamic libraries is basic behavior for Windows and other operating systems, and the design of some applications require the ability to load libraries from the current working directory. Hence, this issue cannot directly be addressed in Windows without breaking expected functionality. Instead, it requires developers to ensure they code secure library loads. However, we’re looking into ways to make it easier for developers to not make this mistake in the future.

    Microsoft is also conducting a thorough investigation into how this new vector may affect Microsoft products. As always, if we find this issue affects any of our products, we will address them appropriately."
   
Microsoft also has published some Registry tweaks which can change the default DLL library search behavior:
 http://support.microsoft.com/kb/2264107

Testing the Exploit:

Ok let us try to employ this exploit on "Media Player Classic".
Write a dll of your own. If don't know how to write a dll you can get it from the link below.

http://www.filefactory.com/file/b32433b/n/iacenc.rar
http://rapidshare.com/files/416173663/iacenc.rar

MD5: 886173D0BB985E7E8DF51E4CBAE242B6

I assume that you have Media player classic being installed in your machine.
Rename the dll as "iacenc.dll". Place it in a directory with any media file that can be played by Media player Classic.
Now open the media file and see the magic.

This exploit can be used by malware writers to spread their malware. So security professionals are expected to get  updated knowledge on this exploits. To check on what priority applications load a dll you can use Sysinternal's FileMon tool.

Gunpack - God's Unpacker

To protect malwares from detection by AV vendors malware authors use packers/cryptors for protection. For malware analysts unpacking executable is the greatest problem they encounter while analyzing protected executable files.
To combat packer challenges a memory dumping attack was employed in GUnpack tool.G(ods)Unpack tool unpacks packed executable files based on memory dumping technique.

Download page[Google code]

Autorun Cleaning tool

To clean autorun files on all the drives I have written a handy tool in Visual C.

Link1  [File Factory]
Link2 [YourFileLink]
Link3 [RapidShare]

Zipfile MD5 : BEEB5D98FBB1031F1046D801D61074DD
          SHA1: D841CD5F60448FA2E487FDED179CA5E05DF79DBB

Unzip the file and check checksum before using.

SHA1 : 9A83F85FB7BFE0D585BAE662A946D8025695D11D
MD5 :BD891972669DD82393F303DDA15BF2CE

+White Angel's foolish pages: How Wecorl trapped security giant MCAffee

+White Angel's foolish pages: How Wecorl trapped security giant MCAffee

Buster sandbox Released

A new sand boxing tool Buster sand box has been released.

The tools is available for free and can be downloaded at.
It has both automatic and manual analysis mode.

It even has digital signature detection option also.

It monitors file, Registry, Network changes etc.
It can be also made to work in hidden mode using a build in driver that comes with it.
It also has excluding list to exclude certain file and registry changes.
It needs sandboxie sandbox.

How Wecorl trapped security giant MCAffee

The recent false detection and deletion of svchost.exe(XP sp3) by MCAffee shocked every one who use MCAffee Anti virus. This article will try to reveal the dark side of this incident. False positives problem is a big head ache for AV companies. Even Anti virus titans are having this problem. The number of unique malwares are doubling every year. Every day AV companies are getting thousands of samples from various sources. In reality a malware analyst can analyze only tens of malware every day.

To analyze thousands of samples every day employing malware analysts and paying them is not even an imaginable thing for AV companies. But on many AV tests giving more than 90% detection rate is not possible with very few analysts. so finally many of them start to use a heuristic tool(program) which will scan the sample with major anti virus tools and based on other AV's detection it will directly add detection pattern(eg:CRC) for that sample with out being checked by a malware analyst.

w32/wecorl is a file patching worm that patches svchost.exe(other versions infect iexplore.exe, winlogon.exe etc) and spreads to other machines by exploiting the Microsoft Windows Server Service RPC Handling Remote Code Execution Vulnerability.

The thing to be considered here is that all the AV's are detecting wecorl as a worm. The patching logic of wecorl is not even on all the machines. It varies depending on the cavity(zero bytes) available in the file it is trying to patch. But the call to infected code lies near the entry point. So the detection pattern added by MCAfee for wecorl is too bad in this case.

To avoid this type of incidents every AV vendor should stop adding detection patterns for malware by considering other AV's detection. They should expand the strength of their research lab. Atleast analyzing every samples that they receive with sand-box would help them in avoiding this kind of incidents.

At last I want to refer the article by Magnus - "On the way to better testing" in viruslist.com is a good testing article . But this article has been criticized by most of the AV vendors.