Skip to content

TurboMeeting: Boolean-based SQL Injection

Critical
rcorrea35 published GHSA-vx5j-8pgx-v42v Jul 24, 2024

Package

TurboMeeting (R-HUB Communications)

Affected versions

<= 8.x (all)

Patched versions

None

Description

Summary

A Boolean-based SQL injection vulnerability in the "RHUB TurboMeeting" web application. This vulnerability could allow an attacker to execute arbitrary SQL commands on the database server, potentially allowing them to access sensitive data or compromise the server. Exploitation of this vulnerability, along with “Insecure Password Reset Mechanism” and “Command Injection in Certificate Signing Request”, allowed Mandiant to authenticate to the web application as the “admin” user and obtain remote command execution as “root”.

Severity

High - An attacker could gain access to sensitive information, modification or deletion of data, disruption of database operations, access to the underlying operating system.

Proof of Concept

The application was removing the semicolon, dash, underscore, and space characters. If present within the meeting_id parameter's value before adding them to the SQLite query. As spaces were essential to the injection, we developed an exploitation proof-of-concept (PoC) script in Python, which allowed the retrieval of the admin user's SHA1 hashed password by a series of Boolean-based database queries. The script automates the extraction of the password through this injection query:

1'/**/OR/**/1=2/**/UNION/**/select/**/password/**/from/**/employee/**/where/**/email='admin'/**/AND/**/substr(password,{i},1)='{char}'/**

This allows the retrieval of the password hash of the admin user, character by character.

Endpoint: http://HOST/as/wapi/vmp POST request with meeting_id=$SQLi parameter

Further Analysis

To address this vulnerability, the application's code should be modified to properly sanitize all user-supplied input before using it in SQL queries. This can be achieved by using prepared statements with parameterized queries, or by using appropriate escaping functions to ensure that special characters in user input are treated as literal values rather than SQL commands.

Timeline

Date reported: 4/17/2024
Date fixed:
Date disclosed: 7/24/2024

Severity

Critical

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

CVE ID

CVE-2024-38289

Weaknesses

Credits