Atomicorp

Posted: **Sun Mar 04, 2012 12:44 pm**

I've started seeing dozens of Perl scripts in my /var/www/vhosts/*/cgi-bin folders...

PROBLEM: They replicate, owned by the ftp user, and add themselves to users' CRONTAB entries.

I've search the internet; found I should change all FTP passwords, delete the offending Perl scripts, remove the CRONTAB entries...

But each day they keep coming back.

Has anyone seen this? I think it's called a GootKit.

I've attached a copy (note that it's never found on disk as "GootKit.pl", it replicates using random dictionary names).

Posted: **Sun Mar 04, 2012 2:49 pm**

ASL has signatures for this, you can run a malware scan of the system to see if its on the system with this command:

nice -n 20 clamscan --exclude-dir=^/sys --exclude-dir=^/dev --exclude-dir=^/proc --exclude-dir=^/var/lib/spamassassin --exclude-dir=^/var/asl --exclude-dir=^/usr/share/w3af --exclude-dir=^/var/lib/openvas/plugins -i -r /

Use "ionice" on the clamscan process if its too much work for your machine:

ionice -n <pid for clamscan> -c 3

Posted: **Mon Mar 05, 2012 5:40 am**

For those of us too poor to outfit a bunch of servers (truly,m I am) where are the root files placed and how do they reactivate even after being removed from the user cron? I have 6 servers being hosed.

Any help is always appreciated.

Posted: **Mon Mar 05, 2012 7:05 am**

I have been up since yesterday morning fighting the nasty gremlin. I managed to regain remote control of the network by turning off nearly everything in our Firebox Peak X8000 firewall. It allowed me to gain access to our hardware nodes that have Virtuozzo on them with two virtual servers. We have a total of 5 virtual servers belonging to one dedicated server customer affected.

This got me to thinking. Although I have managed switches that I didn't reconfigure when we made a data center change (my BAAADDD!) I got to wondering of a viable solution is to set in our case the eth0 speed to 10MB/s instead of 100 until I figure out the stinking password of the managed Dell 7424 switches. I have plenty of Cisco switches here, as well. In Virtuozzo the ethX actually becomes a venetX and isn't referenced as an actually NIC.

But when presented with such a nasty DDoS as this, is my thought viable? No server should be pulling more than 1MB/s 95% anyway.

Slightly off topic, yes and I apologize. It has been a tremendously long 24 hours.

Posted: **Mon Mar 05, 2012 10:42 am**

I had to do all of the following to get rid of the GootKit Perl Scripts:

