Malecious Random JavaScript Rootkit
(Adapted from http://www.cpanel.net/security/notes/random_js_toolkit.html )

Targeted Systems
A Linux server virus has recently been reported targeting multiple platforms such as: RedHat Enterprise, Centos v4.x/v5.x, and Fedora Core v5/v6. This Rootkit is not believed to be specific to any one control panel and/or Php application(s). Unfortunately, there are still many unknown details. We are actively researching the entry point to this exploit to pinpoint the methods used to gain access in order to stop this Rootkit from infecting servers in the future. It's a very time and energy consuming process as the primary Rootkit is designed to be hidden within the system which proves to be challenging even to Level I engineers.

Affected Binary Packages
It has been established that this Rootkit requires super user privileges. The initial entry point has not been confirmed yet. When a hacker gains shell access, the Rootkit is installed. Frequently-compromised binaries include:

/sbin/ifconfig
/sbin/fsck
/sbin/route
/bin/basename
/bin/cat
/bin/mount
/bin/touch

The Rootkit renames these system binary packages by adding a random set of characters at the end of the file name. Additionally, a 0 byte file with a different set of random characters is created based upon the target binary package's name.

For example:

/sbin/routewWmVTnBL6szkobbNZ9Iz
/sbin/routeGnAxnt168fMJAxHiru22

These files are hidden on the live filesystem of an affected system. In order to view these files, the system must be rebooted to a safe environment such as a system rescue CD.

How a Rootkit works

1. Once the Rootkit is successfully installed, the server will sit idle until rebooted. During a server reboot, the system initialization scripts will call the infected binaries.
2. When executed, the infected binary packages use /dev/mem as a pathway to the Kernel , and then attach to several system calls within the running Kernel. This results in hidden files, broken binary packages, and random JavaScript code being seen by web visitors.
3. When the system is fully online in an infected state, the Kernel will begin serving a JavaScript payload to random web requests/visits. This occurs outside of Apache and will not be seen in any of the Apache logs. The JavaScript injection will look like:
   

   <script language='JavaScript' type='text/JavaScript' src='cbolw.js'></script>

The JavaScript file is dynamically created and will have a random five character filename. This JavaScript will begin exploiting several known vulnerabilities within Windows, QuickTime and Yahoo Messenger on the web visitor's PC. Keep in mind that the JavaScript is not served on every request. It is injected into a small percentage of requests at random.

How do I know my server has been infected with this JS Rootkit ?

If you feel your server is being compromised, you can run the tests below to confirm.

The easiest test is to attempt to create a directory with a numerical name such as:

mkdir 123test

If your system returns the following error:

[root\@server ~]# mkdir 1
mkdir: cannot create directory `1': No such file or directory

Your system has been compromised.

This is not always true in older variants of a Rootkit . To make sure that your server is not compromised, run the following command for 3-5 minutes in order to sniff packets:

If your server is infected, the system will return the following result:

root@server log]# tcpdump -nAs 2048 src port 80 | grep "[a-zA-Z]\{5\}\.js'"
tcpdump: verbose output suppressed, use -v or -vv for full protocol

					 		 decode
listening on eth0, link-type EN10MB (Ethernet), capture size 2048 bytes


1311 packets captured
2627 packets received by filter
0 packets dropped by kernel

Additional detection methods require an in-depth knowledge of Kernel debugging.

 Solution
It is possible to remove this Rootkit by booting the server into a safe environment and moving the previous binary back in place. In this case, /sbin/routewWmVTnBL6szkobbNZ9Iz is the original binary. You can confirm this by looking at the size of the file. One will be 0 bytes and the other will be relatively significant in size. We suggest copying these binaries from a trusted and clean server.

Keep in mind that this is a root compromise. Until the point of entry is determined and closed, the server can continue to be compromised without proper security practices in place. We highly recommended that you do the following:

1. Contact your datacenter, NOC, or a qualified administrator to have the system fully checked and recovered.
2. Secure and harden your server.
3. Change any root passwords that have been previously used.
4. DO NOT give shell or jailshell access to ANYONE.
5. Update your server’s applications and services to the latest release, especially security patches and monitor the server closely for any unsuspected activity.

June 26th, 2008: Read the Latest findings about the Random JavaScript Rootkit

Click here if you wish to protect your server against IFrame JS code with "ServerTune IFrame Shield"

More information about Kernel Rootkits (To view this page, your browser must support in-line frames.)

Other articles in this Category

Understanding Attack Techniques

The Concept of Security

What Causes High Server Load?

Mod Security Rules and SPAM

Limit the resources for a specific user

Denial of Services (DoS) Detrimental to Businesses

Protect Your Company Against DDoS Attacks

Latest findings about the Random JavaScript Rootkit

RKhunter report: The command '/usr/bin/ldd' has been replaced by a script

Linux kernels v2.6.17+ vmsplice()Root Exploit

Horde v3.1.6 and earlier is NOT secure

IFRAME injection code :: infected Web sites and suggestions

Warning :: A new wave of domain scam/spam

Your client or your PC might be a zombie in a Botnet

HowTo :: scan and stop uploading infected files to your server