Quote-Number Enumeration Oracle Yields Full Customer PII Across All Sibling Brands
The Risk
An anonymous visitor on the internet could guess insurance quote numbers in bulk and learn the matching customer's full identity for any guess that hit, including legal name, date of birth, residential address, in-force policy number, mortgagee bank, and saved payment card details. Quote numbers follow a short, predictable pattern, so guessing returned a hit on between half and four-fifths of attempts in known-dense ranges. There was no challenge and no slowdown. The same single endpoint exposed customers across all five sibling brands.
The Vulnerability
The customer-facing retrieve-quote flow has a deliberate ownership check: a customer must supply their date of birth and postcode to resume their quote. A variant of the retrieve-token endpoint skipped that check entirely when invoked with a particular query flag. Any unauthenticated client supplying only a candidate quote number received a valid per-customer retrieve token when the quote existed and a 404 when it did not. Response body length also distinguished the two cases, so status normalisation alone would not have closed the oracle.
The endpoint required no session, no challenge, and applied no rate limit. The bypass worked across all five sibling brands. Quote numbers follow a low-entropy pattern with several known-dense prefixes, making the keyspace tractable to enumerate fully.
The Attack
Mint a token
One unauthenticated call returned a bearer token. No login, no challenge.
Probe the oracle
For each candidate quote number, the retrieve-token endpoint returned HTTP 200 with a token when the quote existed and HTTP 404 when it did not. A 14-candidate window returned 7 hits across three sibling brands and both product classes (home and car) at one request per second with no rate limit and no challenge. Aggregate hit rate across four known-dense prefixes was 62 percent.
Chain each hit to full PII
For each valid quote number, the retrieve-token, retrieve-details, and product-specific endpoints chained together to return the customer's full record. For a home record this included primary policyholder name and date of birth, email, mobile, secondary policyholder name and date of birth, full residential address, in-force policy number, building sum insured, mortgagee bank in plaintext, contents sum insured, security-alarm status, annual premium, and saved-payment details including cardholder name, payment-card type, last four digits of the card, full expiry date, and the stored payment-instrument token.
Body-length backup oracle
Even if response status codes were normalised to 200 across the board, the response body size still distinguishes valid from invalid quotes. Valid quotes return a small token envelope. Invalid quotes return a larger error envelope. Remediation must address both signals.
Cross-brand reach
A wider re-verification across multiple prefixes surfaced quotes spanning all five sibling brands through this one endpoint. Aggregator-sourced quotes expose third-party-originated data through the same endpoint.
The Impact
- Full identifiable customer PII recoverable starting from zero attacker input. Iterate the small quote-number keyspace, chain each hit through the unauthenticated retrieve flow.
- Combination of full name, date of birth, residential address, in-force policy number, mortgagee bank, and saved payment instrument is sufficient for identity theft, targeted-burglary planning (home-security alarm posture disclosed), and fraudulent policy modification.
- Cross-brand reach. Customers of all five sibling brands are exposed through one endpoint on one domain.
- Mass-exploitable. At the observed sustained one request per second with zero throttling, that is 86,400 candidates per source per day, multiplied across prefixes and sources.
- Direct regulatory exposure under the Australian Privacy Act and the notifiable data breaches scheme.
Remediation
- Always validate the date of birth and postcode in the request body against the quote being retrieved, regardless of any query flag. The flag should be removed from the API.
- Normalise responses so that valid and invalid quote numbers cannot be distinguished by status code or by body length.
- Apply strict per-source rate limiting and anomaly alerting on the retrieve-token endpoint. Sustained one-request-per-second probing should not pass.
- The downstream product-specific retrieve endpoints should not return saved-payment details or mortgagee data on an unauthenticated retrieve path. These fields belong behind an authenticated customer session.
- Increase the entropy and randomness of quote numbers in future issuance, so that even with the verification fix the keyspace is not blindly enumerable.
- Forensic review of access logs to identify the affected customer set for breach-notification purposes.