[security] Plesk admin login attempts making it impossible to login as admin.

[lnxmtl]

I write in Plesk 9 forum, since the problem is the same for all versions of Plesk. The actual situation is with a Plesk 7.5 machine.

Starting 2 weeks ago, I noticed that when trying to enter as admin, I was very often denied access, the reason being too many unsuccessful login attempts.

At first, I waited, but the problem is now nearly constant, so I made a little script to restore access from SSH.

Here is the script I called psa-unlock (FWIW) :

cat psa-unlock
#!/bin/sh
#
# Unlocks the user (to allow Plesk connection after failed attempts before the normal timeout)
#

pass=`cat /etc/psa/.psa.shadow`

query="SELECT login,last_wrong,attempts FROM psa.lockout WHERE CONVERT(login USING utf8) = '$1' LIMIT 1"
nice -n19 mysql -uadmin -p$pass -B -r -e"$query"
query="DELETE FROM psa.lockout WHERE CONVERT(login USING utf8) = '$1' LIMIT 1"
nice -n19 mysql -uadmin -p$pass -B -r -e"$query"

Just after executing the script, it is possible to log as admin, but waiting more than a minute makes it impossible again, suggesting it's an ongoing attempt.

Here's what I found in the control panel access log :

grep 'login_up.php3?passwd=' </usr/local/psa/admin/logs/httpsd_access_log|sed 's/-.*GET//;s/?passwd=/ /;s/&login_locale=.*login_name=/ /;s/HTTP.*//'|sort|uniq -c|sort -nr

71 209.190.75.xxx /login_up.php3 setup admin
66 97.74.64.xxx /login_up.php3 setup admin
59 72.137.79.xxx /login_up.php3 setup admin
46 67.18.194.xxx /login_up.php3 setup admin
43 216.185.43.xxx /login_up.php3 setup admin
37 69.93.153.xxx /login_up.php3 setup admin
24 67.205.85.xxx /login_up.php3 setup admin
18 69.93.2.xxx /login_up.php3 setup admin
15 63.245.16.xxx /login_up.php3 setup admin
10 74.52.223.xxx /login_up.php3 setup admin

First column is the number of attempts by the IP.
none of the other servers I checked have this pattern of nearly 400 attempts in 24H by a pool of IPs (mostly from the US). The constantly changing IPs that try to get in suggests an organized attack against way more than just this server (using a botnet or already compromised servers)

They try to exploit the simple flaw of the Plesk default admin password :
http://kb.odin.com/en/382 (revised Oct 6, 2008)
http://osvdb.org/show/osvdb/6444 (known since 2000)

Clearly, if I had to reinstall the server, they would have an opportunity during the setup process to enter using the default password and do anything as root (setting up a cron job).

I wonder if this password can be reset (even temporarily) under other circumstances (such as during a Plesk upgrade, or when Plesk tech are given access, etc ...)

So far, they have not entered the server, but I'm not comfortable to know they are in permanence that close to successfully get in, and there is little I can do to stop them (iptable blocking would not help much as their IPs always change).

There clearly is a danger when a server is reinstalled (unless it's isolated during the setup process until the default admin password is changed), and that might be a cause for repeatedly reinfected machines despite complete 'clean' reinstalls.

Is this an known attack ?

Did you experience it with your own servers ?

I wonder if a server under such surveillance is also vulnerable (temporary password reset) at other times ? (that's the part that worries me most)

Also, how comes this default password still exists ?
The admin password could be set during the install process or default to a random value if not set (can then be retrieved as root by typing : cat /etc/psa/.psa.shadow )

 

[cpet]

Re:

I use grok, to sniff out the logs and find loging attempts for various ports which dont need many users to have access, so if IP a tries to brute force the plesk login grok will add a iptables rule. This has worked without flaw so fare. This is a perl script which runs as a daemon sniffing which ever log file you setup with it.

http://www.semicomplete.com/projects/grok/

Doesn't really answer your question but, it does fix the issue and various other as it can be setup to block ssh brute force attempts, the plesk issue you have, and any other issues that might arise.