Head in the Clouds: Google Compute

Introduction

This article is a companion piece for this primer:

IP Address Ranges

Google has, by far, the most convoluted solution for fetching Compute IP addresses, which is detailed here in the Google Compute Engine documentation:

To get the IP address ranges, one must first fetch the TXT DNS record for _cloud-netblocks.googleusercontent.com, like so:

nslookup -q=TXT _cloud-netblocks.googleusercontent.com 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
_cloud-netblocks.googleusercontent.com text = “v=spf1 include:_cloud-netblocks1.googleusercontent.com include:_cloud-netblocks2.googleusercontent.com include:_cloud-netblocks3.googleusercontent.com include:_cloud-netblocks4.googleusercontent.com include:_cloud-netblocks5.googleusercontent.com ?all”

The returned entries in the SPF record for the “_cloud-netblocks#” names contain the information about Google Compute’s current IP address ranges. To get the list, additional lookups must be performed one at a time for each _cloud-netblocks hostname:

nslookup -q=TXT _cloud-netblocks1.googleusercontent.com 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53

Non-authoritative answer:
_cloud-netblocks1.googleusercontent.com text = “v=spf1 include:_cloud-netblocks6.googleusercontent.com ip4:8.34.208.0/20 ip4:8.35.192.0/21 ip4:8.35.200.0/23 ip4:108.59.80.0/20 ip4:108.170.192.0/20 ip4:108.170.208.0/21 ip4:108.170.216.0/22 ip4:108.170.220.0/23 ip4:108.170.222.0/24 ip4:35.224.0.0/13 ?all”

Making Use of the IP Addresses

An up-to-date list of these IP addresses is useful for identifying assets hosted in a Google Compute environment. Any domain or subdomain that points back to an IP address in the list will lead to a storage bucket or Compute Engine server.

Maintaining an Updated Master List

The collection of these IP addresses has been automated in the following script:

The script fetches the latests IP address ranges used by each provider and then outputs one list in a CloudIPs.txt file. Each range is on a new line following a header naming the service, e.g. “# Google Compute Engine.”

Storage: Compute Buckets

Google’s buckets work in a similar manner to AWS buckets. The address scheme looks like this:

https://storage.googleapis.com/cmaddy/

Like AWS, Compute buckets can be discovered and enumerated using brute force by guessing a bucket’s name and checking the XML response.

Bucket Names

Google allows users to name buckets using DNS-compliant names, but if the name includes a dot it must be a valid domain name or subdomain and the user must be able to prove they own the domain. This detailed in Google’s documentation for “Domain-Named Bucket Verification.”

Virtual Servers: Compute Engine

Google’s virtual machine offering is called Compute Engine. Google’s documentation for the Compute Engine metadata service can be found here:

The metadata service is covered in the main primer article.

Authentication: Google Accounts

A Compute account is attached to an active Google and Google Apps account. This account may add new users, but those users are restricted to other active Google and Google Apps accounts. Once a Google account is linked, that user can sign-in using their account and interact with the Google Compute resources assigned to them.

Credential Files

When the Google Compute SDK, Compute’s command line tool, is used for the first time, the user must run gcloud init to authenticate (or gcloud auth login). This launches a web browser for the user to sign-in using their Google account via OAuth2. At this point, several credential files are setup in the user’s home directory:

Linux and macOS: ~/.config/gcloud/

Windows: C:\Users\USERNAME\AppData\Roaming\gcloud\

Inside the gcloud folder, the SDK creates two SQLite databases, credentials.db and access_tokens.db, and a “legacy_credentials” folder. The legacy_credentials folder contains a folder named for each Google account used with the SDK and these folders each contain a JSON file with that account’s client_id and client_secret.

There is also a ~/.gsutil/credstore2 file. The credstore2 file is not easily found in the Google Compute documentation, but is referenced in the boto library used for interacting with Compute (also Azure and AWS) via Python:

This output from gsutil config may explain the existence of this file:

CommandException: OAuth2 is the preferred authentication mechanism with the Cloud SDK.
Run “gcloud auth login” to configure authentication, unless:
– You don’t want gsutil to use OAuth2 credentials from the Cloud SDK,
but instead want to manage credentials with .boto files generated by
running “gsutil config”; in which case run “gcloud config set
pass_credentials_to_gsutil false”.
– You want to authenticate with an HMAC access key and secret, in
which case run “gsutil config -a”.

Stealing Credentials

If Compute credential files are found, access to a Google Compute account can be setup by copying the gcloud credentials.db andaccess_tokens.db database files and the full contents of the legacy_credentials directory from the home folder of a user the has logged-in with the Google Compute SDK.

Note that the folders within the legacy_credentials directory contain an adc.json file and a hidden .boto file.

Once everything has been copied into ~/.config/gcloud/, the database contents can be checked using this command to list all of the authenticated accounts:

gcloud auth list

All successfully copied accounts will be listed. Next, an active account must be specified. This is done using the following command:

gcloud config set account ACCOUNT

Finally, run a gcloud command to test authentication, like gcloud compute instances list. If authentication is successful, the command will return results. If the OAuth2 authentication has expired / been revoked or the copied data is incomplete, an error like this one will be returned:

ERROR: (gcloud.compute.instances.list) There was a problem refreshing your current auth tokens: invalid_grant: Token has been expired or revoked.

In this event, verify the copied data and/or try switching to a different account.

If it turns out the authentication was revoked or has expired, it may be possible to refresh the login with Remote Desktop access. The gcloud auth login command will generate a new OAuth2 login URL and launch the system’s browser. If the user is logged into their Google account in the browser, then the Google profile will appear in a list for selection. Selecting the appropriate Google profile will complete the Google Compute SDK login and refresh the credential files. The new credentials can then be copied.

Automating Credential Theft

As a proof of concept, this tool was created to search for and collect credential files associated with Compute, AWS, and Azure:

SharpCloud is a simple, basic C# console application that checks for the credential and config files associated with each cloud provider. If found, the contents of each found file is dumped for collection and potential reuse.

Command Line: Google Compute SDK

Google uses the Google Compute SDK for command line access. Using the SDK is straight forward and requires logging in using an active Google account linked to a Compute project.

The SDK is installed by downloading the appropriate package for the target operating system and then installing it. Once initialized with a Google account, the command line tools are ready to be used.

Google offers command documentation here:

Useful Commands by Service

compute.csv