skip to Main Content

I was browsing mysql-slow-logs to check for potentiall optimization and I’ve noticed weird schema in them ( see below ):

SELECT password, type FROM accounts AS a  JOIN sys_users AS s ON ( = s.account_id) WHERE s.login='**DICTIONARY_USER_NAME_HERE**'  AND (SELECT count(*) FROM hosting   AS h WHERE h.sys_user_id = = 0  AND (SELECT count(*) FROM web_users AS w WHERE w.sys_user_id = = 0  AND (SELECT count(*) FROM ftp_users AS f WHERE f.sys_user_id = = 0;

What’s more frightening is that those queries are executed from admin@localhost ( which is specified Plesk MySQL user )

I’ve check in and it seems that Plesk stores some of passwords in plain text and those queries are obvious dictionary method to guess the login so mysql would respond with plain text password

So to sum up

  • queries called as admin@localhost
  • plesks passwords in plain text

I’m not sure what is the vector of attack but if we take few things in consideration:

  • the attacker does not now admin’s password, else he could perform
    exact query instead of dictionary
  • the attacker obviously is not going through ssh / remote mysql
  • its probably the plesk’s fault as I observed it on both servers which
    run under different OS, different configuration and only one of it
    has any content ( website/app or whatever which could be a possible
    vector of attack )
  • the most probable seems to be that the attacker ( or bot in this case
    ) is executing a query via some of Plesk’s not secured scripts (
    those who allows such query while not requiring you to be logged in )

Now I may totally wrong and missuderstood the situation and it’s some kind of totally normal Plesk action ( which I doubt ) what’s also weird is that I could not find anything in Google about this vulnerability

Some tech/soft background:

  • VPS
  • 1xCentOS 5 / 1xDebian ( both x64 )
  • Plesk Panel v. 10.4.4

I would be very greatfull if someone could confirm that they did encounter that problem/attack and maybe some kind of solutions how to prevent attacker – he eventually might guess the login, he didn’t got it yet.

Upgrading to v. 11 is for now out of discussion – VPS provider said he cannot do that yet, I cannot move projects to other VPS or at least not so fast

Thanks in advance & Regards,



  1. There has been big buzz about Plesk security about a year ago, but Plesk 10.4 has always been reported as safe.

    For a system storing passwords in plain it would be normal to retrieve password through SQL query. As the query doesn’t look like SQL injection, it is likely to be an activity of Plesk itself, but the activity can really be initiated by an attacker.

    An attacker doesn’t really need to have any special non-secured script in Plesk to try dictionary logins. They can always take your login page and try different combinations of dictionary login/password until it matches up. I guess there may exist pools of login/password pairs obtained from different systems exploited. As people would often reuse login and password – attacker would have a chance if tries many servers. Perhaps your server is one of 1000 others they are scanning.

    If you are really scanned, you should see a lot of those queries in MySQL log and also you should see multiple attempts to access your control panel in access logs. To stop that you need either to block access to your Plesk through Firewall (or through Access Restrictions) to everyone except a list of your trusted IPs.

    Login or Signup to reply.
  2. On a Plesk 12.5 installation, we found that these queries show up in the log when there is an attempt to log on with ssh. This could be verified by correlating the mysql.log with auth.log.

    When there is a dictionary attack against ssh, you can see a big amount of these queries in the log.

    If you can change the ssh port to something uncommon (1337?), you will usually avoid being the target of scripted attacks.

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top