PHPKB is a knowledge management software that allows you to share information with your customers and staff members. It reduces the time spent on customer support, improves the productivity of employees and saves precious time wasted on searching for information. A knowledgebase system enables your staff and customers to access information locally or online. Its powerful group-based permission structure with private categories makes it easy to target and deliver, content to specific groups of knowledge base readers. It has a lot of features such as creating, deleting and editing:
Articles and articles templates
Backup and restore
The knowledgebase can be managed by different types of users, each of them having different roles:
I’ve found different types of vulnerabilities, below there is an explanation for each of them:
Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end-user. An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page. There are different types of XSS:
Reflected attacks are those where the injected script is reflected off the web server, such as in an error message, search result, or any other response that includes some or all of the input sent to the server as part of the request. When a user is tricked into clicking on a malicious link, submitting a specially crafted form, or even just browsing to a malicious site, the injected code travels to the vulnerable web site, which reflects the attack back to the user’s browser.
Persistent XSS attacks are possible when a website or web application stores user input and later serves it to other users. An application is vulnerable if it does not validate user input before storing content and embedding it into HTML response pages. Attackers use vulnerable web pages to inject malicious code and have it stored on the webserver for later use. The payload is automatically served to users who browse web pages and executed in their context. Thus, the victims do not need to click on a malicious link to run the payload (as in the case of Reflected XSS). All they have to do is visit a vulnerable web page.
Blind XSS vulnerabilities are a variant of persistent XSS vulnerabilities. They occur when the attacker input is saved by the web server and executed as a malicious script in another part of the application or in another application. For example, an attacker injects a malicious payload into a contact/feedback page and when the administrator of the application is reviewing the feedback entries the attacker’s payload will be loaded. The attacker input can be executed in a completely different application (for example an internal application where the administrator reviews the access logs or the application exceptions).
Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data, since the attacker has no way to see the response to the forged request;
Remote Code Execution: is a vulnerability that can be exploited if user input is injected into a file or a string and executed (evaluated) by the programming language’s parser. A Remote Code Evaluation can lead to a full compromise of the vulnerable web application and also web server;
Arbitrary File Download: many web applications have file download sections where a user can download one or more files of his choice. If the input is not properly sanitized before being used to retrieve files from the server, it can be exploited to download arbitrary files from the system via directory traversal attacks;
Arbitrary Folder Deletion (which is an uncommon vulnerability) happens when an attacker can traverse directories (go to upper directories) and delete any folders he wants. This could have catastrophic effects as an attacker could delete the whole web application, delete important folders from the operating system, delete the folder that contains the database or personal information and so on;
Arbitrary Files and Folder Listing: this vulnerability allows an attacker to list some (or all) filenames and folder currently stored in a webserver;
CSV Injection is known as Formula Injection, occurs when websites embed untrusted input inside CSV files. When a spreadsheet program such as Microsoft Excel or LibreOffice Calc is used to open a CSV, any cells starting with ‘=’ will be interpreted by the software as a formula. Maliciously crafted formulas can be used for three key attacks:
Hijacking the user’s computer by exploiting vulnerabilities in the spreadsheet software;
Hijacking the user’s computer by exploiting the user’s tendency to ignore security warnings in spreadsheets that they downloaded from their own website;
Exfiltrating contents from the spreadsheet, or other open spreadsheets.
Arbitrary File Renaming: (another uncommon vulnerability) allows a malicious user to rename files on the server (in PHPKB’s case only the filename, not the extension) causing a Denial of Service (DoS).
Code snippets will be presented in order to explain the vulnerabilities and related exploits/proof of concepts.
As we can see, user input is directly passed to file_get_contents without any filtering, we can use ../ to download files from upper directories. This proof of concept will download PHPKB’s configuration file, exposing SMPT and database credentials:
This file is called when the current logged in user tries to drop a file into the WYSIWYG editor. We are going to put our proof of concept file under the /js/ directory as there is no .htaccess file blocking the upload. To exploit this vulnerability, an attacker must set the imgMime POST parameter to image/php, the imgName POST parameter to ../js/example.php and the proof of concept file that is going to be dragged and dropped must contain executable code:
Blind Cross-Site Scripting (CVE-2020-10388)
Exploitable by: Anyone, even external users
Vulnerable file: include/functions-articles.php (linked to article.php, exploitable via the Referer header), triggered at admin/report-referrers.php
In the last step, the Referer header is saved into the database. The file admin/report-referrers.php allows a Superuser to check all the Referer headers that have been submitted to the knowledgebase:
Vulnerable file: admin/save-settings.php allows overwriting, exploit code stored at admin/include/configuration.php, triggered at index.php (or any file that includes admin/include/configuration.php)
We can trigger Remote Code Execution thanks to PHP’s built-in system(); function. The following proof of concept will show the output of the command “dir”:
Out of Band (blind) Authenticated Remote Code Execution (CVE-2020-10390)
Exploitable by: Superuser
Vulnerable file: include/functions-article.php, triggered after saving the new pdf generator path at admin/save-settings.php (different vector than the authenticated remote code execution I just described)
The new wkhtmltopdf_path is placed inside the configuration file, from now on, it can be referenced in other parts of the web application. The official website of wkhtmltopdf says:
wkhtmltopdf and wkhtmltoimage are open source (LGPLv3) command line tools to render HTML into PDF and various image formats using the Qt WebKit rendering engine. These run entirely “headless” and do not require a display or display service.
PHPKB has a feature that allows anyone to generate a pdf copy of an article, managed by export.php:
Digging into include/functions.php, we find a reference to another include:
Let’s take a look at the new include:
This remote code execution is blind: the attacker can execute code but is unable to see the results of the executed code. In order to confirm the vulnerability, we are going to craft a proof of concept that will execute a ping request to our server:
Reflected Cross-Site Scripting in every admin page (CVE BLOCK GOING FROM CVE-2020-10391 TO CVE-2020-10456)
Exploitable by: Superuser/Editor/Writer
Vulnerable file: admin/header.php
The Cross-Site Scripting is triggered in these webpages:
For example, let’s analyze admin/add-article.php, one of the list items written above:
In the last step the comment is saved into the database without being sanitized. The file admin/manage-comments.php allows a Superuser/Editor to check all the comments that have been submitted to the knowledgebase:
“AssetManager”, a small utility implemented by PHPKB, is used to manage all the files that have been uploaded. We have an option to upload files into different folders that are fixed by default. Inside the AssetManager there is an option to change the current working directory to the fixed ones, however there isn’t any check done on the back-end so we can tamper the request. This vulnerability arises because everytime we change the current working directory, the AssetManger shows all the files in that folder; this is the request that is being sent when we try to change the directory into a fixed one:
We traverse directory by injecting our payload into the POST parameter inpCurrFolder; I’ve created a folder called test in the root directoy of my drive and I’m going to use this proof of concept to show the vulnerability: