Posts Tagged ‘rootkit’

1. Dont assume anything. Make some time to learn about securing your system.

2. Acquire and use a reliable antivirus program. Select an antivirus that has a consistent track record. Checkmark, and TuV are among the most respected independent testers of antivirus software.

3. Acquire and use a reliable firewall solution. Again, independent reviewers are your best bet for reasonable choices. Some operating systems come with a firewall which only filters incoming traffic. Use a firewall that can control both incoming and outgoing Internet traffic.

4. Do not open e-mails coming from unknown or distrusted sources. Many viruses spread via e-mail messages so please ask for a confirmation from the sender if you are in any doubt.

5. Do not open the attachments of messages with a suspicious or unexpected subject. If you want to open them, first save them to your hard disk and scan them with an updated antivirus program.

6. Delete any chain e-mails or unwanted messages. Do not forward them or reply to their senders. This kind of messages is considered spam, because it is undesired and unsolicited and it overloads the Internet traffic.

7. Avoid installing services and applications which are not needed in day-by-day operations in a desktop role, such as file transfer and file sharing servers, remote desktop servers and the like. Such programs are potential hazards, and should not be installed if not absolutely necessary.

8. Update your system and applications as often as possible. Some operating systems and applications can be set to update automatically. Make full use of this facility. Failure to patch your system often enough may leave it vulnerable to threats for which fixes already exist.

9. Do not copy any file if you don’t know or don’t trust its source. Check the source (provenance) of files you download and make sure that an antivirus program has already verified the files at their source.

10. Make backups of important personal files (correspondence, documents, pictures and such) on a regular basis. Store these copies on removable media such as CD or DVD. Keep your archive in a different location than the one your computer is in.

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
Source Code – .NET-Sploit 1.0