quote:

---

.NET Framework Rootkits - Backdoors inside your Framework
Author: Erez Metula;

Paper Description
=================

The paper introduces a new method that enables an attacker to change the .NET language, and to hide malicious code inside its core.
It covers various ways to develop rootkits for the .NET framework, so that every EXE/DLL that runs on a modified Framework will behave differently than what it's supposed to do. Code reviews will not detect backdoors installed inside the Framework since the payload is not in the code itself, but rather it is inside the Framework implementation. Writing Framework rootkits will enable the attacker to install a reverse shell inside the framework, to steal valuable information, to fixate encryption keys, disable security checks and to perform other nasty things as described in this paper.

Paper Summary
============

Framework modification can be achieved by tampering with a Framework DLL and "pushing" it back into the Framework.
The process is composed of several steps, described thoroughly at the corresponding whitepaper.
It also exposes a flaw in the manner in which a .NET Framework DLL is loaded, and how it is possible to bypass its signature mechanism.
Instead of re-signing tampered DLL's with a spoofed Microsoft signature key - surprisingly, it was found during this research that the modified DLL can be directly copied to the correct location at the file system, because the SN mechanism does not check the actual signature of a loaded DLL but blindly loads the DLL based on the directory name with the corresponding signature name!
It is important to mention that this technique does not requires "full trust" permissions, which further proves the fact that the GAC / CAS protection mechanisms are broken.

This paper also introduces ".Net-Sploit" - a new tool for building MSIL rootkits that will enable the user to inject preloaded/custom payload to the Framework core DLL.

You can find the detailed whitepaper, .NET-Sploit tool, source code, and the OWASP presentation at:
»www.applicationsecurity.co.il/.N···its.aspx

---

said by whitepaper :

---

Microsoft response team assigned the GAC protection bypass case the track number of "MSRC 8566gs", but even if the GAC bypass will be fixed it'll surely be possible to mount the attacks described in this paper in some other way, since an attacker who has administrator level privileges on a machine can do everything anyway.

Conclusions
Modification of the framework behavior can lead to some very interesting results as seen in this paper. An attacker who has managed to compromise your machine can backdoor your framework, leaving rootkits behind without any traces. Those rootkits can turn the framework upside down, letting the attacker do everything he wants while his malicious code is hidden deep inside the framework DLL’s. As the owner of the machine, there’s not much you can do about that. You can use external file tampering detectors, such as tripwire, in a scenario where you have another machine that monitors your machine. Microsoft, as the developer of the Framework, should give the .NET Framework a kernel level modification protection.

---

said by whitepaper :

---

It is important to mention that the technique described in this paper is considered as a post exploitation type attack! Such attacks are usually deployed after an attacker has managed to penetrate a system (using some other attack) and want to leave backdoors and rootkits behind, for further exploitation. In other words, changing the Framework requires administrator level privileges.

And, although it goes without saying - you must have administrator level permissions to overwrite the DLL, since this is a post exploitation attack…

---

And, as a side note – the methods described in this paper are not restricted only for the
.NET Framework, but can also be applied to other VM based platforms, such as Java.

Surprisingly, it was found during this research that the modified DLL can be directly
copied to the correct location at the file system, because the SN mechanism does not
check the actual signature of a loaded DLL but blindly loads the DLL based on
the directory name with the corresponding signature name!
It is important to mention that this technique does not requires "full trust"
permissions, which further proves the fact that the GAC / CAS protection
mechanisms are broken

said by Link Logger :

(CAS is actually kind of cool as you can white list what your app can do such that any exceptions are flagged, handy if your using a third party dll that you don't trust, so white list what it can do and anything else it does and CAS raises an exception and stops the app cold).

• select a White Listed .dll (ver.dll)

• modify a copy of ver.dll and place on a USB drive

• attempt to copy/overwrite ver.dll