Posts Tagged ‘Python’

http://extraexploit.blogspot.com/2010/01/iexplorer-0day-cve-2010-0249.html

Advertisements

This blog 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…

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
.NET-Sploit User Guide
Tool – NET-Sploit 1.0.zip
Source Code – .NET-Sploit 1.0