CVE-2023-24676

[teppo]

A new vulnerability (CVE-2023-24676) was published last week, detailing how module install can be used to execute code and set up a reverse shell on a site. After going through the post that explains the exploit a couple of times I'm wondering if someone could confirm that I've got it right:

• First of all it requires that a) web server has write access to the modules directory and b) ProcessWire is configured to allow file uploads, right?
  • The latter is by default true in debug mode, which is also mentioned in aforementioned post as one of the conditions. Built-in module downloading features check the moduleInstall setting (in ProcessModuleInstall class) and I couldn't find any way to circumvent them.
• For anything bad to happen, user with (presumably) superuser access must type in an URL of a ZIP file with malicious code, or someone must be able to intercept the request and change it.
  • First part seems to be a non-issue, e.g. if a superuser really does that then there's very little that can be done to protect them, while the second part (to my understanding) sounds like it would be very unlikely and quite difficult, at least assuming that requests are passed through HTTPS.
• According to the post the PHP file in the zip is automatically executed by the system. I find this part a bit strange — I'm not exactly familiar with every involved piece of code, but it doesn't seem like ProcessWire should do that. On the other hand if the file in the package was a properly formatted module class, then this would be more likely, and again probably not something that can be prevented.

So, in other words, it seems to me that this vulnerability isn't really a vulnerability — more like a way to use a built-in feature to do potentially harmful actions, of which users are specifically warned about in UI of said feature? Let me know if I got something wrong here, though.

If anything, it seems to me that this is a good reminder that it is indeed dangerous to enable file uploads from arbitrary URLs or allow web server to write files that could be executed as PHP (or any other language for that matter, including JavaScript). Only thing that I think we could do better is to set those module file download settings false by default, instead of debug as they are now, just to be extra sure that a developer has indeed intentionally enabled them 🙂

[Robin S]

1 hour ago, teppo said:

First part seems to be a non-issue, e.g. if a superuser really does that then there's very little that can be done to protect them

Yes, exactly.

Everything in the vulnerability description after "we require a user account with administrative privileges and the application must have debug mode activated" seems redundant to me. At that point it's game over. Rather than following all the subsequent steps you could simply install Tracy Debugger and start executing arbitrary PHP code in the Console panel.

It's up to every superuser to ensure that malicious users cannot get an account with administrator privileges so I don't understand how this vulnerability description adds anything beyond that basic point.

[teppo]

8 minutes ago, Robin S said:

Rather than following all the subsequent steps you could simply install Tracy Debugger and start executing arbitrary PHP code in the Console panel.

Based on how they kept specifically mentioning the requests containing the download_zip_url variable and the relatively high score this CVE has (7.2 High) I was expecting that they'd found some major issue, or perhaps a way to circumvent normal core behaviour. But really it just seems like they figured out that if you are able to inject code into the system you can use it to do nasty things.

There is one difference to the Tracy example, of course: in that case the administrator would have to install Tracy and then type in the command to the Console panel. If the attacker doesn't have superuser access but they know a system that matches aforementioned conditions, they could lure an existing superuser to install malicious code via the admin 🙂

--

I don't want to belittle any potential security issues, but it seems that this one is blown way out of proportion. I'm not familiar with the process used to validate and score CVE's, but it seems that they definitely err on the side of "always assume that reports are true, and always assume that the issue is as bad as it could theoretically be".

[bernhard]

What would happen if anybody uploaded such a zip to a regular user's file field? It would still be a zip, right? Isn't there a setting to automatically unzip on upload? Would that be a problem? I guess no, right? It would just unzip it and then we'd have a .php file in the field, but I think that would need to be allowed in the field settings. And even if allowed I don't think pw would at any time execute this file?

[BitPoet]

I wonder if @ryan was ever contacted about this.