1) stop all hosting (httpd daemons)
2) remove all cron jobs referencing them (run "crontab -u username -r -i" on each user until they're all gone)
3) remove all bad perl scripts from /var/www/vhosts/*/cgi-bin folders
4) remove all /tmp/apachectrl* files (and the "id" and "ua" files)
5) change all FTP logins/passwords for hacked domains
6) restart hosting

Posted: **Mon Mar 05, 2012 10:05 pm**

I found that by running

Code: Select all

chmod 000 /usr/bin/perl
chown nobody:nobody /usr/bin/perl
killall perl

at least me have my server back for a bit. Then I turn off CGI/Perl/Python for all domains from within th4e Plesk CP. I know that there's a CLI command that would do this but I don't know it yet

Posted: **Wed Mar 07, 2012 1:31 am**

This is hitting all of my Plesk 9 and 10 servers. Do we know how it gets on board and spawns? IP's maybe it is coming from? Cache URL or IP? Anything?

Posted: **Wed Mar 07, 2012 9:35 am**

My guess would be via the SQL injection exploit announced back in February

Posted: **Wed Mar 07, 2012 10:37 am**

If someone comes up with a true solution, let me know... no matter what I do, they're back today.

Posted: **Wed Mar 07, 2012 10:39 am**

I may have imagined it, but I think I saw a script linked to from one of the Parallels KBs related to the exploit which will reset all passwords. This is probably a good thing to do at this point.

You are unlikely to experience a huge tech support spike after doing so - not everybody updates their website or logs into the panel every day.

Posted: **Wed Mar 07, 2012 10:48 am**

We have sigs for it in ASL, make sure youve got the clamav support in proftpd. Those plesk micro-updates will kill it. When that happens you can fix it with: yum reinstall psa-proftpd

Posted: **Wed Mar 07, 2012 11:24 am**

Scott, thanks for the reply... I found that my clamd wasn't running... the ownership in /var/log/clamav was wrong (owned by user "clam" instead of "clamav") so I've fixed that, clamd is now running.

Also noticed that this was missing from /etc/proftpd.conf

<IfModule mod_clamav.c>
ClamAV on
ClamServer localhost
ClamMaxSize 20 Mb
</IfModule>

So I've added that as well.

BUT, WHEN I TRIED TO UPLOAD EICAR.COM, PROFTPD ALLOWED IT... : (

I don't think I have clamav in proftpd, even though I've run "yum reinstall psa-proftpd"

Posted: **Wed Mar 07, 2012 12:31 pm**

Did it re-install? Both the ASL and Atomic repos have that package. Also get rid of this:

<IfModule mod_clamav.c> <-

and
</IfModule> <-

Posted: **Wed Mar 07, 2012 12:49 pm**

(ok, removed it)

And yes, it reinstalled just fine, here's what I have:

psa-proftpd-1.3.4a-1.el5.art
psa-proftpd-mod_sftp-1.3.4a-1.el5.art
psa-proftpd-xinetd-1.3.4a-1.el5.art
clamav-0.97.3-1505.el5.art
clamav-db-0.97.3-1505.el5.art
clamd-0.97.3-1505.el5.art

I'm listing both my /etc/proftpd.conf and proftpd_sftp.conf below:

# ProFTPD configuration file /etc/proftpd.conf
ServerName "ProFTPD"
#ServerType standalone
ServerType inetd
DefaultServer on

<Global>
DefaultRoot ~ psacln
AllowOverwrite on
</Global>

DefaultTransferMode binary
UseFtpUsers on
TimesGMT off
SetEnv TZ :/etc/localtime

# Port 21 is the standard FTP port.
Port 21

# Umask 022 is a good standard umask to prevent new dirs and files
# from being group and world writable.
Umask 022

# To prevent DoS attacks, set the maximum number of child processes
# to 30. If you need to allow more than 30 concurrent connections
# at once, simply increase this value. Note that this ONLY works
# in standalone mode, in inetd mode you should use an inetd server
# that allows you to limit maximum number of processes per service
# (such as xinetd)
MaxInstances 30

#Following part of this config file were generate by PSA automatically
#Any changes in this part will be overwritten by next manipulation
#with Anonymous FTP feature in PSA control panel.

#Include directive should point to place where FTP Virtual Hosts configurations
#preserved

ScoreboardFile /var/run/proftpd/scoreboard

# Primary log file mest be outside of system logrotate province

TransferLog /usr/local/psa/var/log/xferlog

#Change default group for new files and directories in vhosts dir to psacln

<Directory /var/www/vhosts>
GroupOwner psacln
</Directory>

# Enable PAM authentication
AuthPAM on
AuthPAMConfig proftpd

IdentLookups off
UseReverseDNS off

AuthGroupFile /etc/group

Include /etc/proftpd.include
# EOF

And here's my proftpd_sftp.conf:

# /etc/proftpd_sftp.conf
ServerName "ProFTPD_sftp"
ServerType inetd
DefaultServer on

<Global>
DefaultRoot ~ psacln
AllowOverwrite on
</Global>

DefaultTransferMode binary
UseFtpUsers on
TimesGMT off
SetEnv TZ :/etc/localtime
Port 115
Umask 022
ScoreboardFile /var/run/proftpd/scoreboard
TransferLog /usr/local/psa/var/log/xferlog
<Directory /var/www/vhosts>
GroupOwner psacln
</Directory>
AuthPAM on
AuthPAMConfig proftpd
IdentLookups off
UseReverseDNS off
AuthGroupFile /etc/group
AllowStoreRestart on
AllowRetrieveRestart on

#####################################################################################
<IfModule mod_sftp.c>
SFTPEngine On
SFTPLog /var/log/proftpd_sftp.log
SFTPHostKey /etc/ssh/ssh_host_rsa_key
SFTPHostKey /etc/ssh/ssh_host_dsa_key
SFTPCompression delayed
MaxLoginAttempts 6
</IfModule>
#####################################################################################

Include /etc/proftpd.include

And my xinetd.d files (psa_ftp and sftp):

service ftp
{
disable = no
socket_type = stream
protocol = tcp
wait = no
user = root
instances = 199
server = /usr/sbin/in.proftpd
server_args = -c /etc/proftpd.conf
}

service sftp
{
disable = no
socket_type = stream
protocol = tcp
wait = no
user = root
instances = 99
server = /usr/sbin/in.proftpd
server_args = -c /etc/proftpd_sftp.conf
}

Posted: **Wed Mar 07, 2012 1:22 pm**

Oh, sorry, I realize now, you meant remove the IFMODULE lines (I removed all of them)

Ok, I put these back

ClamAV on
ClamLocalSocket /tmp/clamd.socket
ClamMaxSize 20 Mb

and immediately clamd went 100% CPU... I hope it calms down soon...

Atomicorp

GootKit

GootKit

Re: GootKit

Re: GootKit

Re: GootKit

Re: GootKit

Re: GootKit

Re: GootKit

Re: GootKit

Re: GootKit

Re: GootKit

Re: GootKit

Re: GootKit

Re: GootKit

Re: GootKit

Re: GootKit