Managed Code Rootkits Summary

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:

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