NexusPHP: SureCloud Security Review Identifies Authenticated and Unauthenticated Vulnerabilities
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:
- CVE2022-46887 – Unauthenticated SQL Injection
- CVE2022-46889 – Authenticated Stored Cross-Site Scripting
- CVE2022-46888 – Unauthenticated Reflected Cross-Site Scripting
- CVE2022-46890 – Weak Access Control
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.
What is NexusPHP?
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.
What is an SQL Injection?
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:
- Results in output – Occurs when the output from the manipulated query is reflected in the application’s response via an error message or in the page content, making it very easy to identify this type of vulnerability
- Blind – Occurs when no output data or error message is returned in the application’s responses. The extraction of sensitive data can still happen via the use of time-based functions embedded in the DBMS
CVE2022-46887 – Unauthenticated SQL Injection
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
This behavior is caused by the way the ‘consur’ parameter is handled in line nine of the file, /public/takeconfirm.php:
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:
Privileges: Staff Member
Proof of concept:
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’]) . “)”);
Privilege: Staff Member
Proof of concept:
POST /nowarn.php HTTP/1.1
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__);
How do you prevent SQL Injections?
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:
- The principle of least privilege when connecting to a DBMS
- A Web Application Firewall (WAF), which prevents common payloads from exploiting the vulnerability
- Software Development Lifecycle (SDLC) methodology can help identify vulnerabilities before they are pushed into a production environment through the use of code analysis tools
What is Cross-Site Scripting (XSS)?
There are three types of XSS:
- Stored – This occurs when the user input is stored within a database and is returned unsanitized in later responses. E.g. every time a visitor opens a specific page in the vulnerable application
- Reflected – This happens when the user input (often in GET or POST parameter) is reflected back unsanitized, but only in the current response. Therefore, the XSS payload must be embedded in the request to be successful
CVE2022-46880 – Authenticated Stored Cross-Site Scripting
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
Content-Type: multipart/form-data; boundary=—————————538246582365809108635404342
Cookie: <valid session token>
Content-Disposition: form-data; name=”action”
Content-Disposition: form-data; name=”file”; filename=”test.srt”
Content-Disposition: form-data; name=”torrent_id”
Content-Disposition: form-data; name=”title”
Content-Disposition: form-data; name=”sel_lang”
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>
CVE2022-46888 – Unauthenticated Reflected Cross-Site Scripting
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:
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:
Proof of concept: /user-ban-log.php?q=admin”><svg/onload=alert(document.cookie)>
Privilege: user role
Proof of concept: /log.php?query=”><svg+onload=”alert(document.cookie)&search=all&action=dailylog
Privilege: user role
Proof of concept: /moresmilies.php?form=&text=’)”><svg+onload=alert(document.cookie)>
Privilege: user role
Proof of concept: /myhr.php?q=”><svg+onload=alert(document.cookie)>
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)
What’s the solution to XSS?
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.
What is Weak Access Control?
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:
- Horizontal access controls – These controls prevent User A from accessing/editing/deleting functionalities belonging to User B
- Vertical access controls – These controls prevent User A from accessing/editing/deleting functionalities belonging to a higher user privilege: e.g., an administrative user
- Context-dependent access controls – These controls prevent any kind of user from subverting the logic of one or multiple application functionalities: e.g., multi-step user journey
CVE2022-46890 – Weak Access Control
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
Cookie: <valid session cookies>
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:
Weak Access Control prevention
To prevent access control vulnerabilities, it is fundamental for programmers to implement the following principles:
- All backend pages must check the validity of a user’s session, via a cookie or authentication token, before serving any content
- When multiple user roles are involved, the web application must consider each role and check if the currently logged-in user is allowed to access such functionality. Do not rely on user input to check the role. A map or matrix on the server must perform this check
- Access to resources or data belonging to different users must validate if the currently logged-in user is the resource’s owner before being served
- Avoid using a predictable resource identifier (e.g., numeric or incremental IDs). It is widely recommended to use universally unique identifiers for UUIDs
- Before publishing the application, implement test cases in the SDLC so that each possible case scenario is tested and triaged in pre-production
Need some assistance?
To find out more about how SureCloud’s products or services can support the security posture of your application and identify vulnerabilities, contact a member of our team or visit www.surecloud.com.
Alternatively, take a look at the benefits of our Vulnerability Management Software, and how it can assist your cybersecurity team.