Summary An attacker with admin privileges can upload an attachment containing JS code without extension and the application will render it as HTML which allows for XSS attacks.

Details When attachments are uploaded without an extension, the application renders it as HTML by default. Therefore allowing attackers to upload .html files containing javascript code to perform XSS attacks. The direct file path to the uploaded attachment is also easily obtainable as it is made up of substrings of the file's MD5 hashes.

PoC 1. Admin users can upload attachments containing XSS payloads in files without extensions to bypass the .html extension check. !image

2. Since the path of the uploaded file is built entirely on the file’s MD5 hash and the attachment directory, it is possible for an attacker to know the direct path of the uploaded file.

E.g file MD5 hash: 38fff51cb7248a06d6142c6bdf846831

URL will be: http://127.0.0.1/phpmyfaq/attachments/38fff/51cb7/248a0/6d6142c6bdf846831

- /attachments - /38fff (first 5 chars of MD5 hash) - /51cb7 (next 5 chars of MD5 hash) - /248a0 (next 5 chars of MD5 hash) - /6d6142c6bdf846831 (remaining chars of MD5 hash)

3. Even though the attachment was uploaded without a file extension, it is still rendered as .html, hence triggering the XSS payload. !image

Impact This allows an attacker to execute arbitrary client side JavaScript within the context of another user's phpMyFAQ session.

Summary There is a Path Traversal vulnerability in Attachments that allows attackers with admin rights to upload malicious files to other locations of the web root.

PoC 1. In settings, the attachment location is vulnerable to path traversal and can be set to e.g ..\hacked !image

2. When the above is set, attachments files are now uploaded to e.g C:\Apps\XAMPP\htdocs\hacked instead of C:\Apps\XAMPP\htdocs\phpmyfaq\attachments

3. Verify this by uploading an attachment and see that the "hacked" directory is now created in the web root folder with the attachment file inside. !image !image

Impact Attackers can potentially upload malicious files outside the specified directory.

Summary Due to insufficient validation on the contentLink parameter, it is possible for unauthenticated users to inject HTML code to the page which might affect other users. Also, requires that adding new FAQs is allowed for guests and that the admin doesn't check the content of a newly added FAQ.

PoC 1. Browse to ../phpmyfaq/index.php?action=add&cat=0 , enter https://test.com?p=<h1>HTMLINJECTION</h1> for the contentLink parameter. !image

2. Verify the HTML injection by viewing the FAQ itself, “All categories” → “CategoryName” → ”QuestionName”. !image

Impact Attackers can manipulate the appearance and functionality of web pages by injecting malicious HTML code. This can lead to various undesirable outcomes, such as defacing the website, redirecting users to malicious sites, or altering the content to deceive users. Additionally, unauthenticated HTML injection can compromise user privacy by displaying sensitive information or misleading content. It undermines the integrity of the application and erodes user trust, potentially resulting in loss of reputation and credibility.

Summary A SQL injection vulnerability has been discovered in the insertentry & saveentry when modifying records due to improper escaping of the email address. This allows any authenticated user with the rights to add/edit FAQ news to exploit this vulnerability to exfiltrate data, take over accounts and in some cases, even achieve RCE.

PoC 1 - SQL Injection at insertentry: 1. Browse to “/admin/?action=editentry”, edit record and save. Intercept the POST request to "/admin/?action=insertentry" and modify the email and notes parameters in the body to the payloads below: a. email=test'/@email.com b. notes=/,1,1,1,1,null,1);select+pgsleep(5)--

2. Send the request and notice the pgsleep(5) command is executed with a time delay of 5 seconds in the response. This verifies that the SQL injection vulnerability exists. !image

PoC 2 - SQL Injection at saveentry 1. Browse to “/admin/?action=editentry”, edit record and save. Intercept the POST request to "/admin/?action=saveentry" and modify the email and notes parameters in the body to the payloads below: a. email=test'/@email.com b. /,notes=(select+pgsleep(5))-- 2. Send the request and notice the pgsleep(5) command is executed with a time delay of 5 seconds in the response. This verifies that the SQL injection vulnerability exists. !image

Impact The SQL injection vulnerability discovered allows authenticated users with appropriate privileges to execute malicious SQL queries, potentially leading to data exfiltration, account takeover, and even remote code execution. Attackers can exploit the vulnerability to read sensitive data from the database, such as user credentials and system files, compromising the confidentiality and integrity of the system. Moreover, successful exploitation may enable attackers to gain unauthorized access to user accounts or execute arbitrary commands on the server, impacting both system administrators and end users.

Summary By manipulating the news parameter in a POST request, an attacker can inject malicious JavaScript code. Upon browsing to the compromised news page, the XSS payload triggers.

