Exploiting Ssrf To Cloud Metadata

---
name: exploiting-ssrf-to-cloud-metadata
description: >-
  Adjudicate whether a server-side request-forgery primitive actually reaches
  high-value internal targets, especially a cloud instance metadata endpoint that
  hands out credentials. Covers proving the fetch is attacker-steered, reaching
  link-local and internal addresses, defeating allowlist and parser-based filters
  through DNS rebinding and URL confusion, retrieving instance credentials, and
  blind out-of-band confirmation. Use when a feature fetches a URL, host, or address
  the user can influence, or when triaging an SSRF lead for real impact.
license: MIT
---

# 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](../../FINDING-SCHEMA.md) - source = the attacker-influenced URL
  or host, sink = the internal or metadata request it drives.