Recent Posts

Pages: 1 ... 7 8 [9] 10
81
You want to delete /usr/local/cwpsrv/var/services/user_files/modules/filemanager.php (or rename it to like filemanager.php.disabled, make sure it no longer has .php extension at the end)
For now, however, I would like to repeat: Make sure no one can access your filemanager by deleting the file /usr/local/cwpsrv/var/services/user_files/modules/filemanager.php (or renaming it to filemanager.php.disabled).

Exactly, delete OR rename. I don't see your point.
82
You want to delete /usr/local/cwpsrv/var/services/user_files/modules/filemanager.php (or rename it to like filemanager.php.disabled, make sure it no longer has .php extension at the end)
For now, however, I would like to repeat: Make sure no one can access your filemanager by deleting the file /usr/local/cwpsrv/var/services/user_files/modules/filemanager.php (or renaming it to filemanager.php.disabled).
83
PHP / Re: FYI - ionCube Release new loaders 13.3.0
« Last post by Starburst on July 08, 2025, 11:03:25 PM »
The current version of the ionCube Loaders is current at 14.4.1.

And yes, it's better to be safe than sorry.
84
Mod_Security / ModSecurity updated to 2.9.11
« Last post by Starburst on July 08, 2025, 11:01:47 PM »
If you already have updated your ModSecurity from the stock 2.9.1, to e.g. 2.9.8, this article will show you how to update to 2.9.11.

And if you want, there is also a script you can download & run.

https://starburst.help/control-web-panel-cwp/modsecurity-running-with-control-web-panel/update-modsecurity-to-2-9-11-running-cwp-and-apache-on-almalinux-8-9/
85
Might need some more street cred here than just the 4 posts on this thread before people listen to the advice and go deleting (!) their filemanagers... A Chicken Little response doesn't usually end up well.

But, the file manager always has struck me as a sore thumb, bolted on to CWP -- and it looks to be an implementation of the Vue library, with treeVue and other JS integrated. Probably overdue for some attention & modernization. It hasn't changed much at all over the last 5+ years. Probably plenty of fleas...

Firstly, I didn't say delete, I said rename a single file that inconveniences your users slightly (they now have to use SFTP or FTP to change files, rather than a WebUI), not a core feature of CWP in the first place. You could always install a WebFTP plugin to temporarily stopgap the functionality, too.

Further, I can't force people to listen, nor do I intend to try. I'm doing my best to keep people safe. And, as stated, am willing to prove the exploit is real if that helps people feel better about it (without giving it away of course, since not wanting it to spread).
What people do with the information I provide is up to them.

Lastly, I have gotten a response from CWP support they'll have a developer look at my report, so let's hope something good comes out of that before more people get their websites turned into malware.
86
Might need some more street cred here than just the 4 posts on this thread before people listen to the advice and go deleting (!) their filemanagers... A Chicken Little response doesn't usually end up well.

But, the file manager always has struck me as a sore thumb, bolted on to CWP -- and it looks to be an implementation of the Vue library, with treeVue and other JS integrated. Probably overdue for some attention & modernization. It hasn't changed much at all over the last 5+ years. Probably plenty of fleas...
87
It seems like the filemanager is riddled with bugs itself (beyond its authentication bypass). Without looking too hard, I have now also managed to find a command injection vulnerability (as in, you can get it to run arbitrary shell commands as the user), which might explain another path how these malicious scripts run.

From how quickly I found this after probing random features, it is likely there's more as well, they might just be harder to find, or I didn't try them, yet.