I've tried to come up with a scenario where the URL injection mentioned in the CVE can become exploitable, but I'm having a hard time. When you can intercept a communication to that level and modify the message body, you could just forge the necessary requests, supply them with the intercepted session information and use the built-in module upload functionality. That's why we have DANE, so the communication stays confidential even if you're routed through untrustworthy networks.

I've sent a rejection request to MITRE with the following rationale:

Quote

The reported vulnerability describes how a malicious extension module might be imported and executed in an installation of the ProcessWire content management system. The exploitation mechanism described in the verbose article on medium.com (linked below) is based on two assumptions:
1. the user logged into the ProcessWire installation has admin permissions;
2. the attacker is able to intercept and modify requests between the client (browser) and the webserver hosting the ProcessWire installation.

Such an admin user, however, already has the means to upload zip files which contain arbitrary module code from the local system through a HTTP POST request. If an attacker can intercept and modify the communication to the level required for the described scenario, they could also use the intercepted session information and simply forge a request that contains the code for a malicious module.

It is my understanding that with the combination of a) being able to execute a MITM attack as needed here and b) being able to abuse the session credentials for an admin user that way, any modern, browser based CMS could be modified in a way that it either performs unwanted actions or stops working, so the numbers of CVE entries one could generate would be astronomical, when, on the other hand, it is essential knowledge that the safe administration of a web application requires state of the art means of ensuring confidentiality (e.g. by using strong TLS and securing the integrity of the certificate through DANE). In summary: since the scenario in question already requires a far further reaching breach as a prerequisite, it should not be considered an independent vulnerability.

 

[teppo]

22 hours ago, BitPoet said:

When you can intercept a communication to that level and modify the message body, you could just forge the necessary requests, supply them with the intercepted session information and use the built-in module upload functionality.

This is the part that I was most confused about. The post goes to detail about trivial stuff such as how to create a zip file, but then simply states that...

Quote

When intercepting the request using Burp Suite [...]

To inject the malicious code into the ProcessWire application, I intercepted the plugin installation request once again. This time, I inserted the URL of the VPS containing the “plugin.zip” file with the malicious “pwn.php” code.

They make it sound super easy, and obviously it is when you are both the attacker and the victim, but that has little to do with real world. Of course MITM is a serious threat and systems should be configured properly and users should be educated about risks of e.g. connecting via public wifis, but it's not something you can just pull off like it was nothing.

And yes, any system that allows the user to directly execute code or upload files that are executed as code is technically "vulnerable" once you gain access to those features.

That being said, I do see some potential for improvement here. For an example I think the default settings for moduleInstall should be as strict as possible, and I'm also wondering if ProcessWire could do light-weight scanning of obviously dangerous actions? Something like checking if an uploaded module/PHP file contains exec/eval/etc. or base64 encoded values, and at least displaying a warning to the user.

Not sure if that's really feasible or particularly useful, though, and it could no doubt be circumvented by a targeted attack. Just a rough idea 🤷‍♂️

[BrendonKoz]

On 2/4/2024 at 4:38 AM, bernhard said:

What would happen if anybody uploaded such a zip to a regular user's file field? It would still be a zip, right? Isn't there a setting to automatically unzip on upload? Would that be a problem? I guess no, right? It would just unzip it and then we'd have a .php file in the field, but I think that would need to be allowed in the field settings. And even if allowed I don't think pw would at any time execute this file?

That might be another thing to test then, too - see if the automatic ZIP upload and decompression setting of a file field that ended up getting used in a, let's say FormBuilder form, which then creates pages for the user...would allow a PHP file to be created, and accessible, by a nefarious site user.

In hindsight it seems silly to allow such a process to occur, but when you're so focused on the intended uses of something like this, the unintended sometimes is missed. (ex: Having a local writer's community website managed by ProcessWire, and allowing them to upload ZIP archives of text, html, photos, markdown, etc., to then be published for others to read/see - and then overlooking the potential for an HTML file to reference an external site via iframe that does some fun things - it's not specifically a ProcessWire issue, it's an oversight in development)