Broadband Tech > Security > Security > .NET Framework Rootkits

.NET Framework Rootkits

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

---

The 'exploit' starts with the modification of a framework dll (assembly) from outside the runtime using administrative privileges. I'd hardly call that a viable rootkit but ok, let's run with it.

Changes to an assembly can be detected with a signature check but the CLR used by the author is blindly loading Strong Name assemblies. This is not how I understood the runtime to function in a default configuration. Without an exception made by sn.exe or inserted directly into HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\StrongName\Verification\, any SN assembly will have its current file hash checked against the signed one as it is loaded. The author claims this verification is not occurring within the GAC. If so, call Microsoft for a bug fix.

Without this initial compromise the rest of the paper is useless. I'll wait for someone to explain why the CLR is not working as (I thought) it should.

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.

---

That is exactly my point as well. I refuse to participate in testing new and new incompatible frameworks on my computers. I understand that development with NET may be easier, but as a consumer - I'll better wait until it settles down to finally workable solution...
--
Keep it simple, it'll become complex by itself...

reply to SUMware
i agree with you, netfixer.. i hate having "NETFramework" installed, but my ati (video card) driver-package requires it..

as far as i know, hewlett-packard "printer" driver-packages also require "NETFramework"..

What if you will install driver only - does it require .NET too?

reply to redwolfe_98

reply to redwolfe_98
If in the printer package you have a folder with *.INI file along with set of other files (usually with *.dl_ extensions) you may install the driver directly. In this case you do not have to run any "setup" program from the package (and it will not install any .NET). That's the way I install my drivers.

reply to redwolfe_98

reply to SUMware
Well I'm not sure if I consider this much of a security problem -- I mean, replacing a .NET library with a malicious one with similar API calls but malicious payloads causing bad effects should NOT be a surprise.

That's like saying replacing Notepad with a reformatter causes you to lose data when clicking on a Notepad shortcut later on. You need to be priviledged in order to be able to tinker with the actual framework .dlls to begin with, at which point you can reign so much hell on the system that this is a moot point.
--
Ubuntu MOTU Developer and Forums Council

reply to redwolfe_98

reply to SUMware
As stated before:

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…

---

Right, exactly. And it's a shame people are suddenly using this to fear-monger the .NET framework as if somehow non-.NET native based runtimes are not affected by tampering in this manner?
--
Ubuntu MOTU Developer and Forums Council

reply to SUMware
This article is Snake Oil IMO

the attacker would have to have admin access to your machine, in other words, gotten past your firewall and cracked your password.

At this juncture, I don't care eif you have .Net installed or not, your owned regardless. Besides, why would they even both with a .Net rootkit anyways, when there are much easier methods of rootkitting a system?

this article is snakeoil for that reason. If someone gets admin access to your system, your owned no matter what you have installed. .Net is no more a security risk than any other runtime or compiler.