cPanel Forums

MurdochNZ · #1 (**permalink**) 01-13-2008, 06:22 AM

My business runs a cPanel server, and we had a most odd problem this weekend. When you visited a particular site, a file would end up in Firefox's cache that AVG said was a "Virus Identified Exploit" but would not name the virus. I scanned the site files, a copy of the site made by WinHTTrack (it's powered by a CM) and found nothing. However, the boss did the same download and found a uleso.js, Google returns no results for this, and alas AVG deleted it. This is consistent with what I saw - sometimes the site would infect me, sometimes not. My downloaded copy lacked this file, his did not. Even more strange, he did a search for this file name on the downloaded site code and could not find a reference to it.

The site now seems clean. I'm really bewildered by the whole thing. Has anyone here encountered something like this before?

idealso · #2 (**permalink**) 01-13-2008, 01:45 PM

Does the site use ads from an adserver, or any other included external content?

MurdochNZ · #3 (**permalink**) 01-13-2008, 02:48 PM

No, not at all. Everything is on the server.

MurdochNZ · #4 (**permalink**) 01-13-2008, 06:17 PM

Update: I caught it in the act....

<body leftmargin="0" topmargin="0"><script language='JavaScript' type='text/javascript' src='pfatc.js'></script>

That JS line is not part of the original file. Alas the JS didn't end up in my cache cause it stalled in Firefox. The file was gone by the time I checked the FTP, and the reference itself is gone now too. Other sites on our server are affected.

cooldude7273 · #5 (**permalink**) 01-13-2008, 09:26 PM

run

Code:

clamscan -ri

ClamAV will scan your entire server and display all infections, consider running rkhunter too.

MurdochNZ · #6 (**permalink**) 01-13-2008, 11:36 PM

We don't have those installed. I'll see what I can do about getting them set up.

I have managed to isolate the script. It's full of escaped code that it unescapes then outputs with document.write. I'm trying to rewrite it to output those escaped parts as normal but my AV gets in the way, might try doing it in PHP.

n1zyy · #7 (**permalink**) 01-14-2008, 02:19 PM

This sounds exactly like something being discussed over on WebHostingTalk: http://www.webhostingtalk.com/showthread.php?t=651748

It's the same MO there -- five-character .js names being randomly inserted.

Not a ton seems to be known yet, but you're far from the first one to notice it.

Edit: The folks over on WHT are saying that RKHunter doesn't pick this up.

n1zyy · #8 (**permalink**) 01-14-2008, 02:24 PM

Quote:

Originally Posted by MurdochNZ

I have managed to isolate the script. It's full of escaped code that it unescapes then outputs with document.write. I'm trying to rewrite it to output those escaped parts as normal but my AV gets in the way, might try doing it in PHP.

I wrote a little PHP script to do it. First, a warning: don't view the output in your web browser!

When you view the output, it seems that there's still an encoded string inside. It looks like it's encoded differently, too. (Unicode?)

The following works:

grep unescape nmtpm.js >> escape.txt

