That whole 'setup' password deal

J

JimJ

Bit poster
Right now, there is an active worm which is targeting datacenter ip address ranges, searching for plesk installations that have the username & password combination of admin and setup. I've personally setup fresh plesk installations on known datacenter ip address ranges within multiple datacenters to watch the progress of this worm, and each have been hacked in the following manner:

1) Bot logs in with the username/password of admin:setup
2) Bot accepts license agreement, goes on to enter saved registration information for the company based on the network they are attacking
3) Bot goes into plesk, straight to the crontab configuration section, adjusts the crontab to download their rootkit, unpacks the rootkit, runs a variety of different scripts to replace binaries & simply backdoor the box.
4) Bot removes the crontab entry once everything is finished, and from there a new host is added to their list of boxes for use.

This would not be possible if the plesk installer didn't come pre-packaged with a static password. In addition to that, it's one of the only internet applications that doesn't include password configuration as part of the script installation.

Would anyone make use of a linux distribution that enabled ssh by default, skipped root password configuration, stuck you with the password of 'password', and demanded you identify yourself and your business before you had a chance to enter your root password?

Yeah, you can always use the '/usr/local/psa/admin/sbin/ch_admin_passwd' binary to change the password before entering your registration information, but that program is not known to everyone, and it's pretty poorly written to begin with. You should be able to use something like '/usr/local/psa/admin/sbin/ch_admin_passwd MYPASSWORD', but instead you have to use

Code: 
read -p Password: PSA_PASSWORD; export PSA_PASSWORD;
/usr/local/psa/admin/sbin/ch_admin_passwd; unset PSA_PASSWORD

Which is probably going to confuse most anyone who has the desire to use your windows frontend for linux in the first place.

I hate your company entirely, it pains me to support your god awful software, you are only popular because you made your control panel look like windows, everything you've written implements all system services in an ass backwards manner. This password configuration manner has been in place for years, and your developers are absolute buffoons for thinking this is acceptable.
 
finished restoring server from this rootkit

I just finished restoring my whole dedicated server due to this worm. My host installed plesk manually with username/password of admin/setup. Basically the bot took control of my server via the steps that JimJ described in his post.

This worm appears to spread fast since my host installed plesk and handed it over to me in a matter of a few minutes. I had no idea that the server was compromised; the license agreement page came up and everything seemed fine and worked properly.

The worm installed the SHV5 rootkit onto the server. SHV5 replaces common linux programs such as "top", "ls" and "netstat" with hacked versions to hide the presence of the rootkit. The server log files are edited by the rootkit to cover tracks and the functions that show the last logins are hacked also. The rootkit also compromised the rkhunter program that was installed. I had to install a new version of rkhunter 1.3.6, manually to detect the possibility of the rootkit.

Manually inspecting the file system I found,

/usr/lib/libsh/.sniff/shsniff (What appears to be a packet sniffer)
/usr/lib/libsh/.backup (Copies of the hacked services)
..many other modifications

I had to do a complete format and setup the server from scratch, complete OS reload.

The only reason I detected this rootkit is because "logwatch" recorded the rootkit trying to connect to other services. I suspected something and installed rkhunter again manually. Apparently this rootkit installs an ssh server complete with public key so that the hacker can enter the system even if the password is changed. The rootkit also sets the immutable flag on some hacked processes to prevent their deletion.

I decided to write this message so that others hopefully will run a scan on a fresh server install to detect the rootkit early. I did not suspect that my host would provide a server that is already loaded with a rootkit on a fresh install. I have spent the last 6 hours reinstalling my server due to this.

The Plesk installer should not have a hardcoded password that can be exploited so easily and quickly. I suspect that many users would not even notice this rootkit since it does an excellent job of covering it's tracks.
 
I decided to install a simple installation of apache+mod_ssl and run it with ssl running on port 8443. Here's some stats:

[root@aperature /var/log]# cat httpd-ssl_request.log | grep "login_up" | wc -l
314

[root@aperature /var/log]# cat httpd-ssl_request.log | awk {'print $3'} | sort -u
130.160.64.249
174.136.43.15
198.144.197.131
200.49.152.2
207.38.22.109
213.194.93.16
216.108.226.36
216.14.118.98
216.240.95.227
216.55.139.28
63.243.97.53
63.70.163.105
64.151.108.12
64.235.59.104
64.34.174.156
66.241.66.199
66.90.73.101
67.228.215.135
69.93.153.10
72.18.202.6
74.86.174.154
78.40.224.55
78.40.226.55
78.40.226.93
91.121.29.79
 
You must log in or register to reply here.
Back
Top