lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [day] [month] [year] [list]
Date: Thu, 13 Nov 2008 18:07:33 +0200
From: "Erez Metula" <erezmetula@...ecure.co.il>
To: <full-disclosure@...ts.grok.org.uk>, <websecurity@...appsec.org>,
	<webappsec@...urityfocus.com>, <dailydave@...ts.immunitysec.com>,
	<pen-test@...urityfocus.com>, <bugtraq@...urityfocus.com>
Subject: 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

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