Reverse Engineering Team Board - .NET Framework Rootkits

Reverse Engineering Team Board (http://www.reteam.org/board/index.php)

- .NET Reverse Engineering (http://www.reteam.org/board/forumdisplay.php?f=28)

- - .NET Framework Rootkits (http://www.reteam.org/board/showthread.php?t=1464)

.NET Framework Rootkits

An interesting paper in .Net Reverse

.NET Framework Rootkits:
Backdoors inside your
Framework
November, 2008
Erez Metula

Link download:
http://www.applicationsecurity.co.il...=161 &mid=555

The main idea:

Quote:

Upon request for this DLL from other executables running inside the framework, the
framework will search for the required DLL based on his version and signature. The
framework will not check for the actual signature but instead will rely on the signature
mentioned in the directory file name.
To put it in other words, the signature of the DLL itself is irrelevant, the only
thing that matters is the directory in which it is located.

Source:
http://www.applicationsecurity.co.il...=161 &mid=555

Tool:
http://www.applicationsecurity.co.il...=1 61&mid=555

Modul:
http://www.applicationsecurity.co.il...=1 61&mid=555

Thanks my friend...
nice paper

Hi Kurapica,
Test this research if you have time. I myself can not believe that it can be bypassed so easily. I will start to test in some next days.

More info about this bug

Quote:

Sometime later, when an application attempts to load your signed assembly:

1. The .NET assembly loader calculates the cryptographic digest of the current assembly contents. This is known as the run-time digest.
2. The loader extracts the stored compile-time digest and public key from the assembly.
3. The loader uses the public key to decrypt the compile-time digest.
4. The loader then compares the run-time digest with the decrypted compile-time digest to ensure they match. If not, then the assembly has been modified since you compiled it, and the assembly load fails.

This process is different when loading shared assemblies from the GAC. Because assemblies are verified when they are first installed into the GAC–and they cannot be modified while in the GAC–the .NET assembly loader does not verify an assembly when loading it from the GAC. This can improve the startup speed of your application if you load many shared assemblies.

I wrote a small tool called GAC Verifier to dectect this art of rootkit.

http://rongchaua.net/tools-mainmenu-36/129-gac-verifier

It will scan the GAC Folder and tell us which assembly was not exactly signed. These assembly can be modified to work for the rootkit.

Regards.
rca.

nice tool thx checkd my framework ,) thx god not rooooted ,)

Nice tool rongchaua, thanks for coding.