Tiny File Manager Path Traversal Recursive Directory Listing and Absolute Path File Backup Copy
CVEID: CVE-2020-12102, CVE-2020-12103
CVSSv3: 7.7 (High), 7.7 (High)
Affected Products and Versions: Tiny File Manager – 2.4.1
Two security issues were found in Tiny File Manager (2.4.1).
Both vulnerabilities are exploitable only while authenticated as a non-readonly user, or while authentication is disabled.
The first one (CVE-2020-12102) is a Path Traversal Recursive Directory Listing that allows to enumerate files and directories outside the scope of the application via a Path Traversal attack.
The second one (CVE-2020-12103) is an Absolute Path File Backup Copy that allows to create backup copies of files outside the scope in the same directory in which they are stored.
Both vulnerabilities are exploitable by sending a specially crafted HTTP POST request.
Proof of Concept
As a Proof of Concept there follows a write-up in which we’re going to combine both vulnerabilities to enumerate PHP files in the webserver and view their source code in clear.
After installing Tiny File Manager locally (by cloning the repository inside /var/www/html), we’re going to configure the application scope to the files subfolder by editing the $root_path variable.
Then we’re going to create dummy files inside of it as well. As you can see in the following picture this is the application scope (/var/www/html/files).
Now in order to exploit these vulnerability we need to be authenticated, so we make a POST request using default credentials and we’re going to use the session cookie assigned.
Once authenticated we’re going to exploit the first vulnerability by sending an HTTP POST request structured as follows:
POST /tinyfilemanager/tinyfilemanager.php?p= HTTP/1.1 Host: 127.0.0.1 Content-Type: application/x-www-form-urlencoded Content-Length: 27 Cookie: filemanager=apak2kmrti634ncftvj6jnj6g3 ajax=1&type=search&path=../
using a Path Traversal attack (by setting ../ as path parameter) to enumerate files and directories outside the application scope. As you can see in the following picture the attack worked: the server responded with a JSON that recursively lists all the files inside the directory one level outside the application scope, listing the content of /var/www/html including the Tiny File Manager PHP source file (tinyfilemanager.php).
Then in order to read its source code in clear we’re going to create a backup copy of it by sending another HTTP POST request structured as follows:
POST /tinyfilemanager/tinyfilemanager.php?p= HTTP/1.1 Host: 127.0.0.1 Content-Type: application/x-www-form-urlencoded Content-Length: 78 Cookie: filemanager=apak2kmrti634ncftvj6jnj6g3 ajax=1&type=backup&path=/var/www/html/tinyfilemanager&file=tinyfilemanager.php
using absolute path on parameter path to bypass the application scope. As you can see in the following picture, a backup file was created as response of this request.
This file is an identical copy of the file we chose, but with a .bak extension, which allows us to read its content in plaintext without PHP interpreting it.
In fact, as you can see in the following picture, the content of the created .bak file is the source code of Tiny File Manager application in plaintext.
So, we’ve showed how to retrieve this application’s source code by exploiting these vulnerabilities, but now we’re going to show how to retrieve other PHP files’ source code in the webserver.
This time our target is test90234482.php. By accessing to it with a simple GET request, all we see is just this message.
But by creating a backup copy and accessing to it via a HTTP GET request we can see its hidden content, normally invisible to client-side users.
In conclusion, these two vulnerabilities if used in combination can lead to multiple issues, for instance Complete Information Disclosure by enumerating and reading potentially every PHP file in the webserver, just like we did in this write-up.
Remediation: Update to Tiny File Manager version 2.4.2
27/03/2020 – Initial vendor contact
27/03/2020 – Vendor acknowledged the vulnerability
23/04/2020 – Vendor agreed to further discuss the problem and to coordinate the disclosure
14/05/2020 – Vendor publicly confirmed the issue
18/05/2020 – Vendor released a fixed version (2.4.2)
Discoverer: Michele Di Bonaventura <firstname.lastname@example.org>