Endpoint

During security testing, the following OTP authentication endpoint was identified as vulnerable to user enumeration:

POST https://picker-api-gateway.redacted.com/api/v2/dash-picker/send-otp

This endpoint is used in the login workflow to send OTPs to registered picker accounts.

Where the Bug was Found

While testing the authentication flow, I observed that the API returned different responses depending on whether the submitted phone number was registered in the system.

The process: 1) Navigate to the picker login portal. 2) Enter a random phone number. 3) Intercept the OTP request using burpsuite. 4) Send the request to the OTP endpoint with multiple phone numbers. 5) Comparee the API responses.

For valid and registered phone numbers: -> The OTP was successfully triggered.

# Request

{
"phone":"9990999909"
}
#Response

{
  "statusCode": 0,
  "statusMessage": "OTP sent",
  "data": null,
  "tid": "xyzxyzxx-d0fc-49c8-8111-b9dc6af3e9e4",
  "sid": "reqId_5f56312a-xyzx-4c76-xyzx-7f936ab8085b_null_null_null",
  "deviceId": "null",
  "errorCode": null,
  "knowCourselist": []
}

For non-existing phone numbers: -> The API returned a clear message stating that the picker account did not exist.

#Request

{
"phone":"9097909890"
}
#Response

{
  "statusCode": 1,
  "statusMessage": "Picker 9097909890 does not exist",
  "data": null,
  "tid": "8e867a82-d0fc-49c8-8111-b9dc6af3e9e4",
  "sid": "reqId_5f56312a-bc28-4c76-847e-7f936ab8085b_null_null_null",
  "deviceId": "null",
  "errorCode": null
 }

This difference in response allowed an unauthenticated attacker to determine which phone numbers were registered on the platform.

Since the endpoint did not enforce effective rate limiting, this behavior could be automated using large datasets of phone numbers. This made it possible to build a database of valid user accounts at scale.

Reported the Bug and found to be Duplicate :)

Nevertheless, Happy Hacking :)