Authentication Bypass in FOSSBilling via Token Reuse

Executive Summary

This vulnerability affects FOSSBilling versions 0.5.6 through 0.7.2. When a client requests a password reset, the system creates a reset token valid for 15 minutes. However, if a reset token already exists and is still valid, subsequent password reset requests reuse the original token instead of generating a new one. This means the validity period is based on the first token's creation time, not the most recent request.

As a result, an attacker who obtained the original reset link can continue to use it even after the victim requests a new password reset, because the original token is never invalidated or replaced.

The issue is fixed in version 0.8.0. Workarounds include configuring a reverse proxy to apply per-IP rate limiting on the reset-password endpoint and manually clearing expired reset records from the database.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can allow an attacker who has obtained a previous password reset link to reuse it beyond its intended expiration window, potentially gaining unauthorized access to a user's account.

Because the original reset token is not invalidated when a new reset is requested, the attacker can bypass the victim's attempt to secure their account by requesting a new password reset.

This could lead to account compromise, unauthorized access to sensitive billing and client management information, and potential misuse of the affected system.

Useful 0 Not Useful 0

Mitigation Strategies

To mitigate this vulnerability, you should configure a reverse proxy such as Nginx, Apache, or Cloudflare to apply per-IP rate limiting on the /client/reset-password endpoint. This helps minimize the window of opportunity for an attacker to reuse an existing password reset token.

Additionally, manually clear expired client_password_reset records from the database after a client reports a suspected compromise to ensure that old tokens are invalidated.

Upgrading to version 0.8.0 or later of FOSSBilling is recommended, as this version patches the issue by properly handling token generation and invalidation.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability involves the reuse of an existing password reset token in FOSSBilling versions 0.5.6 through 0.7.2 when multiple reset requests are made before the original token expires.

To detect this vulnerability on your system, you can monitor requests to the `/client/reset-password` guest API endpoint and check if multiple reset requests for the same client reuse the same token instead of generating a new one.

Since no specific detection commands or tools are provided, a general approach would be to log and analyze HTTP requests to the reset-password endpoint, looking for repeated tokens for the same client within the 15-minute validity window.

Additionally, inspecting the database table `client_password_reset` for multiple reset requests per client and verifying if tokens are being reused can help detect the issue.

No explicit commands are provided in the available information.

Useful 0 Not Useful 0