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.
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:
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: close </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>http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd
For a user that doesn’t already exist, like “Section8”:
The response doesn’t contain any failure information:
HTTP/1.1 200 OK [SNIPPED] Set-Cookie: jforum-secure-sso=""; Path=/ Connection: close </a>"> <div id="lightbox"><a title="Close" class="top-close" href="#"></a><div class="MainContent">0</div></div>http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd
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.
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.
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.
2018-12-17 – Vulnerability Discovered
2019-02-05 – Vendor Disclosure
2019-02-06 – CVE Created