NET Framework Rootkits: Backdoors inside your Framework. Erez Metula, Application Security Department Manager, Security Software Engineer, 2BSecure [email protected]. April 17, 2009. Agenda. Introduction to .NET execution model Tampering with programming language implementation - PowerPoint PPT Presentation
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
NET Framework Rootkits: NET Framework Rootkits: Backdoors inside your Backdoors inside your
FrameworkFramework
Erez Metula,Erez Metula,Application Security Department Manager,Application Security Department Manager,
• Able to run several languages (c#, c++, vb.net, etc.)• Installed on almost every windows machine• Available on other OS (project mono) - linux , solaris, mac, etc..• Execution model similar to other platforms (such as java)
• High level code is compiled to MSIL (CIL)
• The CLR generates native code on the fly– JIT (Just-In-Time)
• Pseudo-assembly, Object “aware” intermediate language. Some instructions:– Add, mul, call, ret – Stloc – Store stack value into local variable– Ldstr - loads a string on the stack – Newobj, throw, catch
• All calls are stack-based• Also known an CIL
Is it possible to change a programming language?
• Example - Changing WriteLine(string s) implementation• Sample test application calling WriteLine
static void Main(string[] args)
{
Console.WriteLine("Hello (crazy) World!");
}
• Let’s make WriteLine(string s) to print every string twice
public void WriteLine ( string value ){ //Framework’s implementation of WriteLine()//low level code for printing //low level code for printing (duplicate)}
EXE User
public void WriteLine ( string value ){ //Framework’s implementation of WriteLine()//low level code for printing }
Hello (crazy) WorldHello (crazy) World
User interface
Why tampering the Framework?
• An ideal, overlooked place for code hiding
• Low level access to important methods
• Large attack surface / success rate– Pre-installed (windows server 2003 and above)– Recommended update
<AssemblyFunc><FileName> SendToUrl_generic.func </FileName><Location><![CDATA[} // end of class System.Object]]></Location><BeforeLocation>TRUE</BeforeLocation>
• Things you can do with it – API Hooking – Code manipulation– Resource hiding (file,process,port…)– Covert Channels / reverse shells– Proxy (bouncer)– Backdoors– Polymorphism attacks
Important places• Classes
– Class Security.Cryptography– Class Reflection.MemberInfo– Class Security.SecureString– Class TextReader
• Authenticate() is used by all applications performing authentication
• Send the credentials to the attacker:
Post injected
Original code (end of authenticate)
Modified code(post injection)
DEMO
Authentication backdoors
• Conditional authentication bypass– Example – if password is “MagicValue”– Backdooring .NET’s Authenticate() method
Reverse shell
• Call ReverseShell() from any method to create the connection
• Example – connect when Run() is called– To 192.168.50.129 , port 1234
Pre injection
Original code Modified code (pre injection)
Stealing connection strings
• SqlConnection::Open() is responsible for opening DB connection– “ConnectionString” variable contains the data– Open() is called, ConnectionString is initialized
• Send the connection string to the attackerpublic override void Open()
• CAS (Code Access Security) is responsible for runtime code authorizations
• Security logic manipulation– CodeAccessPermission::Demand()– FileIOPermission, RegistryPermission, etc.
• Applications will not behave according to CAS policy settings
• It seems like the app is restricted while it’s not
Things to consider when injecting
• Pre / Post consideration
• Places to inject your code
• Object Oriented and inheritance
• References to assemblies
• Stack size usually grows
• File size changes
• Removing traces with NGEN
Malware development scenarios
• Changing a language class libraries can lead to some very interesting attacks
• Deploy many types of malicious software– Backdoors– Rootkits– Viruses– Spyware– Worms– Etc..
Call for action
• AV vendors AV vendors – Block Framework tampering attempts• Microsoft Microsoft – Raise the bar. It’s too low!
– Code obfuscation– Kernel level protection
• ITIT - File tampering detectors (ex: tripwire)• Auditors/testersAuditors/testers – know about this malware hiding place• ForensicsForensics – look for evidence inside the Framework• DevelopersDevelopers – your app is secure as the underlying
framework• End usersEnd users – be aware of this kind of stuff!