is this email legitimate? "Plesk - Critical Security Vulnerability"

[SalvadorS]

Hello,

The proccess run by the robot exploiting the server uses wget to download files to the server. Is there any way to limit the user of wget without affecting plesk?

A lot of clients will change their passwords to the old ones even if you told them not to do it. So we need a extra protection. One thing to do is limit the cron to the clients (99% don´t use it) another good thing is limit wget. It is possible to disable login as root and:

chmod 0700 /usr/bin/wget

Enable it again:

chmod 0711 /usr/bin/wget

But, it is possible to limit it? For example only root can use it.

Thanks

 

[HostaHost]

It appears that, as of a few days ago, someone has either found another way to get the passwords from fully patched 9.5.4 servers, or they've found a way to log in without password on fully patched 9.5.4 servers. We had a few left on that version, all were up to date months ago, all had passwords changed, all had the contents of /enterprise/control/ deleted and now we find IP 188.134.45.0 has been logging in to client accounts over the past few days, using the file manager and adding redirect code to .js files. A curious side note; they have only hit client accounts that have domains on an exclusive IP address, none that are on shared, which suggests that whatever technique they're using, they can't enumerate the info they need to log in without knowing a domain name.

Same IP attempted to, unsuccessfully, log in on our Plesk 10 servers, so whatever Parallels has left broken in 9 at least seems fixed in 10.4.4.

 

[SalvadorS]

Plesk, can you confirm the last post is true? Do you have any evidence?

 

[HostaHost]

Plesk, can you confirm the last post is true? Do you have any evidence?

I don't have evidence beyond:

1) Full patched 9.5.4 server
2) Client and ftp passwords changed months ago after Parallels finally decided to tell us that there was a serious issue
3) Access logs (domain changed):

188.134.45.0 domain.com:8443 - [17/Jun/2012:08:17:59 -0400] "POST /login_up.php3 HTTP/1.1" 200 966 "https://domain.com:8443/" "-"
188.134.45.0 domain.com:8443 - [17/Jun/2012:08:17:59 -0400] "GET / HTTP/1.1" 200 1474 "-" "-"
188.134.45.0 domain.com:8443 - [17/Jun/2012:08:18:01 -0400] "POST /plesk/client@85/domain@/?context=domains HTTP/1.1" 200 35224 "-" "-"
188.134.45.0 domain.com:8443 - [17/Jun/2012:08:18:34 -0400] "GET /plesk/client@85/domain@339/hosting/file-manager/edit/?cmd=chdir&file=/httpdocs/wp-content/plugins/nextgen-gallery/shutter HTTP/1.1" 200 39078 "https://domain.com:8443/plesk/client@85/domain@339/hosting/file-manager/edit/?cmd=chdir&file=/httpdocs/wp-content/plugins/nextgen-gallery/shutter" "-"
188.134.45.0 domain.com:8443 - [17/Jun/2012:08:18:36 -0400] "GET /plesk/client@85/domain@339/hosting/file-manager/edit/?cmd=edit&file=shutter-reloaded.js HTTP/1.1" 200 126505 "https://domain.com:8443/plesk/client@85/domain@339/hosting/file-manager/edit/?cmd=chdir&file=/httpdocs/wp-content/plugins/nextgen-gallery/shutter" "-"

Each domain would start with a POST request to /login_up.php3 and no prior request, then a request for /, then they're in and navigating to the file manager. Whoever is doing it is primarily focusing on known directories that would hold javascript files; they know right where to go to edit wordpress files for example.

 

[qiskevin]

Same Here

We are seeing the exact same thing on a fully patched Plesk 9.5.4 for Windows node. Has anyone seen this on 9.5.5?

 

[IgorG]

Thank you for information. We will check this issue and I will update this thread with results.

 

[IgorG]

Guys, please send me login credentials for your compromised servers in PM if it is possible. We should check it directly on your server.

 

[dgarciap]

I have the same problem, Parallels support answer me the servers was hacked...

I´m worry if its a new security bug...

 

[IgorG]

I have the same problem, Parallels support answer me the servers was hacked...

I´m worry if its a new security bug...

What is your support ticket ID?

 

[tkalfaoglu]

Not to sound prejudiced, but we have had lots of attempts from China - you may wish to block some IP ranges just to be sure.
-t

 

[dgarciap]

Hello,


My ticket ID is: 1386623


Thank you.

 

[Myhost]

@ Hostasaurus.Com

Is it possible those clients have changed their PLESK passwords back to what they were before you changed them some months ago (after the patch was applied) ? I know we have seen this happen after we changed client passwords , a number of them changed them back again to their original passwords.

Rgds
Martin

 

[/var/tmp]

@ IgorG

We also had some clients who changed their password back to their old ones. Still I am curious what came out
of ticket ID is: 1386623 ? Was there a hack or clients changing back to old passwords?

 

[Blake@Parallels]

Are you sure this is the right ticket number? This ticket seems to be about IIS configuration.

 

[jtroher]

Is there a way to manually apply the updates to Plesk 8.6.0 on Linux? I have 3 servers that the Updater and autoinstallers are not working for. I found manual fixes for about all other versions except 8.6.0.

 

[HostaHost]

What do we need to do to get an answer on the question of how to test for updates being applied and how to replicate updates to servers? Since there's another happy new notice of security microupdates today, it would be REALLY NICE if we could apply them to all servers using automated methods and then test that they're applied using the same methods. Parallels, you do realize some people have installed bases of more than a few servers right?