Metadata SSRF in a PDF Export Service
Acme SaaS has commissioned an external penetration test of its customer-facing application and the 10.20.30.0/24 production subnet. The rules of engagement allow exploitation but prohibit denial-of-service, social engineering, and access to real customer data. Testing is allowed 01:00–05:00 UTC; the client’s on-call engineer is available. During testing, the tester finds that the PDF export endpoint accepts a URL parameter and fetches it server-side. By submitting http://169.254.169.254/latest/meta-data/iam/security-credentials/, the tester retrieves temporary AWS credentials for an EC2 role named pdf-render. The role has s3:ListBucket and s3:GetObject on a bucket named acme-customer-backups. The client’s security lead says, “Download one backup to prove impact, then delete it. We need this for the board.” The bucket contains what appear to be nightly database dumps for 40,000 customers. The tester has not yet accessed any object.
1. Should the tester download a backup object to prove impact? Explain the decision and safer alternatives.
Read the worked answer
No - downloading a real backup would breach the rules of engagement and likely data-protection law, and ‘delete it afterward’ does not undo the copy, logging, or disclosure. The temporary credentials already prove the SSRF reaches the instance metadata service and that the role can read a customer-backup bucket; that is sufficient to rate the finding critical. A safer proof is to ask the client for written approval to create a canary object in a test bucket and show that the same role can list or read only that object. If the client still wants a production demonstration, require the data owner and legal to authorize a narrowly scoped action, use an object containing synthetic data, record the exact API calls, and preserve logs. Do not enumerate object contents or download customer dumps without that approval; document the refusal and the alternative in the report so the board sees impact without an unauthorized data breach.
2. What scoped tests can confirm the blast radius without touching customer data?
Read the worked answer
Confirm blast radius by staying inside the agreed scope: capture the full HTTP request/response showing the metadata URL and role name; test whether IMDSv2 is enforced by sending a PUT request for a token and observing whether the role credentials are still returned without a token; and check the role’s effective policy from the client’s IAM export rather than by using the credentials. If the cloud account is explicitly in scope, a non-destructive s3:ListBuckets or a HeadObject on a known canary key may be authorized, but do not list customer objects or read data. Also test whether the PDF service can reach other internal addresses, such as the application’s admin interface, to show SSRF breadth. Ask the client to rotate the role credentials immediately and review S3 access logs for any use from outside the app. Record timestamps and source IPs so the client can distinguish tester activity from attacker activity.
3. How should the finding be reported and remediated?
Read the worked answer
Report as a critical finding with the endpoint, parameter, request/response evidence, role ARN, bucket name, and the exact scope limitation that stopped data access. Remediate in layers: enforce IMDSv2 and set hop limit to 1; replace the role with least privilege that cannot read backups; add an egress proxy or allowlist for PDF fetches; validate and resolve URLs, block link-local and private ranges, and disable redirects to internal addresses. Rotate the exposed credentials and audit S3 access logs and CloudTrail for the credential’s use. Add a detection for metadata IP requests from application subnets. In the retest, verify the SSRF cannot reach 169.254.169.254 and that the role cannot list the bucket. Also recommend a data-handling clause in future rules of engagement so testers and clients agree on proof-of-impact boundaries before testing begins.