PoC 1. Edit a FAQ news, intercept the request and modify the news parameter in the POST body with the following payload: %3cscript%3ealert('xssContent')%3c%2fscript%3e 2. Browse to the particular news page and the XSS should pop up. !image

Impact This allows an attacker to execute arbitrary client side JavaScript within the context of another user's phpMyFAQ session

Summary The category image upload function in phpmyfaq is vulnerable to manipulation of the Content-type and lang parameters, allowing attackers to upload malicious files with a .php extension, potentially leading to remote code execution (RCE) on the system.

Details In the file upload function of the category image, the Content-type can be manipulated to return an empty string for the extension and the lang parameter can be set to .php. to allow an attacker to save a file as .PHP. This allows the uploading of web shells which could lead to RCE on phpmyfaq.

PoC 1. Generate a fake .GIF file that contains a php command using the tool gifsicle a. Cmd: gifsicle < test1.gif --comment "<?php system('whoami'); ?>" > output.php.gif !image

b. The contents of the file should look like this: !image

2. Browse to “../phpmyfaq/admin/?action=addcategory” and upload the fake .GIF file !image

3. Intercept the upload request and modify the params below and forward it: 3a. lang parameter to .php. 3b. Content-Type parameter from image/gif to image/gif2

!image

4. Browse to the “/phpmyfaq/images” directory and notice that our fake .GIF file has been uploaded as a PHP file with the category number as its filename. !image

5. Now we just need to browse to “../phpmyfaq/images/category-<ID>-.php” and see the results of our whoami command. Hence, verifying that RCE is achieved. !image

Impact Attackers can upload malicious files containing executable code, allowing them to take control of the vulnerable system. This enables them to execute arbitrary commands, steal sensitive data, disrupt services, and potentially escalate their privileges, posing significant risks to the security and integrity of the system and its data.

Occurrences In CategoryImage.php line 124, the getimagesize and isValidMimeType functions can be bypassed by uploading a fake .GIF file generated by gifsicle. !image

In CategoryImage.php line 85, the getFileExtension function returns an empty string when the content type doesnt match any of the following 3 mappings. Hence, its possible to just supply an invalid content type such as image/gif2 in step 3 of the PoC to make the function return an empty string. !image

In CategoryImage.php line 66, the getFileName function generate the filename by concatenating the categoryId, categoryName and fileExtension together. This allows us to save the file with a .PHP extension. (It should be possible to just set the payload in step 3 above to just .php but it doesnt work and im not sure why..) !image

Suggested Fix I believe one of the ways to solve this vulnerability is by forcing the getFileExtension function to return one of the 3 mimetype instead of an empty string. This ensures that the uploaded file will have an image extension and will not execute as a PHP file.

Summary The email field in phpMyFAQ's user control panel page is vulnerable to stored XSS attacks due to the inadequacy of PHP's FILTERVALIDATEEMAIL function, which only validates the email format, not its content. This vulnerability enables an attacker to execute arbitrary client-side JavaScript within the context of another user's phpMyFAQ session.

Details Despite using PHP's FILTERVALIDATEEMAIL function, the email field does not adequately validate the content of the email address. This means that malicious input, such as JavaScript code, can be accepted and stored in the database without being detected. When the stored data is retrieved and displayed on web pages, it is not properly sanitized to remove or neutralize any potentially harmful content, such as JavaScript code which leads to Stored XSS.

PoC 1. Login as any user, go to the user control panel, change email to any valid email and intercept the request.

2. Modify the request’s email parameter to the following payload: "><svg/onload=confirm('XSS')>"@x.y !image

3. Send the request and see that the XSS is triggered in the user control panel page. !image

4. Also affects any user who browse to "../admin/?action=user&useraction=listallusers" !image

Impact This allows an attacker to execute arbitrary client side JavaScript within the context of another user's phpMyFAQ session.

Summary A SQL injection vulnerability has been discovered in the the "Add News" functionality due to improper escaping of the email address. This allows any authenticated user with the rights to add/edit FAQ news to exploit this vulnerability to exfiltrate data, take over accounts and in some cases, even achieve RCE.

Details The vulnerable field lies in the authorEmail field which uses PHP's FILTERVALIDATEEMAIL filter. This filter is insufficient in protecting against SQL injection attacks and should still be properly escaped. However, in this version of phpMyFAQ (3.2.5), this field is not escaped properly can be used together with other fields to fully exploit the SQL injection vulnerability.

PoCs 4 PoCs are demonstrated here to illustrate the potential impacts.