I have also poked around at the other various endpoints in CWP, those seem to validate authentication correctly. But the filemanager code just seems to be of substantially worse quality than the rest of CWP (not sure why, as I can't read the code as previously mentioned, just judging from finding multiple bugs very easily, while the rest of CWP seems to hold up to some poking and prodding)

I do agree, this necessitates an immediate response as it puts every single user of CWP at high risk. Really only a matter of time until some scanner finds any CWP installation and tries to exploit it.


As for lateral movement: That is quite easy. You can simply list all folders in /home (which reveals all usernames) and repeat the exploit against every single user (possibly via the above mentioned command injection to bypass mitigations like open_basedir). You can likely even run the exploit locally from the machine itself. As mentioned, the exploit works against any valid user. And with one, you can enumerate all users.

To reiterate, this allows dropping files and running shell commands as any CWP user, no matter if they have an active domain or not. It does not allow going to "root" or "admin" levels.


So, all existing symptoms (lateral movement after finding a single user, uploading files into user's /home folders, and running files) can currently be explained with the filemanager vulnerabilities.

If any files are running as root, then everything gets much worse, but so far I have not found a path to root user / system compromise. That does not mean it is impossible, of course.

For now, however, I would like to repeat: Make sure no one can access your filemanager by deleting the file /usr/local/cwpsrv/var/services/user_files/modules/filemanager.php (or renaming it to filemanager.php.disabled).
88
It is indeed a filemanager issue. I have tested found the vulnerability by testing against my own CWP server (which is up fully up to date, and runs AlmaLinux 8 ).

You can effectively convince the filemanager to perform any operation without being correctly authenticated as any user (so long you know or can guess their username).

Luckily, this does not work against the "root" user, only valid CWP users, so it does not allow for total system compromise.

As for why it makes non-.php files run as code? Possibly a malicious ".htaccess" file or similar could be uploaded to changes the handler directives, or another vulnerability (which I did not discover) allows reconfiguring the webserver.


I tried reporting the issue (privately) using the contact form and have been informed I need a support subscription, and have responded that I will not pay for reporting security issues. If I get another negative response, I might have to put the information into the bug tracker so the engineers actually can see it, but I would really rather avoid sharing any information in public to not cause this to be exploited even more widely than it already seems to be.


The easiest sign of a compromise (or attempt) through this bug are POST calls to "/USERNAME/index.php?module=filemanager&..." with a 302 response code in your logs, especially with non-browser user-agents.

I am also not sure what the discussion of "execution" here is, PHP does not care if a file is chmod 644 or 755 or anything else, so long as it can read the file, it can (and will) run the file when accessed via a browser through the webserver.

There might well be more security issues present in CWP, given the one I found was not too difficult to discover, that allow actually running arbitrary commands or things of that nature, but checking is hard as all of CWP is encoded with ionCube, and therefor I have to try random things to see what happens, I can't just read the code.

I will look for more issues in the filemanager code myself as well, just for completeness sake.

And again, if anyone knows of a way to (privately) report this to CWP without telling potential "bad guys" the exact exploit path, please tell me.

If anyone needs verification of this bug, feel free to create me a test user on a CWP installation of your choice and I can upload a (harmless!) file using the exploit.

It’s completely unacceptable that no one from the CWP team has replied to us. This issue was identified as early as June 22nd and was supposedly fixed, yet it continues to occur.
89
It is indeed a filemanager issue. I have tested found the vulnerability by testing against my own CWP server (which is up fully up to date, and runs AlmaLinux 8 ).

You can effectively convince the filemanager to perform any operation without being correctly authenticated as any user (so long you know or can guess their username).

Luckily, this does not work against the "root" user, only valid CWP users, so it does not allow for total system compromise.

As for why it makes non-.php files run as code? Possibly a malicious ".htaccess" file or similar could be uploaded to changes the handler directives, or another vulnerability (which I did not discover) allows reconfiguring the webserver.


I tried reporting the issue (privately) using the contact form and have been informed I need a support subscription, and have responded that I will not pay for reporting security issues. If I get another negative response, I might have to put the information into the bug tracker so the engineers actually can see it, but I would really rather avoid sharing any information in public to not cause this to be exploited even more widely than it already seems to be.


The easiest sign of a compromise (or attempt) through this bug are POST calls to "/USERNAME/index.php?module=filemanager&..." with a 302 response code in your logs, especially with non-browser user-agents.

I am also not sure what the discussion of "execution" here is, PHP does not care if a file is chmod 644 or 755 or anything else, so long as it can read the file, it can (and will) run the file when accessed via a browser through the webserver.

There might well be more security issues present in CWP, given the one I found was not too difficult to discover, that allow actually running arbitrary commands or things of that nature, but checking is hard as all of CWP is encoded with ionCube, and therefor I have to try random things to see what happens, I can't just read the code.

I will look for more issues in the filemanager code myself as well, just for completeness sake.

And again, if anyone knows of a way to (privately) report this to CWP without telling potential "bad guys" the exact exploit path, please tell me.

If anyone needs verification of this bug, feel free to create me a test user on a CWP installation of your choice and I can upload a (harmless!) file using the exploit.
90
So according to the 2 vulnerability reports you mentioned, it's limited to EOL CentOS 7 systems -- for which support ended over a year ago. Not too surprising, really. The longer those systems are on the internet, the more of sitting ducks they become. Time to migrate to AlmaLinux!

Can you confirm that you both are running CentOS 7 systems?

Caught one probe for this vuln on one of my Alma systems, coming from Hong Kong:
Code: [Select]
[root@alma]# grep "module=filemanager" /usr/local/cwpsrv/logs/access_log
91.124.30.69 - - [08/Jul/2025:04:50:00 -0500] "POST /myuser/index.php?module=filemanager&acc=changePerm HTTP/1.1" 404 147 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 14.7; rv:134.0) Gecko/20100101 Firefox/134.0"

No is not, this is a panel issue (Im in version 0.9.8.1206), I use AlmaLinux 8 not CentOS 7. This is is a Filemanager issue, is better to remove the filemananger for now.
Pages: 1 ... 7 8 [9] 10