Hello folks,

I'm new to this forum, but not terribly new to Linux.

I'm stumped trying to track down the origin of a security compromise on several of my Plesk servers.

We have found at least 5-10 web sites on several servers that have various foreign Perl scripts in their cgi-bin directory. The servers are all CentOS 4 or 5 running Plesk. The script says it's part of the Gootkit ddos system. Here's a snippit of one of the files:

===================
#!/usr/bin/perl

#part of the Gootkit ddos system
use Fcntl qw(:flock EFAULT);

use Socket;
use IO::Socket;
use IO::Select;

use POSIX 'setsid';
use Cwd 'abs_path';

print "Content-type: text/plain\n\n";

#---------------------------------------------------#
# CUSTOM parameters #
#---------------------------------------------------#
my $number_of_bots = 5;
my @defaults = ("camizio.net:80", "jumpbeat.net:80", "tagtags.net:80");
my $pingTimeout = 1200;
my $proxyPort = 5432;
#---------------------------------------------------#

===============

It appears that the file installs a cron job and executes every 1 minute and then tries to connect out to the world.

We block all "foreign" outbound traffic on odd ports, so they aren't getting anywhere with this, and it's easy to track down the files and remove them and clear the cron jobs.

BUT, what I can't track down is how they are loading these Perl scripts in to the user's cgi-bin.

Here's an example of ownership:

-rwxr-xr-x 1 customer_name psacln 62934 Mar 2 05:35 contusive.pl

"customer_name" is actually the client's correct FTP username.

Because of the correct ownership, it would appear that these files were uploaded with FTP. We changed all the FTP passwords for the compromised sites yesterday, removed all of the Perl scripts from the cgi-bin and removed all the cron jobs. We also disabled Perl and cgi capabilities for all users who don't need it.

Today, the nasty files are back in the cgi-bin directories!

We checked the ftp logs for the users, and the output of "last", and there are no records of any of those users logging in with FTP.

I thought that maybe there was a common thread with the type of web site the users have. BUT, some of the sites are simply default and/or empty. No nasty PHP elements or any common thread between customers or web sites that I can find.

I ran the chkrootkit tool and it came back with a few false positives, but nothing obvious as far as a root kit.

Any clues about how they are getting these files up to our client's web sites?

Thanks again for any help,

-Nick Voth

The most common cause of this type of compromise is a vulnerability in your web stack. It can either be from an outdated application, such as a content management system, or an improperly secured script. Often times they will make use of the /tmp directory as an initial point of entry as the permissions on it are looser, but this isn't always the case.

At this point you have two primary objectives: 1 - determine the intrusion vector, and 2 - determine the scope of the compromise, especially to determine if they have violated root. The Centos 4 machines are particularly concerning, because they stopped receiving full updates back in 2009 and stopped receiving even maintenance updates last month. One of the biggest things you can do to prevent intrusion is keep your system up to date and how diligent you have, or not, been in this regard is something to evaluate. This brings us to the starting point of the investigation:

You mentioned running Centos 4 or 5. What is the revision level and patch level of the problem system(s)?. How many system have been infected and if multiple, what is the common link between them (btw, how deep into your system were they able to penetrate?). What server applications, e.g. httpd, ssh, ftp, are your running and at what version and patch level? What content management and server management applications are you running, again at what revision and patch level?

Next, I would recommend the CERT Intruder Detection Checklist. While it is dated, it still contains a good outline of the steps that you should be going through. You should isolate the system and try to make as few changes as possible to avoid disturbing forensic evidence. This includes avoiding reboots. Unfortunately, your steps to eliminate the infection, such as modification to /etc/shadow, have probably disturbed a lot of the evidence. Once you have isolated the system, which you can do by either disconnecting the network cable or putting up a firewall to allow SSH connections from a single trusted source, you should look for hidden files, files with setuid and setguid, examine all of the cron jobs and also verify your system binaries against the RPM database. One thing you will need to determine is if the repeated modifications are coming from a local, but hidden script or process, or if there is an active connection.

You should make a very thorough examination of your log files, starting with some time before the suspected compromise, look for signs of intrusion as the process is usually noisy. Running your logs through Logwatch, on high detail may be helpful here.

A really good set of commands to run is the following:
This will create a big text file containing process information that will assist with looking for suspect applications. Before you run these commands, it is imperative that you verify that the files being used have not been compromised themselves.

Same situation here.
Plesk 9.5.4 + centos 5.4

yes, it is not uploaded through FTP for sure, I have changed the FTP passwd, but the files still got uploaded again yesterday.
Will do further checking and gives report here.
I suspect there are a security hole through script/javascript in the html code. will compare the affected sites and try to find any similiarity.

Have you seen:

http://forum.parallels.com/showthread.php?t=257628

AND

http://forum.parallels.com/showpost....3&postcount=33

Any of this common to you?

Folks,

Thanks very much for the input on this. It turned out to be a vulnerability in the Plesk control panel:

http://kb.parallels.com/en/113321

It's a serious pain, but we've managed to mitigate it by changing the admin password, the control panel passwords and FTP passwords for all compromised users.

Thanks,

-Nick Voth