Skip to content

Information Disclosure in JForum 2.1.X – Syntax

  1. Home
  2. blog
  3. Information Disclosure in JForum 2.1.X – Syntax

Information Disclosure in JForum 2.1.X – Syntax

Information Disclosure in JForum 2.1.X – Syntax

  • Blog
  • Blog
  • Share

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.


Version Tested: 2.1.8

CVE Number: CVE-2019-7550

Security Advisories: None

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=/
view sourceprint?
Connection: close<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “<a href=”http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd</a>”>

<div id=”lightbox”><a title=”Close” class=”top-close” href=”#”></a><!– == CMS MainContent (BEGIN) == –><div class=”MainContent”>The name admin is already in use, please choose something else</div><!– == CMS MainContent (END) == –></div>

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

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

The response doesn’t contain any failure information:

HTTP/1.1 200 OK
[SNIPPED]
Set-Cookie: jforum-secure-sso=””; Path=/
Connection: close<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “<a href=”http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd</a>”>

<div id=”lightbox”><a title=”Close” class=”top-close” href=”#”></a><!– == CMS MainContent (BEGIN) == –><div class=”MainContent”>0</div><!– == CMS MainContent (END) == –></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.

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 the response for a unique username.

Figure 1 – Burp Suite Pro Intruder Username Enumeration

The next step of an attack would be to see if the existing usernames have been reused from other sites that 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

by Moez Janmohammad | TEAMARES
February 8, 2019