PoC 1 - Postgres Time Based SQLi 1. Login as admin or any user with the rights to view and save news. 2. Navigate to "../phpmyfaq/admin/?action=news", click on "Add news", fill in some data, send and intercept the request. 3. Modify the intercepted "/admin/?action=save-news" request to look like the SS below: 3.1 - Set the "authorEmail" field in the body to "test'/@email.com". 3.2 - Set the "linkTitle" field in the body to "/,1,1,1,1,1,1,1);select+pgsleep(5)--". 3.3 - Set the rest of the fields as empty and send the request. 4. Notice the 5s delay in the response time, indicating that the sleep function was executed, verifying the existence of the SQLi vulnerability. !image

PoC 2 - SQLi to Read Data from PostgresDB 1. Steps 1 and 2 are the same as PoC 1. 2. Modify the intercepted "/admin/?action=save-news" request to look like the SS below and send the request: 2.1 - Set the "authorEmail" field in the body to "test'/@email.com". 2.2 - Set the "linkTitle" field in the body to "/,1,1,1,1,1,1,1);SELECT+rememberme+FROM+faquser+limit+1+offset+1%3b--". !image (1)

PoC 3 - SQLi to Read Files from PostgresDB 1. Steps 1 and 2 are the same as PoC 1. 2. Modify the intercepted "/admin/?action=save-news" request to look like the SS below and send the request: 2.1 - Set the "authorEmail" field in the body to "test'/@email.com". 2.2 - Set the "linkTitle" field in the body to "/,1,1,1,1,1,(select+pgreadfile(CONCAT(CHR(67),CHR(58),CHR(92),CHR(87),CHR(105),CHR(110),CHR(100),CHR(111),CHR(119),CHR(115),CHR(92),CHR(119),CHR(105),CHR(110),CHR(46),CHR(105),CHR(110),CHR(105)))),1)--". (the CONCAT() and CHR() functions are used to bypass the escaping of single quotes, these characters in its decoded form is "select pgreadfile('C:\Windows\win.ini')") !image (2)

PoC 4 - SQLi to Shell It is also possible to obtain a shell if superuser is enabled on the postgres DB. These are the high level steps of the exploit chain:

1. Create a table called "cmdexec" to store the payload. 2. Create a function in postgres to store the command to write a web shell to the "../htdocs" directory. (This step is required as CONCAT() function cannot be used to bypass the step where; "COPY cmdexec FROM PROGRAM '<command>' " is run as it requires single quotes.) 3. Trigger the function to write the PHP web shell at "http://<URL>/shell.php" that takes in commands via the "?cmd=" parameter. 4. Send the Python reverse shell command via a GET request to launch the reverse shell.

The video demo and the Python PoC script can be accessed from this link: https://drive.google.com/drive/folders/1BFL8GHIBxSUxu0TneYf66KjFA0A4RZga?usp=sharing

Impact The SQL injection vulnerability discovered in the "Add News" functionality of the application allows authenticated users with appropriate privileges to execute malicious SQL queries, potentially leading to data exfiltration, account takeover, and even remote code execution. Attackers can exploit the vulnerability to read sensitive data from the database, such as user credentials and system files, compromising the confidentiality and integrity of the system. Moreover, successful exploitation may enable attackers to gain unauthorized access to user accounts or execute arbitrary commands on the server, impacting both system administrators and end users.

Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.1.17.

Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.1.17.

Sensitive Cookie in HTTPS Session Without 'Secure' Attribute in GitHub repository thorsten/phpmyfaq prior to 3.2.1.

Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.2.2.

Insufficient Session Expiration in GitHub repository thorsten/phpmyfaq prior to 3.2.2.

Cross-site Scripting (XSS) - Reflected in GitHub repository thorsten/phpmyfaq prior to 3.2.2.

Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.2.1.

Cross-site Scripting (XSS) - DOM in GitHub repository thorsten/phpmyfaq prior to 3.1.18.

Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.1.18.

Cross-site Scripting (XSS) - DOM in GitHub repository thorsten/phpmyfaq prior to 3.1.18.

Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.1.18.

Unrestricted Upload of File with Dangerous Type in GitHub repository thorsten/phpmyfaq prior to 3.1.18.

Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.1.16.

Improper Neutralization of Formula Elements in a CSV File in GitHub repository thorsten/phpmyfaq prior to 3.1.16.

Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.1.14.

Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.1.14.

Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.2.0-beta.

Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.2.0-beta.

Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to version 3.1.13.

Cross-site Scripting (XSS) - Reflected in GitHub repository thorsten/phpmyfaq prior to 3.1.13.

Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.1.13.

Improper Access Control in GitHub repository thorsten/phpmyfaq prior to 3.1.13.