Flatpress 1.2.1 - File upload bypass to RCE Vulnerebility

[s4n-h4xor]

File upload bypass to RCE
Severity: High

Description:
It is observed that the application has the functionality to upload images and download them further. The
download functionality is not sandboxed, and it does not have proper security control which can be
bypassed by tricking webserver and uploading dangerous file types which leads to RCE.

Technical Impact:
A privileged attacker can use the upload functionality to gain access to the server

Suggested Remediation:

1. Restrict the file types accepted for upload, check the file extension, and only valid
   extensions to upload.
2. Rename the files after getting uploaded randomly or use a hash.

Steps to Reproduce:

1. Login to the application

2. Navigate to the uploader section of the application.

3. Create a PHP file using the following payload.
   Payload:
   GIF89a;

4. Upload created php file

5. Navigate to file from media manager and open file

6. Append the following payload after file to give input commands and observe that commands
   are getting executed
   Payload: ?cmd=cat+/etc/passwd

Opening issue here, Got no reply from [email protected] for 2 months

[Fraenkiman]

Hello, everyone,

I unfortunately successfully reproduced the security issue on FlatPress fp-1.3.dev [master] and PHP version 7.4.30.

A possible solution could be to prevent the upload of php files via uploader.
Unfortunately, my PHP knowledge is not sufficient for a possible solution.

So that PHP files in the attachs folder cannot be called directly, you can add an additional htaccess with the following rule for this folder as a temporary solution:

<FilesMatch "\.(?i:php)$">
  <IfModule !mod_authz_core.c>
    Order allow,deny
    Deny from all
  </IfModule>
  <IfModule mod_authz_core.c>
    Require all denied
  </IfModule>
</FilesMatch>

_htaccess.zip

This is then only valid for this folder.
Tested with Apache/2.4.54

Best Regards

[azett]

Hi, thank you very much for reporting. FlatPress 1.2 didn't check uploaded files properly at all (even if the changelog said it did).
@Fraenkiman, could you please test this again?

Opening issue here, Got no reply from [email protected] for 2 months

Which I am ashamed of, totally missed this. Thank you very much for re-reporting here.

[Fraenkiman]

Hello, everyone,

the bug fix for the issue was successfully tested in the following upload scenarios:

Single file: shell.php ;File was not placed in the attachs images directory as expected. ✔️
Single file: *.zip; File was placed in the attachs directory as expected. ✔️
Single file: *.rar; File was placed in the attachs directory as expected. ✔️
Single file: *.png; File was placed in the images directory as expected. ✔️
Single file: *.jpg; File was placed in the images directory as expected. ✔️
Single file: *.gif; File was placed in the images directory as expected. ✔️

Mixed selection - only allowed file types; *.png, *.gif, *.jpg, *.zip, *rar, *.mp4 and *.avi; Files were placed in the images and attachs directory as expected. ✔️

Mixed selection - allowed file types with forbidden file type; *.png, *.gif, *.jpg, *.php, *.zip, *rar, *.mp4 and *.avi; ;PHP file was not placed in the attachs images directory as expected. ✔️
However, the following was noticed: #154

In my test, I was also able to successfully upload the *.js file type. This file type could potentially be exploited for similar vulnerabilities.

• Is the behavior of the uploader as expected?

Conclusion: Bugfix request has been successfully tested on fp-1.3.dev [master]. I have created a new issue to address the issue.

Best Regards
Frank