Information Disclosure in JForum 2.1.X - Syntax | Critical Start
Prepare your business with On-Demand Breach Response
Webinar Series | Once More unto the Breach | Lessons Learned from Billion Dollar Breaches

Information Disclosure in JForum 2.1.X – Syntax


 

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=/
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, CRITICALSTART
February 8, 2019

Contact an MDR Specialist Today

Get in Touch
PREVIOUS RESOURCE
Path 11 Copy 2 Created with Sketch.
NEXT RESOURCE
Path 11 Copy 3 Created with Sketch.

Related Content

Categories