|
|
|
|
|
|
 |
|
Managed Code Rootkits
|
 |
|
|
 |
NOTE: this page is no longer being updated.
This page introduces application level rootkit attacks on managed code environments, enabling an attacker to change the language runtime implementation, and to hide malicious code inside its core.
Same concept can be applied to
• Java Virtual Machine (JVM)
• .NET Framework (CLR)
• PHP (Zend Engine)
• Flash Player / AIR - ActionScript Virtual Machine (AVM)
• Python
• Dalvik virtual machine (Google Android)
• SQLite virtual machine (VDBE)
• Perl virtual machine
• Etc…
For information on Java and .NET Rootkits please refer to:
Java & .NET were chosen as case studies, since their execution model similar to each other and to other platforms, and since they're used today by most new development projects.
What are Managed Code Rootkits (MCR)?
MCR are Application level rootkits, hidden inside the managed code environment libraries. Their target is the managed code runtime (the VM) providing services to the upper level applications. MCR main influence is on the upper level application, by controlling their execution code in single control point.
While traditional rootkits usually hide some information from the OS (Hiding their presence, hiding files, processes, registry keys, ports, etc…), MCR can do the same, but by hiding from the upper level applications. Another characteristics of MCR is that they can cause sophisticated logical behavior modification, as will described later on.
Code reviews will not detect backdoors installed inside the VM since the payload is not in the code itself, but rather it is inside the VM implementation. Writing MCR 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.
Since MCR's act as a part of the sandbox, they have access to low level, private methods. They can also change the virtual machine’s implementation. By performing direct modification of the library intermediate bytecode, the application cannot detect the presence of a rootkit. The modified sanbox “lies” to the application.
It is important to mention that there are Non evasive (“by design”) legitimate ways of tampering with the sandbox behavior:
• AOP - Aspect programming (dynamic weaving)
• Configuration modification
• Setting an alternative evil ClassLoader
• Loading a malicious agent “-javaagent:MyEvilAgent.jar” (Java)
• Library location tampering of “machine.config” (.NET)
MCR advantages to the attacker
• An ideal, overlooked place for malicious code hiding
• No (current) AV / IPS understands intermediate language bytecodes
• Same goes for forensics techniques
• Developers backdoors are hidden from code review audits
• Universal rootkit - rely on the VM’s generation of machine specific code for different platforms
• Large attack surface – VM’s are Installed/preinstalled on almost every machine
• High success rate - one deployment can control all applications
• Managed code becomes part of the OS (Example: .NET PowerShell cmdlet’s)
• Sophisticated attacks enabler
• Low level access to important methods
• Timing
• Object Oriented malware
Attack scenarios
MCR is not an exploit. It requires having admin level access to the machine, since messing with the sandbox usually requires admin privileges (due to ACL restriction).
• Scenario #1 - Attacker gains admin access to a machine by exploiting some vulnerability. Here we are talking about an alternative, post exploitation (housekeeping) attack vector for rooted machines.
• Scenario #2 – The “trusted insider” threat – trusted employee who abuses his admin privileges on the attacked machine. Here we’re talking about Developers, IT Admins, DBA’s, etc.
So the attacker somehow got access to the target machine.What’s next?
Attacker installs a MCR, capable of
• Hide processes
• Hide files
• Hide network connections
• Install a backdoor for future access to the system
• Manipulate sensitive application logic
Method Injection
Injecting a new method enables to extend the runtime environment with general purpose “malware API” implemented as new methods
• Used by payload code - Deploy once, use many times
• Parameter passing
Those functions can live “Side by side” with other methods - they can be injected separately or at once without interfering with each other. Now all the payload needs to do is call the requested injected method and supply the correct parameters.
Some examples:
• private void SendToUrl(string url, string data)
• private void ReverseShell(string ip, int port)
• private void HideFile (string fileName)
• private boolean InjectClass (Class maliciousClass)
• private Socket MitM (string victimURL, int port, string attackerURL)
• Public void KeyLogEventHandler (Event e)
Attacking the "Object" class
All classes automatically extend the class “Object” - they inherit its member variables & methods and by that they contain generic code recieved from Object.
Injecting a new method to “Object” class will influence ALL existing classes, so a rootkit can be injected to Object in order to take control of all the instantiated objects.
Example method: report current object variables to attacker
private void SendVariables(string attackerAddress)
Call for action
People should be aware of MCR. They should pay close attention to the status their application VM runtime code in order to prevent/detect modifications.
Knowing about MCR is relevat to everyone:
• AV/HIPS vendors – Block Runtime tampering attempts. Like you do while protecting the OS.
• Auditors/Testers – know about this malware hiding place
• Forensics – look for evidence inside the runtime VM. There's a new place you should check.
• IT - use File tampering detectors (external tripwire)
• Developers – your app is secure as the underlying runtime VM
• Vendors – Although it’s not a bulletproof solution - Raise the bar. It’s too low!
• End users – verify your Runtime libraries! Reinstall them if you're suspecting something
Related material
Brought to you by www.AppSec.co.il
|
|
 |
|
|
|
|
Announcements
|
|
|
|
|
| added - Saturday, February 28, 2009Managed Code Rootkits presentation at BlackHat USA Las Vegas 2009
"Managed Code Rootkits" will be presented at BlackHat USA 2009, Las Vegas , July 29 2009, Caesars Palace Las Vegas.
|
|
| added - Saturday, February 28, 2009Managed Code Rootkits presentation at DefCon 17 2009
Managed Code Rootkits will be presented at DefCon 17 2009 ,August 2nd 2009, Riviera Hotel Las Vegas.
|
|
| added - Saturday, February 28, 2009New release - .NET-Sploit 1.0
Added features to the new version of .NET-Sploit include:
-
pre injection ability
-
method replacement ability
-
new items
|
|
|
|
|
|
|
|
|
|
| DotNetNuke® is copyright 2002-2010 by DotNetNuke Corporation |
|