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

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.

Same problem here, someone fixed it?

You can Google the fix, it's a standard PHP Injection Attack due to an insure PHP configuration.
It also only affects people still using the EOL CentOS 7 OS.

But I think someone posted the fix here in one of the threads as well.

🛑 What I Found

On my server, inside /home/username/public_html/public/ and /home/username/public_html/, I found two suspicious files:
   •   nbpafebaef.jpg – Contains PHP code despite the .jpg extension:
<?php echo md5("gewafwaef1");die;?>

   •   defauit.php – A PHP script with a misleading name (looks like “default.php”).

i also found these two files in my public_html folder, what should i do with them should i deleted them both? how to make sure there is no other similar exploit?

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/

i understand that is for the future prevention but what to do with the current infection . should i delete the below two file manually from all sites public_html directories ?

defauit.php
nbpafebaef.jpg

Oh for sure -- I thought you had already done that as a first step. They are likely what gives the attacker persistence on your server.

Since I don't need the user panel, I removed ports 2082 and 2083 from the firewall configuration file. This prevents access to the user panel.

To do this: log in to the admin panel, go to Firewall, and configure the "Opened TCP/UDP Ports". This will open the configuration file in edit mode. Remove ports 2082 and 2083 (you can find them under "Allow outgoing TCP ports" and "Allow incoming TCP ports") and then restart the firewall.

You will still be able to access the user panel if you need to perform actions that cannot be done through the admin panel, because when you log in as an admin in the admin panel, your IP is unrestricted by the firewall. Other users will experience connection timeouts.

I also recommend changing your users’ passwords, as the generated passwords are quite weak. Why the concern?
I discovered that long time ago I had created a username incorrectly by swapping two characters, then deleted it and created another one. Later, I removed that second user as well since it was not needed. Although these users are removed and non-operational, they still appear in the system, specifically in the "/etc/shells" file.
After checking the access logs, I saw that these two users had been exploited by the attacker. So I assume the attacker was able to read many files including "/etc/shells".
For testing, I logged in as a non-sudo user and confirmed that I could access and modify content in many parts of the server. So by the SSH access, you are not restricted only to the /home folder, you can explore almost all directories and content of the server. So It is also possible to extract password hashes for cracking. Or maybe your server can be ordered to brute force passwords and send it to the attacker.

Additionally, last night I turned off my httpd service, but by the morning it was running again. It was restarted at 4 AM. I am not sure what caused it to turn back on, but this behavior looks weird.

I do not intend to use my server for shared hosting, so I am not particularly concerned. However, granting this kind of shell access to regular users does not seem appropriate.

1. You also need to harden your PHP configuration.

2. Not be running CentOS 7 still, update to AL8.

3. Only firewall ports that should be open, are the bare minimum your server needs.
With Admin IP's whitelisted.

Additionally, last night I turned off my httpd service, but by the morning it was running again. It was restarted at 4 AM. I am not sure what caused it to turn back on, but this behavior looks weird.

Various cron tasks will restart httpd as a matter of course. And CWP's cron tasks run overnight, particularly AutoSSL which runs at 4 am. If you really want to disable it, you could remove those cron tasks, issue systemctl disable httpd and block incoming ports 80 and 443 on the firewall. But then you won't have a web server anymore. But maybe that's what you're after...

Since this WAS a vulnerability in CWP, there is no point in considered that if a server was affected, there is no backdoor still installed.

The report is here: https://fenrisk.com/rce-centos-webpanel

So, if you are still in a server that have been compromised, there is no way around to know what have been done. Remove the files can be suficient, sure. But you don't know if anything else was compromised.

The information that this is a fault from PHP, WordPress or some script in the user server are not true. If you see the files stated in the first message in your accounts, your server was exploited due to the CWP vulnerability.

Also: we are still waiting for any information related to this by the CWP team.

So, if you are still in a server that have been compromised, there is no way around to know what have been done. Remove the files can be suficient, sure. But you don't know if anything else was compromised.

As far as I could see, this attack was only able to compromise non-sudo accounts. Through trial and error (using combinations of domains related to the server), the attacker only needed to find one valid user. Once that happened, he was able to discover other usernames to exploit additional non-sudo accounts.

In the worst-case scenario, the attacker was able to explore the server in read-only mode — likely dumping databases, backup files, SQL user credentials, and so on, across the entire system.
Non-sudo accounts should not have read access across the whole system, even the /etc/shadow file is readable with them.
Write access was only possible within the affected users’ home directories, including the /tmp directory.

Regarding WordPress what happened to your websites? Mine were defaced with a fake drop-shipping-style store, and the results got messed up in Google Search. Usually, these deface hacks are triggered when the referrer is Google, but this one didn’t behave that way. I only discovered it's real face by simulating a Googlebot user agent in my browser.
The wordpress code got so messed up that I can't even find where the infected code is. I'll have to reconfigure a brand new installation.

It looked like this:
https://i.imgur.com/zn6ji93.png

As far as I could see, this attack was only able to compromise non-sudo accounts. Through trial and error (using combinations of domains related to the server), the attacker only needed to find one valid user. Once that happened, he was able to discover other usernames to exploit additional non-sudo accounts.

The file dropped in the directory was a web shell. The attacker indeed have interest in change the webpages to a pseudo store, but with the webshell, he can have access to any account in the server, and any file on it - including the way of change any system file or configuration.

Yes, the exploit starts with a non-sudo user, but can change any other file on the system. If that happend or not... is complicated to know.

In the worst-case scenario, the attacker was able to explore the server in read-only mode — likely dumping databases, backup files, SQL user credentials, and so on, across the entire system.
Non-sudo accounts should not have read access across the whole system, even the /etc/shadow file is readable with them.
Write access was only possible within the affected users’ home directories, including the /tmp directory.

With the webshell, you can have full access to the system, unless you have some way of mitigate that - like Cloudlinux does. They have a virtual filesystem to every users, so even if the website is exploited with a webshell, the attacker can only see the virtual root filesystem, not the actual system.

CWP doesn't have that. With a webshell, they can see and edit or send any command to the server.
If you use the CWPSecure kernel, i don't know if they have that protection. But i bet most of the servers don't use that.

Regarding WordPress what happened to your websites? Mine were defaced with a fake drop-shipping-style store, and the results got messed up in Google Search. Usually, these deface hacks are triggered when the referrer is Google, but this one didn’t behave that way. I only discovered it's real face by simulating a Googlebot user agent in my browser.
The wordpress code got so messed up that I can't even find where the infected code is. I'll have to reconfigure a brand new installation.

It looked like this:
https://i.imgur.com/zn6ji93.png

Yes, the exploit appears to be target to wordpress websites. The file that actualy deploys the exploit can be dormant in the system for months, and only activated when the attacker sees it. Is a fake JPG file with PHP code in it.

Do you know which wordpress files got infected?

It can vary from installation to installation.
In some, the backdoor stays dormant in the server, waiting to be "activated" - the file placed first is just a exploit, to create the webshell file if access with a POST request and specific queries. If the request is done, the file "defaiult.php" is created, and that is the real webshell file.

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.

Of course, data in the BD and other details, like the WordPress configuration file, are also changed/access. If you have any password or WordPress salt in there, change them. But at this point, the installation in your server should NOT be considered safe.
You can still use it... but at your own risk.