[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