Horizon Alert
Summary of the vulnerability and why it matters
This CVE describes a vulnerability in Hiperdino's REST API where an inadequate access control mechanism could allow an attacker to enumerate customer contact details using a static bearer token. This information disclosure occurs because a public endpoint for checking customer status returns associated email and telephone numbers without sufficient authentication or rate limiting.
- Customer data can be exposed through the API.
- Confirms the need to verify if our systems use this API.
- Understand exposure and take appropriate action.
Attack Path
How an attacker could exploit the issue
An attacker could begin by obtaining a static bearer token for the Hiperdino REST v1.0 API, which is exposed publicly without requiring strong authentication or rate limiting. By sending a telephone number or email address to the 'customer/check' endpoint, an attacker can enumerate contact details for registered customers, leading to an information disclosure.
- Requires a static bearer token.
- Public endpoint accepts customer data.
- Reveals user contact information.
Live Threat
Current exploitation, exposure, and threat context
This vulnerability in Hiperdino's REST API could expose registered customer contact information, specifically their email addresses and telephone numbers. This exposure could occur when an attacker, possessing a static bearer token, uses the public 'customer/check' endpoint to query a telephone number or email address belonging to a registered customer. The service would then return the associated contact details without requiring further authentication or rate limiting.
- Customer contact details (email, phone).
- Queries via a static bearer token.
- Information disclosure of contact details.
Operational Fix
Recommended remediation, mitigation, and detection steps
The Hiperdino REST API's inadequate access control poses a risk of user information disclosure. Application owners are likely responsible for this API, with support from platform and security teams. The first step is to identify all instances of the API, determine their reachability and business criticality, and confirm the accountable owner. Subsequently, a remediation plan should be developed based on the assessed risk.
- Application owners should lead the response.
- Verify API reachability and criticality.
- Plan remediation based on risk.
