Exploiting Ssrf To Cloud Metadata

Exploiting SSRF to cloud metadata: reach is what makes it critical

A server that fetches a URL an attacker can influence is only dangerous if that fetch reaches something worth reaching. The highest-value target in a cloud environment is the instance metadata service, a link-local endpoint that returns the workload's credentials to anything that can make it a request. Turning an SSRF lead into a real finding means proving the request is steerable, reaches an internal target, survives the filters, and returns something that matters, usually a credential.

When to use

• A feature makes a server-side request to a URL, host, or address the user influences (a webhook, importer, link preview, URL parameter).
• You are triaging an SSRF lead and need to know its real impact.
• You are assessing exposure of a cloud workload's metadata and credentials.

Scope check

Test only infrastructure you are authorized to assess. Retrieve credentials solely from your own instances and revoke them after. If you can't name the authorization, stop.

The loop

1. Confirm the fetch is attacker-steered. Find the feature that makes a server-side request and confirm the destination, or part of it, comes from your input. If you cannot influence where the request goes, there is no SSRF; if you can, establish exactly which part (scheme, host, path, port).

2. Establish internal reach. Point the request at addresses the server should never fetch on your behalf: loopback, link-local, and internal ranges, and internal hostnames. Use an out-of-band listener to confirm the server actually made the request when the response is not reflected. Reaching an internal address at all is the core of the primitive.

3. Aim at the metadata endpoint. Direct the fetch at the cloud instance metadata address and its credential path. If the environment does not require the hardened, header-bound request flow, or the feature can be made to supply the required header, the endpoint returns the instance role's temporary credentials. Retrieving those is the critical outcome.

4. Defeat the filters. If an allowlist or blocklist stands in the way, test the known bypasses: DNS rebinding (a name that resolves to an allowed address on check and the target address on fetch), URL parser confusion (embedded credentials, fragments, redirects, alternate encodings that split the validator's view from the fetcher's), and redirects from an allowed host to an internal one. A filter that parses the URL differently from the HTTP client is bypassable.

5. Handle the blind case. When no response comes back, confirm exploitation out of band (an interaction on your listener) and exfiltrate small facts through timing or differential responses. A blind SSRF that reaches metadata is still critical if you can prove the request and stage credential retrieval to a channel you observe.

6. Rate and record. SSRF to instance credentials is critical, a foothold into the cloud account; SSRF limited to non-sensitive internal endpoints is lower but real. Kill the lead if the destination is not attacker-controlled, the fetch cannot leave an allowed set proven robust against rebinding and parser tricks, and metadata access requires a flow the feature cannot satisfy. Record with the exact reach proven.

What turns SSRF critical

• Reach decides impact. SSRF is only as serious as the most valuable thing the fetch can touch; metadata credentials are usually the top.
• The filter and the client must agree on the URL. Every bypass is a gap between what the validator sees and what the HTTP client fetches.
• DNS is mutable between check and use. An allowlist that resolves once and fetches later is defeated by rebinding.
• Blind is not safe. Out-of-band confirmation plus credential staging makes an unreflected SSRF fully exploitable.

Worked example (a confirm and a kill)

Confirm. An avatar-import feature fetches a user-supplied URL. It blocks internal literals, but a hostname under attacker control resolves to an allowed address at validation and to the link-local metadata address at fetch time (rebinding). The fetch retrieves the instance role credentials, which authenticate to the cloud account. Confirmed SSRF to metadata, critical, remediation = fetch only through a pinned-resolution allowlist, block link-local and internal ranges at the socket, and require the hardened metadata flow.

Kill. A link-preview service resolves the host once, pins that address for the actual connection, rejects loopback, link-local, and internal ranges at the socket layer, follows no redirects, and the metadata service requires a header-bound session the feature cannot produce. Rebinding and parser tricks cannot move the fetch off the pinned public address. Killed, kill_reason = "destination pinned after validation, internal ranges blocked at the socket, no redirects, hardened metadata flow unreachable."

Rationalizations to reject

• "We block internal IP literals." → Rebinding and hostnames bypass literal blocklists. Enforce at resolution and at the socket.
• "The response isn't shown to the user." → Blind SSRF is confirmable out of band and can still stage credential theft. Test it.
• "It only fetches images." → The fetcher does not enforce content type before connecting. The request still reaches the target.
• "It's behind a firewall." → The metadata endpoint is reachable from the instance itself, which is exactly what SSRF turns into a client.

Executing this in practice

You need the feature that fetches a URL, control over the destination or its DNS, an out-of-band listener for blind confirmation, and knowledge of the environment's metadata endpoint and its hardening. A proxy plus a controlled domain and listener works; the reach-and-filter analysis and the metadata objective are the method. Only target infrastructure you are authorized to test.

Related

• adjudicating-taint-paths - proving your input reaches the request destination.
• mapping-attack-surface - finding the features that make server-side requests.
• adjudicating-dependency-cve-reachability - the same reachability discipline, applied to a request destination.
• FINDING-SCHEMA.md - source = the attacker-influenced URL or host, sink = the internal or metadata request it drives.