I recently took part in a live bug hunting event:
As part of these event, we reviewed the product Navigate CMS. In order to perform this review I setup a local instance of this tool, using version v2.9 r1433 (2020/06).
While taking part of this event, I managed to help identify several findings:
- User enumeration
- Session information leakage
- User password reset vulnerability
- Store Cross-Site Scripting (XSS)
- Reflected Cross-Site Scripting (XSS)
User Enumeration - CVE-2020-14016
Navigate CMS has a Forgot password? feature, which allows a user to reset their password if they forgot what their current password is.
In order to use this feature the user supplies either their username associated with their account, or the email address which is associate with their account.
When entering the username or email address of a non-existent user, it produces and error stating that the user couldn't be found:
When reviewing the HTTP response it can clearly be seen that the HTTP response responds with the message not_found in the response body:
POST /navigate/login.php HTTP/1.1 Host: 192.168.0.130 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0 Accept: */* Accept-Language: en-GB,en;q=0.5 Accept-Encoding: gzip, deflate Content-Type: application/x-www-form-urlencoded; charset=UTF-8 X-Csrf-Token: 236c7e771d9d104865dd84a095910bdeef4434443f7c55be1cdff82bb6037b7f X-Requested-With: XMLHttpRequest Content-Length: 36 Origin: http://192.168.0.130 Connection: close Referer: http://192.168.0.130/navigate/login.php Cookie: PHPSESSID=6ls0ko8kgh9fikeqt0a78cmp0t; navigate-tinymce-scroll=%7B%7D; NVSID_ff0d48a629500e15=6ls0ko8kgh9fikeqt0a78cmp0t action=forgot-password&value=invalid
HTTP/1.1 200 OK Date: Wed, 10 Jun 2020 16:55:33 GMT Server: Apache/2.4.41 (Ubuntu) Set-Cookie: NVSID_ff0d48a629500e15=6ls0ko8kgh9fikeqt0a78cmp0t; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate Pragma: no-cache Set-Cookie: NVSID_ff0d48a629500e15=6ls0ko8kgh9fikeqt0a78cmp0t; expires=Wed, 10-Jun-2020 17:55:33 GMT; Max-Age=3600; path=/; domain=192.168.0.130; HttpOnly; SameSite=Lax Set-Cookie: PHPSESSID=6ls0ko8kgh9fikeqt0a78cmp0t; expires=Wed, 10-Jun-2020 17:55:33 GMT; Max-Age=3600; path=/; domain=192.168.0.130; HttpOnly; SameSite=Lax X-Csrf-Token: 236c7e771d9d104865dd84a095910bdeef4434443f7c55be1cdff82bb6037b7f Vary: Accept-Encoding Connection: close Content-Type: text/html; charset=utf-8 Content-Length: 9 not_found
Using this one can either use something such as a wordlist to try enumeration which users exist on the system:
Session Information Leakage - CVE-2020-14017
Navigate CMS stores session information in plaintext files on the server in the webroot. These files are then publicly available to un-authenticated users. As part of the setup, there is an option to copy/install the appropriate .htaccess files used to prevent access to this directory and files. However it appears that this doesn't prevent access with later versions of Apache HTTPD.
Depending how the server has been configured, it could be possible to view the contents of the directory:
Upon navigating to one of the session files (most preferably the most recent), one is able to view details and sensitive information (such as CSRF tokens) which are associated with the session:
If directory listing has been disabled on the webserver (such as via Apache configuration), an attacker is still able to access these files without authentication, however they would need to bruteforce the session IDs to find existing sessions and thus the existing session files:
User Password Reset Vulnerability - CVE-2020-14015
The Forgot password? feature allows a user to reset their password. When a user successfully enters their username or email address in the forgot password feature, an email is sent the user which contains a password reset link. This link contains an activation code, which allows the user to then reset the password associated with their account.
When providing an invalid code, the user is presented with the login screen:
However a flaw exists when no code is presented, the user is prompted for a new password:
And setting the password results in success:
Upon further investigation, the reason is that when a user is created, their account is created without an activation code:
When no code is supplied in the password reset process flow, the first user without an activation key will be matched and thus have their password reset.
Stored Cross-Site Scripting - CVE-2020-14018
While there is HTML encoding on User field in the Users / Edit page, there is not sufficient encoding on the E-Mail field, these leaves it vulnerable to a store XSS vulnerability:
As stated the User field is appropriate HTML encoded, preventing any XSS vulnerability from this field on this page:
However the E-Mail field is does not have sufficient HTML encoding, resulting in a stored XSS vulnerability:
This stored XSS vulnerability is persisted and present from both the User as well as the E-Mail fields when viewing users on the Users page:
Reflected Cross-Site Scripting - CVE-2020-14014
On the landing page once the user authenticates, there is a resource /nagivate.php which can take the query parameter fid. The value from this parameter is reflected back on the page, without having appropriate validation or HTML encoding. This makes the page vulnerable to reflected XSS:
This is since the value is reflected to a link in the top right corner of the page:
Fixed as of version v2.9.1 r1487 (2020/06).
- 10 June 2020 - Initial contact with the vendor, indicating wish to share findings with vendor before disclosing publicly.
- 11 June 2020 - Received response from vendor expressing wish to obtain information about findings.
- 11 June 2020 - Forwarded findings to vendor.
- 17 June 2020 - Vendor shared fixes with myself and asked me to review the fixes.
- 21 June 2020 - Reviewed fixes and confirmed with vendor.
- 22 June 2020 - Vendor confirmed new version and approved public disclosure of findings.