Reverse Engineering Team Board

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)

rongchaua 03-12-2009 04:10 AM

.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

Kurapica 03-12-2009 05:58 AM

Thanks my friend...
nice paper

rongchaua 03-12-2009 06:46 AM

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.

rongchaua 03-12-2009 07:43 PM

GAC Verifier
 
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.

sirp 03-19-2009 04:10 AM

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

Kurapica 03-19-2009 07:34 AM

Nice tool rongchaua, thanks for coding.


All times are GMT -4. The time now is 04:44 PM.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.