User Enumeration in api_check_user_exists Endpoint

[ivaldivieso]

On this part of code: https://github.com/jhuckaby/Cronicle/blob/master/lib/api.js#L43C2-L55C3

There is a vulnerability in the api_check_user_exists function within the Cronicle application that allows an attacker to enumerate valid usernames via the API endpoint /api/app/check_user_exists. The endpoint responds differently depending on whether the username exists, making it easy for an attacker to determine valid usernames.

Steps to Reproduce:

1. Make a GET request to the following endpoint:
   GET https://<your_domain>/api/app/check_user_exists?username=<desired_username>
   Example:
   GET https://acuris-cron.staging.services.acuris.com/api/app/check_user_exists?username=admin

2. The response will reveal if the username exists:

• If the username exists:

{"code":0,"user_exists":true}

• If the username does not exist:

{"code":0,"user_exists":false}

Impact:
This vulnerability enables attackers to enumerate usernames by sending repeated requests to the API. This could facilitate further attacks such as brute-force password guessing, credential stuffing, or account enumeration attacks.

[jhuckaby]

That API is necessary for the green checkmark that shows you if your username is available when creating an account:

How do other apps accomplish this? Honestly, I do not know.

[ivaldivieso]

Hello,

Thank you for your response. However, I would like to clarify that the affected API endpoint (/api/app/check_user_exists) can be accessed without authentication.

By making a simple unauthenticated request:

curl -X GET "https://acuris-cron.staging.services.acuris.com/api/app/check_user_exists?username=admin"

Since there is no authentication required to access this endpoint, an attacker can exploit it to enumerate valid usernames using automated tools. This exposure could facilitate further attacks, such as credential stuffing, brute-force attempts, or social engineering.

Could you confirm if there are plans to restrict access to this API or implement mitigations such as authentication, rate-limiting, or generic responses?

Looking forward to your feedback.

Best regards,
Ivan Valdivieso

[jhuckaby]

Ah, I see. Yeah, that's because the user authentication library that Cronicle uses, pixl-server-user, has a free_accounts option (disabled by default):

https://github.com/jhuckaby/pixl-server-user#free_accounts

If this is set to true, then users can sign up for free. Obviously this would only work in a fully trusted, closed network, but you get the idea. Anyway, that's why that API has no auth, so it can work on the user "self-signup" page.

I will add a condition auth check in the next version, that only runs if free_accounts is false.

[jhuckaby]

Fixed in Cronicle v0.9.77.