Authenticated Connection Validation Exposes an Internal TCP Timing Oracle

Sanitized disclosure. The target name, domain, endpoint path, report identifier, tenant identifiers and authentication material have been removed. The timings and final triage state are preserved because they are the evidence relevant to this report.

Executive summary

An authenticated connection-validation feature accepted a user-controlled database connection URI and attempted to resolve and connect to its destination from the service’s backend network position. Although every authenticated probe returned the same generic failure body, the response time changed consistently across destination ports.

The behavior created a limited blind SSRF primitive: a project user could infer destination-dependent TCP behavior inside the service environment. The test did not retrieve internal response content or demonstrate access to credentials, metadata, another tenant or a sensitive management interface.

Affected workflow

The affected workflow was an authenticated migration or connection-checking function. The public path is intentionally withheld; the relevant request shape was equivalent to:

POST /api/[redacted]/connection-validation
Content-Type: application/json
Authorization: Bearer [redacted]
X-Bug-Bounty: ilias1988

{
  "connection_uri": "postgres://test:test@[internal-service-name]:[port]/test"
}

Only an owned account and an owned test project were used. Request volume was limited to three samples per test case.

Methodology

The validation used one stable internal service name and changed only the destination port. This minimized variables and made the timing comparison easier to interpret.

1. Authenticate with the dedicated bug bounty test account.
2. Submit the same connection-validation request three times for port 443.
3. Repeat for ports 81 and 5432, changing no other request fields.
4. Record HTTP status, normalized response-body hash and elapsed time.
5. Send the same request without authentication as a negative control.
6. Compare medians instead of relying on a single request.

Observed evidence

All nine authenticated requests returned the same generic application-level failure body. The useful signal was the repeatable timing separation of approximately one second between port 443 and the two comparison ports.

Security impact

The demonstrated impact was narrow but real: an authenticated user could use the backend as a timing oracle to classify destination-dependent TCP behavior that was not observable directly from the public internet.

This could assist internal service discovery when combined with a carefully selected list of hostnames and ports. However, this report did not establish:

• retrieval of internal HTTP or database content;
• access to cloud metadata or orchestration APIs;
• credentials, tokens or secrets;
• cross-tenant access;
• state-changing requests;
• denial of service or remote code execution.

Recommended remediation

1. Parse the connection URI using a strict, scheme-aware parser before any DNS lookup or socket operation.
2. Resolve the hostname and reject loopback, link-local, private, carrier-grade NAT, multicast and otherwise reserved address ranges for both IPv4 and IPv6.
3. Revalidate every resolved address immediately before connection and after any redirect or resolution change.
4. Apply egress firewall rules so the validation worker can reach only the external destinations and ports required by the product.
5. Return constant, generic errors and enforce a uniform timeout to reduce timing and error-class side channels.
6. Add audit logging and rate limits for repeated connection checks across many hosts or ports.

Program outcome

This outcome is important professionally: the technical observation was reproducible, but bounty eligibility is determined by first valid report and root cause—not by being the first person to reproduce the issue in a different deployment.

Final response evidence

The screenshot below records the final state while deliberately concealing the target and report identifier.