Exploit SSRF with Gopher for GCP Initial Access

What this lab covers

You find a request forgery flaw, encounter a protection intended to stop it, and defeat that protection using a protocol the filter did not anticipate, then use the resulting access to enumerate Google Cloud resources.

The protocol smuggling element is the instructive part. Most SSRF defenses fail because they reason about the destination rather than about what the request-making library will accept, and that gap is where alternative schemes live.

It suits web testers moving into cloud and assumes no prior GCP experience.

How SSRF reaches cloud credentials

SSRF occurs when an application makes a request to a location influenced by user input. In a cloud environment the highest-value target is the metadata server, a link-local address reachable only from the instance, which returns configuration and access tokens for the attached service account.

Naive protections block obvious targets by string matching, denying the metadata hostname or address. These are defeated by alternative representations, redirects and, importantly, by different protocols, because the filter is reasoning about a URL while the underlying library is reasoning about a request.

The gopher scheme is useful to an attacker because it allows arbitrary bytes to be sent to a host and port, which turns a request forgery into something closer to a socket. That permits interaction with services that are not plain HTTP and gives fine control over what is transmitted, which many filters never contemplate.

How to detect this in your own environment

Watch for metadata server requests originating from unusual processes. Legitimate access comes from cloud SDKs and agents, so a request from a web request handler is anomalous and is the cleanest host-level signal.

Monitor application logs for requests to internal or link-local addresses, and for unusual URL schemes in parameters. Both are visible if outbound request destinations are logged, which many applications do not do.

The most reliable cloud-side detection is token misuse. Service account credentials used from outside the instance are theft regardless of how the theft occurred, and that signal does not depend on recognizing the exploit.

How to prevent it

Validate destinations against an allow list of permitted hosts, and resolve addresses before connecting so that a name resolving to a link-local address is rejected. Deny lists of known-bad targets are the approach that keeps failing.

Restrict which schemes the request library will accept. Most applications need HTTP and HTTPS only, and disabling everything else removes protocol smuggling as a category.

Scope the instance service account narrowly, because that is what an attacker inherits. This does not prevent SSRF and it decides what SSRF is worth, which in practice is the control that limits impact.

Real-world context

Server-side request forgery is listed in the OWASP Top 10, and its severity rose substantially with cloud adoption because the metadata server turned a request forgery into a route to credentials.

The 2019 Capital One breach, prosecuted by the US Department of Justice, is the reference case for this shape of attack, where a request forgery weakness led to instance credentials being obtained and used to access stored data. The mechanism is the same across providers even though the metadata endpoints differ.

The pattern maps to MITRE ATT&CK T1190 Exploit Public-Facing Application and T1552.005 Cloud Instance Metadata API.

Applying this at work

• Review your applications for anywhere a request destination is influenced by user input, and validate against an allow list rather than a deny list.
• Restrict URL schemes accepted by your HTTP client libraries to HTTP and HTTPS.
• Audit the service accounts attached to internet-facing workloads and reduce their permissions.
• Add detection for metadata server access from web application processes.
• Confirm you would notice instance credentials being used from outside the instance.

Frequently asked questions

Why is SSRF so serious in cloud environments?

Because the metadata server returns access tokens for the workload's service account to anything that can request them from the host. A request forgery therefore becomes credential disclosure without the application being compromised.

What makes the gopher protocol useful to an attacker?

It allows arbitrary bytes to be sent to a host and port rather than a structured HTTP request. That defeats filters reasoning about URLs and permits interaction with services that are not plain HTTP.

How should SSRF be prevented properly?

Validate destinations against an allow list, resolve addresses before connecting so names resolving to internal ranges are rejected, and restrict the schemes your request library accepts. Deny lists of known-bad targets are consistently bypassed.

Do I need my own Google Cloud account to practice this?

No. The lab runs in a live Google Cloud environment that Pwned Labs provisions for you, so there is nothing to set up and no risk to your own project.

Which certification covers this in depth?

The Google Cloud Red Team Professional (GCRTP) covers Google Cloud and Google Workspace attack paths in full, including service account abuse and privilege escalation, and is assessed hands-on in a live Google Cloud environment.