Full Report
Instance providers, like GCP and AWS, have a service for getting credentials local to the server. Obviously, getting an SSRF to get this information is horrible for the client. So, some protections have been added to make this harder. One of these is the requirement of the Metadata-Flavor: Google header. While on a pentest, the author of this post noticed that adding an extra slash to the instance removed the requirement of this header! But why!? Using http://169.254.169.254/computeMetadata>/v1/instance/ with a single extra slash did the trick. Sometimes, fuzzing and trying weird things is the way to go! Our systems are just so complex nowadays that it's hard to understand how they work.
Analysis Summary
# Vulnerability: Google Cloud Platform (GCP) Instance Metadata Service Protection Bypass
## CVE Details
- **CVE ID**: N/A (Discovered via Google VRP; often tracked via internal bug reports for cloud infrastructure flaws)
- **CVSS Score**: Estimated 7.5 [High] (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N)
- **CWE**: CWE-444: Inconsistent Interpretation of HTTP Requests ("HTTP Request Smuggling/Splitting") or CWE-288: Isolation Wall Bypass
## Affected Systems
- **Products**: Google Cloud Platform (GCP) Compute Engine
- **Versions**: Infrastructure version active prior to July 2019
- **Configurations**: Instances utilizing the v1 Instance Metadata Service (IMDS) at `169.254.169.254` reachable via Server-Side Request Forgery (SSRF).
## Vulnerability Description
The GCP Instance Metadata Service (IMDS) implements a security control requiring the presence of the `Metadata-Flavor: Google` HTTP header to prevent simple SSRF attacks. Research discovered that the security check responsible for validating this header could be bypassed through three primary methods:
1. **URI Path Normalization Bypass**: Appending an extra forward slash (e.g., `computeMetadata//v1/`) caused the metadata server to skip the header validation check while still serving the metadata.
2. **HTTP/1.0 Downgrade**: Sending an HTTP/1.0 request without headers to the root path triggered a default behavior where the service dumped all metadata content, ignoring the requirement for the security header.
3. **Delimiter Manipulation**: Using a semicolon (`;`) allowed an attacker to terminate the logical path interpretation, bypassing application-level restrictions that append hardcoded suffixes to a URL.
## Exploitation
- **Status**: PoC available; addressed by vendor in 2019.
- **Complexity**: Low
- **Attack Vector**: Network (via SSRF vulnerability in a hosted application).
## Impact
- **Confidentiality**: High (Allows unauthorized access to sensitive service account tokens, private keys, and instance configuration metadata).
- **Integrity**: Low (Metadata is primarily read-only through this endpoint).
- **Availability**: None.
## Remediation
### Patches
- **Vendor Fix**: Google updated the internal handling of the Metadata Service on **2019-07-22** to ensure that `Metadata-Flavor: Google` is enforced regardless of URL path formatting or HTTP version.
### Workarounds
- **IMDSv1 Restriction**: Where possible, enforce the use of secure identity metadata and ensure applications do not have vulnerabilities that allow arbitrary network requests to internal IP ranges.
- **Network Policy**: Use VPC firewall rules or metadata server descriptors to restrict which processes or users can access the metadata endpoint.
## Detection
- **Indicators of Compromise**:
- Unusual HTTP requests to `169.254.169.254` containing `//` in the URI path.
- Requests to the metadata service using HTTP/1.0.
- **Detection Methods**: Monitor application logs for SSRF attempts and audit GCP VPC Flow Logs for unexpected egress to the metadata IP address.
## References
- **Original Research**: hxxps[://]amlw[.]dev/vrp/135276622/
- **GCP Documentation**: hxxps[://]cloud[.]google[.]com/compute/docs/metadata/overview