Server Hack Help

powerdomein

Verified User
Joined
Dec 28, 2005
Messages
121
Dear guys,

One of my customer use opensoruce. And the site is just been hacked. The hacker place some perl script.. But i cant shut it down.. i have to high server load. I dont what to do.
We

Can anyone helpme . I have Fedora 3 server.

Apache Error log

Length: 31,254 [text/plain]

0K .......... .......... .......... 100% 89.02 KB/s

18:53:18 (89.02 KB/s) - `botek.txt.3' saved [31,254/31,254]

rm: too few arguments
Try `rm --help' for more information.
sh: line 1: botek.txt.1: command not found
--18:53:27-- http://www.aol.eu.com/botek.txt
=> `botek.txt.4'
Resolving www.aol.eu.com... 216.40.34.100
Connecting to www.aol.eu.com[216.40.34.100]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 31,254 [text/plain]

0K .......... .......... .......... 100% 89.05 KB/s

18:53:27 (89.05 KB/s) - `botek.txt.4' saved [31,254/31,254]

rm: too few arguments
Try `rm --help' for more information.
sh: line 1: botek.txt.1: command not found
[Wed Jul 12 18:56:02 2006] [notice] SIGHUP received. Attempting to restart
[Wed Jul 12 18:56:02 2006] [warn] module perl_module is already loaded, skipping
[Wed Jul 12 18:56:02 2006] [warn] NameVirtualHost 85.92.134.114:80 has no VirtualHosts
[Wed Jul 12 18:56:02 2006] [warn] NameVirtualHost 85.92.134.114:443 has no VirtualHosts
[Wed Jul 12 18:56:03 2006] [notice] Apache/1.3.36 (Unix) mod_ssl/2.8.27 OpenSSL/0.9.7a PHP/4.4.2 mod_perl/1.29 FrontPage/5.0.2.2510 configured -- resuming normal operations
[Wed Jul 12 18:56:03 2006] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Wed Jul 12 18:56:03 2006] [notice] Accept mutex: sysvsem (Default: sysvsem)
[Wed Jul 12 19:16:39 2006] [error] [client 211.206.245.207] File does not exist: /home/kaan/public_html/nl/mambots/content/mosthumb/mosthumb.js
[Wed Jul 12 19:18:26 2006] [error] [client 83.180.56.224] File does not exist: /home/kaan/public_html/nl/mambots/content/mosthumb/mosthumb.js
[Wed Jul 12 19:19:22 2006] [error] [client 83.180.56.224] File does not exist: /home/kaan/public_html/nl/mambots/content/mosthumb/mosthumb.js
[Wed Jul 12 19:20:00 2006] [error] [client 83.180.56.224] File does not exist: /home/kaan/public_html/nl/mambots/content/mosthumb/mosthumb.js
[Wed Jul 12 19:20:45 2006] [error] [client 83.180.56.224] File does not exist: /home/kaan/public_html/nl/mambots/content/mosthumb/mosthumb.js
[Wed Jul 12 19:26:22 2006] [error] [client 86.87.201.130] File does not exist: /home/kaan/public_html/nl/mambots/content/mosthumb/mosthumb.js
[Wed Jul 12 19:27:09 2006] [error] [client 86.87.201.130] File does not exist: /home/kaan/public_html/nl/mambots/content/mosthumb/mosthumb.js
[Wed Jul 12 19:27:15 2006] [error] [client 86.87.201.130] File does not exist: /home/kaan/public_html/nl/mambots/content/mosthumb/mosthumb.js
[Wed Jul 12 19:31:29 2006] [error] [client 83.180.56.224] File does not exist: /home/kaan/public_html/nl/mambots/content/mosthumb/mosthumb.js
[Wed Jul 12 19:37:44 2006] [error] [client 86.87.201.130] File does not exist: /home/kaan/public_html/nl/mambots/content/mosthumb/mosthumb.js
[Wed Jul 12 20:08:25 2006] [error] [client 72.30.133.209] File does not exist: /var/www/html/robots.txt
[Wed Jul 12 21:46:02 2006] [notice] caught SIGTERM, shutting down
[Wed Jul 12 21:46:05 2006] [warn] module perl_module is already loaded, skipping
[Wed Jul 12 21:46:06 2006] [warn] NameVirtualHost 85.92.134.114:80 has no VirtualHosts
[Wed Jul 12 21:46:06 2006] [warn] NameVirtualHost 85.92.134.114:443 has no VirtualHosts
[Wed Jul 12 21:46:07 2006] [notice] Apache/1.3.36 (Unix) mod_ssl/2.8.27 OpenSSL/0.9.7a PHP/4.4.2 mod_perl/1.29 FrontPage/5.0.2.2510 configured -- resuming normal operations
[Wed Jul 12 21:46:07 2006] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Wed Jul 12 21:46:07 2006] [notice] Accept mutex: sysvsem (Default: sysvsem)
Can't use an undefined value as a symbol reference at sq.txt line 1399.
[Wed Jul 12 23:08:26 2006] [error] [client 72.30.133.209] File does not exist: /var/www/html/robots.txt
 
this is an extreemly long time

Try this, Shut down the server keep it down for at least a week, now wile it is down you will need to access the hard drive, find the clients file and backup only his www dir. now scan the CGI-bin for the stupid thing and kill it. but keep it down for the rest of the week so if the hacker tryies to get in it will deny access and the prog hes using will delete your address. If this dont work i dont know what will:confused: :D :D :D
 
Shutdown the server for a week what for answer is that ???? what should the customers think of that.

Just install software like chkrootkit and other products and scan.
My advice is too reinstall the server when its infected..
And secure your /tmp ....
 
Hahaha, like we can shut down clients for a week :)

By the way, the problems are allready solved, without shutting down :) Thanx for the advice Jerry
 
if your server is really compromised, i would never trust it again. let's hope you have backups and do a reinstall.

if you would have looked at the search function of this forum, you would have found this thread:
http://directadmin.com/forum/showthread.php?postid=78874

If you don't know what to do after a hack, or in case there are "other" problems with your server, find a sysadmin who can help you with the daily maintenance of your server.
 
My advise is:

Protect your TMP directory noexec
Search for eggdrop and delete it
Search for crontab for apache en delete it
$ crontab -u apache -l

Remove files, who gives the possiblelity for hack.

Restart you server.

I was 5 hours busy to solute this problem.
 
Wow you have a major issue.

You are going to need to do a total system audit to find that hacker. I would bet he has bash shell running on it. You can clean it up if you know what you are doing, if not honestly the simple answer if you can get a new box up and running and start from scratch.

Once mambo has been comprimised in Linux you can change the attributes on the binary and install all kinds of nasty stuff.

Check the /tmp and see if you have any files owned my the wrong user. You can check the process tree to see if any scripts that should not be running are running:

ps auxf

While you are check verify that you don't have a ton of bogus connections, if you see a bunch to strange ports print them here:

netstat -nt

Get off of Fedora is a terrable OS for servers. If you are a kernel developer its great other wise it has to many holes. Get Red Hat ES or Cent or as I will always say FreeBSD.

Once you get this cleaned or server fixed you should force either yourself or you customers to subscript to the mailing list for the script's they run. This way they are aware of the latest versions.
 
We have the same issue on one of our FreeBSD 6.1 servers. The process list shows a process owned by apache, running klm (perl5.8.8)

After removing a certain .txt file (the first time it was called but.txt) the load dropped. But I, for the life of me, can't find where it's coming from.

The exploit is the so called Pitbull Bot, but I could only find 1 reference to it last night, which was an outdated link to that script. Here's the header:

Code:
#!/usr/bin/perl
# Pitbull Bot
#
# Coded by : The_PitBull
#
# Thanks to :
# Ex0d3us for the Scanner
# r0x00k  for testing and helping
#
# Greets to :
# ASC @ irc.ascnet.biz
#
# **** you to :
# W8ting4u
# Morgan
#
#You can use the following commands :
#!bot @portscan <ip>
#!bot @back <ip><port>
#!bot @udpflood <ip> <packet size> <time>
#!bot @tcpflood <ip> <port> <packet size> <time>
#!bot @httpflood <site> <time>
#!bot @linuxhelp
#!bot @multiscan <vuln> <dork>
#!bot @googlescan <vuln> <dork>
#!bot @system
#!bot @milw0rm
#!bot @join <#channel>
#!bot @part <#channel>
#!bot @help
#!bot cd tmp for example

Earlier in this thread I read that it might be a Joomla Simpleboard exploit, but there's no mention of it on Joomla's forums.

We've remounted all the /tmp directories as noexec, and hopefully this will prevent the exploit from being executed but I'd rather tackle the source; find the exploited site and fix it.

So any and all (helpful) comments are welcome.
 
We have located the offending website, but we can't yet find the exploit embedded. We did however manage to find the following line in the logfile:

88.242.214.209 - - [23/Sep/2007:03:40:14 +0200] "GET
/administrator/components/com_remository/admin.remository.php?mosConfig_absolute_path=SURPRESSED
HTTP/1.0" 404 - "-" "Mozilla/4.0 (compatible; MSIE 6.0b; Windows NT 5.0)"

The url leads to a file containing the following:
Code:
Defacing Tool 2.0 by r3v3ng4ns
[email protected]
se for modificar o codigo, por favor, mantenha o nome de seus autores originais
e por favor, entre em contato comigo...

ae galera, serio, tem mta gente fdp q simplismente usa, nao seja soh um sucker do script,
n seja um lammer imbecil, n seja o merda dum script kiddie, n seja um babaca, ajude a melhora-lo tambem!!

If anyone speaks portugese, I'd like a translation.

The rest of the file contains code I shan't post here.
 
if it will be to modify codigo, please, keeps the name of its original authors
e please, enters in contact with me…

ae galera, serio, has mta people fdp q simplismente uses, nao either soh sucker of script,
n either lammer imbecile, n either the excrement of one script kiddie, n either a babaca, helps improves it tambem!


Thats what google translate gave me.
 
And Babel Fish the same:
Defacing Tool 2,0 by r3v3ng4ns [email protected] will be to modify codigo, please, keeps the name of its original authors and please, it enters in contact with me... ae galera, serio, has mta people fdp q simplismente uses, nao either soh sucker of script, n either lammer imbecile, n either the excrement of one script kiddie, n either a babaca, helps improves it tambem!
Jeff
 
I am not done researching this, but this is what I have found so far.

I found one of our servers so bogged down that it had become useless as a web server. The process list showed that exim was being called to send email, when we were not sending any email from that host. The process calling exim to send mail had changed its name in the process table as to not be found. Killing the process only caused another to start immediately. I immediately looked in the /tmp directory to find c2.pl and robots.pl, both of which I knew should not have been there. I isolated the process bogging the host down to get its process id. lsof -p <pid> showed me the files it had open and the connections it had made. lsof showed a permanent connection with a host, ns305366.ovh.net and the port was for IRC, 6667. I then modified the iptables to block outgoing connections to the lookup for ns305366.ovh.net, which was 94.23.218.118. I killed the process again, and this time it did not start itself again, presumably because it could not connect to the IRC server.

I then looked at the .pl scripts and found that robots.pl was a copy of c2.pl with some constants changed. robots.pl was being run to connect to the IRC server to receive email addresses and spam messages which it piped to exim for transmission off our server. If you use your IRC client to connect to ns305366.ovh.net, you will see that there is only one or two channels on that server and they are used to bring up a DCC connection to the hacked mail host to send the spam data.

We will be wiping this system to upgrade Fedora anyway, but our standby host is already in use. So, my goal was to just disable the spam relay. I still don't know how the application got on to the server, but I suspect PHP which has been our security nemesis several times in the past. The key to fixing this problem was lsof and iptables.
 
Back
Top