WebApp Sec mailing list archives
RE: New Whitepaper - .NET Framework Rootkits: Backdoors inside your Framework
From: "Erez Metula" <erezmetula () 2bsecure co il>
Date: Fri, 14 Nov 2008 12:14:23 +0200
Hi Ragan, Performance seems to be the main cause for the lack of signature check (although the overhead penalty occurs once per loaded DLL). I also believe that Microsoft did some threat modeling and came to the right conclusion that since the checking mechanism is in the hands of the attacker anyway, and he is able to disable it regardless of how it works, it would be pointless to trust it like you mentioned. This is the reason why I believe that even if they do change the signature mechanism (which will probably be broken shortly) the idea of modifying .NET Framework DLL will last for a long time.. ☺ And it's also important to mention - I think the main issue is not the mechanism itself but the fact that now he know that attackers have another place to hide malicious code – it's not just the BIOS, Kernel, Drivers, etc. but also .NET Framework core DLL. Cheers, Erez. ________________________________________ From: Ragan, Rob R [mailto:rob.ragan () hp com] Sent: Thursday, November 13, 2008 10:18 PM To: Erez Metula; websecurity () webappsec org; webappsec () lists securityfocus com Subject: RE: New Whitepaper - .NET Framework Rootkits: Backdoors inside your Framework Nice presentation and paper. When a signed assembly is installed in the GAC, the system hashes the contents of the file containing the manifest and compares the hash with the digital signature embedded in the PE file, after unsigning it with the public key. It is interesting that the assembly isn’t part of the hash with framework DLLs. Perhaps this is the case for performance reasons. Is there too much overhead to check the signature of these files as they’re used so often? Let’s say performance isn’t an issue, would it be a pointless gesture to trust the checking mechanism on a machine that has been victimized by a rootkit? Modifying the framework in the way described does require admin privileges. By the way, Reflexil is a Reflector plug-in designed for easy modification of assemblies based on Mono.Cecil. http://www.mono-project.com/Cecil “With Cecil, you can load existing managed assemblies, browse all the contained types, modify them on the fly and save back to the disk the modified assembly.” I prefer it to a text editor. It might save a couple steps from the modify and recompile sections of your paper. Also it has a feature for removing strong naming. http://sebastien.lebreton.free.fr/reflexil/ http://www.codeproject.com/KB/msil/reflexil.aspx Enjoy, Rob Ragan HP Application Security Center 770.343.7050 Tel From: Erez Metula [mailto:erezmetula () 2bsecure co il] Sent: Thursday, November 13, 2008 10:39 AM To: websecurity () webappsec org; webappsec () lists securityfocus com Subject: [WEB SECURITY] New Whitepaper - .NET Framework Rootkits: Backdoors inside your Framework Paper Name ========= .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: http://www.applicationsecurity.co.il/.NET-Framework-Rootkits.aspx
Current thread:
- New Whitepaper - .NET Framework Rootkits: Backdoors inside your Framework Erez Metula (Nov 14)
- <Possible follow-ups>
- RE: New Whitepaper - .NET Framework Rootkits: Backdoors inside your Framework Erez Metula (Nov 14)