Information Disclosure in JForum 2.1.x

Version Tested

2.1.8

CVE Number

CVE-2019-7550

Security Advisories

None

Background

While conducting a penetration test for a customer, I encountered an unused developer forum using JForum version 2.1.8 and started looking for vulnerabilities within the application.

Issue

When creating a new user within the application, the browser sends a GET request to the server to check if a username is taken. This process is done as soon as the user exits the username field, not when the form is submitted.

For example, to see if a user with the name “admin” exists, the browser will send a GET request that looks like this:

https://[REDACTED]/register/check/username?username=admin

For a username that already exists in the forum, the server’s response is:

HTTP/1.1 200 OK

[SNIPPED]

Set-Cookie: jforum-secure-sso=""; Path=/

Connection: closehttp://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd</a>">

<div id="lightbox"><a title="Close" class="top-close" href="#"></a><div class="MainContent">The name admin is already in use, please choose something else</div></div>

For a user that doesn’t already exist, like “Section8”:

https://[REDACTED]/register/check/username?username=Section8

The response doesn’t contain any failure information:

HTTP/1.1 200 OK
[SNIPPED]
Set-Cookie: jforum-secure-sso=""; Path=/
Connection: closehttp://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd</a>">
 
<div id="lightbox"><a title="Close" class="top-close" href="#"></a><div class="MainContent">0</div></div>

The requests also contain a session ID and a string of numbers that appears to be a timestamp. I removed both of those and didn’t receive any errors, so I proceeded to the next step of an attack.

A remote, unauthenticated attacker can automate sending many requests to find usernames that already exist. I used Burp Suite Pro Intruder to launch a similar attack to enumerate usernames on the forum within the customer environment.

image
usernames that were enumerated in the application using Burp

If we sort the responses by length, we can find usernames that already exist in the forum. We sort by length because the responses saying a username is already taken is noticeably longer than a response for a unique username.

The next step of an attack would be to see if the existing usernames have been reused from other sites which have password lists available. Since this developer forum wasn’t in use, the only accounts that existed were the admin accounts and a test account I had created.

Other Information

JForum is a forum application that is no longer being maintained by the developer. The source code was uploaded to GitHub and the developer stated that he will not apply fixes or develop new features. Since the repository was no longer being updated and the application is over 10 years old, I decided to forego the standard 90-day release embargo for this CVE.

Timeline

2018-12-17 – Vulnerability Discovered

2019-02-05 – Vendor Disclosure

2019-02-06 – CVE Created

 

Leave a Reply

Your email address will not be published. Required fields are marked *