Stored XSS and possible RCE/LFI in case of misconfiguration in thorsten/phpmyfaq
Reported on
Oct 3rd 2022
Description
phpmyfaq has a feature to restore from a backup the entire application. An attacker with admin grant can export the configuration and re-upload the same file bypassing all the backend sanitization and controls.
Proof of Concept XSS
- login as admin
- go to backup page
- Create a backup and download it
- Edit or add some query to file
- in this case i edited the content of a category in order to fire an XSS on the admin panel or homepage
- navigate some page and see the xss (homepage, list categories etc).
PoC-Payload:
#MISCONF
In case of misconfiguration of the SQL service user grant. An attacker could abuse of that by reading/write sensitive file.
Example (read file grant) 1:
- Read ssh keys, or passwd etc...
SELECT LOAD_FILE('/etc/passwd')
Example (write file grant) 2:
- write a php shell file in the root of the server web (the path is discovered from the system information-> Server Document Root)
SELECT 'some php code ' INTO dumpfile '/sitepath/somefile.php'
Impact
This vulnerability allow an attacker to take control of the entire database and in some cases read arbitrary file or execute shell commands by writing malicious php file.
Great work @mike993 👌 Could you kindly propose/submit a fix for this vulnerability? Any help is appreciated.
@mike993 An attacker with admin permissions has easier ways of adding malicious code into the application.
Thank you @Thorsten. Sure, you are right, with an administrative user it is easier to add malicious code, but unfortunately many applications for this reason are not protected, or are superficially protected.
Often an application administrator is also not the system / server administrator. So the application must prevent the users (also admin) to go out of its context. In this specific case the backup and restore functionality is a feature, but there is no reason for a user to edit it before upload it.
Currently two solutions come in my mind:
Sanitize also the inbound queries from the restore function (I think it is very time-consuming to develop)
Encrypt the backup file before download and decrypt it after upload. This limits the ability to arbitrarily modify the database structure or bypass the various security checks. (i think is faster to develop)
this is an example: https://www.pakainfo.com/encrypt-and-decrypt-files-using-php/
The second solution i think is better in this case.
i hope i was helpful.
Thanks for the hint, I thought about something like this, too. As this solution would be a breaking change, I would add this feature for the upcoming 3.2 release.
you're welcome. If is not a problem for you, can you mark as valid this submission?
feel free to contact me for any help.
Please feel free to review the patch. I used libsodium as mcrypt is deprecated in PHP 8. As it's a breaking change for the current 3.1 release cycle I added the verification of backups for the upcoming 3.2 release
Hello @Thorsten, i reviewed the last commit code and now the backup/restore features seems ok. Very good job! In the next few days I will test it directly on my servers.
@maintainer can I ask you if we can go ahead with the CVE request? @admin could we get CVE?
@mike993 just waiting for maintainer approval then we can go ahead with your CVE :)