(Substituting nmtpm.js for the name of whatever your JS file is.) This extracts just the unescape(... lines.

Then, parse the file with PHP like so:

<?php
$FILE = '/home/n1zyy/escape.txt';
$fh = fopen($FILE,'r');
$contents = fread($fh, filesize($FILE));
fclose($fh);

$array = explode('%', $contents);
echo "<pre>";
for($i=0; $i<sizeof($array); $i++) {
$x = $array[$i];
echo chr(hexdec($x));
}
?>

Again, don't view the output in your web browser! It's incomplete, so I didn't seem to have any problems, but don't risk it.

I recommend using wget to retrieve the PHP output, and then viewing it in vi or less or such. (If you do view it in a web browser, the page will be blank: it includes the JavaScript tags, so you have to view the source.)

ramprage · #9 (**permalink**) 01-15-2008, 11:40 AM

Not to dismay your script and effort but I believe this javascript injection is in real time through server memory. Therefor no actual pages that reside on the server are modified, just as your browser loads them up.

At least this is what I've seen for the vast majority of exploits like this, 1/5 actually modify the pages on the server. The others just modify the memory output. So you won't ever see .js if you view the source of the page from the servers shell console.

pjman · #10 (**permalink**) 01-15-2008, 03:43 PM

How are they getting onto the memory. Any idea what is the main avenue they are using for the exploit? I'm reading all over that everyone is scratching their head on this one, but it's only hitting Microsoft servers, not Linux. Any ideas?

ramprage · #11 (**permalink**) 01-15-2008, 07:14 PM

It's on Linux. I just looked at a cPanel server today with latest kernel that was infected. One way to tell if you have it is to login as root shell

mkdir 123

If You can't make directories with numeric values then you've been compromised. The box I looked at was CentOS 4.

That's about all that's known about it right now. Also that it's changing the port 80 output and doing injections in real time. From what others think it's not an Apache addon. Seems like some kind of 0 day kernel exploit they're using to spread crap on websites to infect Windows PCs.

cPanelTodd · #12 (**permalink**) 01-15-2008, 07:29 PM

This issue is indeed due to a compromise. The compromise is at the root level and a rootkit has been installed. This rootkit will attach to several syscalls within the kernel and begin serving malicious javascript to random web visitors.

This root compromise is not related to cPanel directly, as it has been reported on many different control panels on many different servers. The compromise is at the system level, and only Redhat 4, CentOS 4, and FC6 appear to be vulnerable at this time. We are actively researching this issue and will have an in-depth analysis of current information posted soon.

The easiest way to confirm the compromise is to attempt to make a directory with a numerical name. Run 'mkdir 1' or 'touch 2'. If this fails with an error similar to the errors below, then it's recommended to contact your datacenter, NOC or a qualified admin who can recover the system properly.

Code:

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

[root\@cpanel ~]# touch 2
touch: cannot touch `2': No such file or directory

cPanelTodd · #13 (**permalink**) 01-15-2008, 07:41 PM

More details can be found at http://www.cpanel.net/security/notes...s_toolkit.html

This page will continue to be updated as we find new information.

pjman · #14 (**permalink**) 01-15-2008, 07:55 PM

I'm seeing so much info on the web about this kind of compromise, it's got me freaked. I'll follow that thread daily.

Scott.Mc · #15 (**permalink**) 01-15-2008, 08:04 PM

As I mentioned on IRC the explanation is somewhat wrong on the cleanup because the original binary is not always there and you have no way to determine what is the original binary.

The creating directories/filenames with numbers issue is not a reliable way to determine, as this only works in newer variants. Another symptom is it preventing kernels related tools from being compiled (That includes mod-init-tools) it will invoke a panic when you attempt to compiling any such tools.

The most reliable way to determine is to check your sys_call_table , for the stock kernels you will need kernel-debuginfo.

Another is to check your outgoing packets,

Quote:

tcpdump -nAs 2048 src port 80 | grep "[a-zA-Z]\{5\}\.js'"

For older versions of tcpdump (Such as the ones provided with RHEL3/centOS3)

Quote:

tcpdump -XX -ns 2048 src port 80 | grep "[a-zA-Z]\{5\}\.js'"

The grsecurity fix people are mentioning does not remove this, it simply stops it from writing to /dev/mem (or /dev/kmem depending on what is available) however the second you boot out of this kernel you are likely to be vulnerable again.

The rootkit itself is rather simple in terms of how it actually functions, it uses common binaries as listed in the article (there’s another binary not listed from the older variants of this [that don't prevent the numbers at the start of file names/directories]). Replacing those binaries in the manner suggested is not the safest option and there is not always a copy, you should replace these from the binaries from your distribution. In the particular case it’s actually rather easy to do , simply remove the attributes to the files, remove the files themselves(not needed, but do it anyway) and then reinstalled the RPM’s (As this is always on an RPM based distribution) there’s only 3 rpm’s that are needed to be reinstalled.

Lastly, if you are not comfortable working with the kernel/debuggers then HIRE A QUALIFIED ADMINISTRATOR there’s plenty of them out there.

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode