GCP - Non-svc Persistance

Impara l'hacking su AWS da zero a esperto con htARTE (Esperto Red Team di HackTricks su AWS)!

Altri modi per supportare HackTricks:

Queste sono tecniche utili una volta che, in qualche modo, hai compromesso delle credenziali GCP o una macchina in esecuzione in un ambiente GCP.

Token Hijacking

Token Utente Autenticato

Per ottenere il token corrente di un utente puoi eseguire:

sqlite3 $HOME/.config/gcloud/access_tokens.db "select access_token from access_tokens where account_id='<email>';"

Controlla in questa pagina come utilizzare direttamente questo token usando gcloud:

Per ottenere i dettagli per generare un nuovo token di accesso esegui:

sqlite3 $HOME/.config/gcloud/credentials.db "select value from credentials where account_id='<email>';"

È anche possibile trovare i token di aggiornamento in $HOME/.config/gcloud/application_default_credentials.json e in $HOME/.config/gcloud/legacy_credentials/*/adc.json.

Per ottenere un nuovo token di accesso aggiornato con il token di aggiornamento, l'ID client e il segreto client eseguire:

curl -s --data client_id=<client_id> --data client_secret=<client_secret> --data grant_type=refresh_token --data refresh_token=<refresh_token> --data scope="https://www.googleapis.com/auth/cloud-platform https://www.googleapis.com/auth/accounts.reauth" https://www.googleapis.com/oauth2/v4/token

La validità dei token di aggiornamento può essere gestita in Admin > Sicurezza > Controllo sessione Google Cloud, e per impostazione predefinita è impostata su 16 ore, anche se può essere impostata per non scadere:

Flusso di autenticazione

Il flusso di autenticazione quando si utilizza qualcosa come gcloud auth login aprirà un prompt nel browser e dopo aver accettato tutti gli ambiti, il browser invierà una richiesta come questa alla porta http aperta dal tool:

/?state=EN5AK1GxwrEKgKog9ANBm0qDwWByYO&code=4/0AeaYSHCllDzZCAt2IlNWjMHqr4XKOuNuhOL-TM541gv-F6WOUsbwXiUgMYvo4Fg0NGzV9A&scope=email%20openid%20https://www.googleapis.com/auth/userinfo.email%20https://www.googleapis.com/auth/cloud-platform%20https://www.googleapis.com/auth/appengine.admin%20https://www.googleapis.com/auth/sqlservice.login%20https://www.googleapis.com/auth/compute%20https://www.googleapis.com/auth/accounts.reauth&authuser=0&prompt=consent HTTP/1.1

Quindi, gcloud utilizzerà lo stato e il codice con un certo client_id codificato in modo rigido (32555940559.apps.googleusercontent.com) e client_secret (ZmssLNjJy2998hD4CTg2ejr2) per ottenere i dati finali del token di aggiornamento.

Si noti che la comunicazione con localhost avviene tramite HTTP, quindi è possibile intercettare i dati per ottenere un token di aggiornamento, tuttavia questi dati sono validi solo una volta, quindi sarebbe inutile; è più semplice leggere il token di aggiornamento dal file.

Ambiti OAuth

È possibile trovare tutti gli ambiti Google su https://developers.google.com/identity/protocols/oauth2/scopes o ottenerli eseguendo:

curl "https://developers.google.com/identity/protocols/oauth2/scopes" | grep -oE 'https://www.googleapis.com/auth/[a-zA-A/\-\._]*' | sort -u

È possibile vedere quali ambiti l'applicazione che utilizza gcloud per autenticarsi può supportare con questo script:

curl "https://developers.google.com/identity/protocols/oauth2/scopes" | grep -oE 'https://www.googleapis.com/auth/[a-zA-Z/\._\-]*' | sort -u | while read -r scope; do
echo -ne "Testing $scope         \r"
if ! curl -v "https://accounts.google.com/o/oauth2/auth?response_type=code&client_id=32555940559.apps.googleusercontent.com&redirect_uri=http%3A%2F%2Flocalhost%3A8085%2F&scope=openid+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fuserinfo.email+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcloud-platform+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fappengine.admin+$scope+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fsqlservice.login+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Fcompute+https%3A%2F%2Fwww.googleapis.com%2Fauth%2Faccounts.reauth&state=AjvFqBW5XNIw3VADagy5pvUSPraLQu&access_type=offline&code_challenge=IOk5F08WLn5xYPGRAHP9CTGHbLFDUElsP551ni2leN4&code_challenge_method=S256" 2>&1 | grep -q "error"; then
echo ""
echo $scope
fi
done

Dopo averlo eseguito, è stato verificato che questa app supporta questi ambiti:

https://www.googleapis.com/auth/appengine.admin
https://www.googleapis.com/auth/bigquery
https://www.googleapis.com/auth/cloud-platform
https://www.googleapis.com/auth/compute
https://www.googleapis.com/auth/devstorage.full_control
https://www.googleapis.com/auth/drive
https://www.googleapis.com/auth/userinfo.email

È interessante vedere come questa app supporti lo scope drive, che potrebbe consentire a un utente di passare da GCP a Workspace se un attaccante riesce a costringere l'utente a generare un token con questo scope.

Controlla come abusare di questo qui.

Account di servizio

Proprio come con gli utenti autenticati, se riesci a compromettere il file della chiave privata di un account di servizio, sarai in grado di accedervi di solito per tutto il tempo che desideri. Tuttavia, se rubi il token OAuth di un account di servizio, questo potrebbe essere ancora più interessante, perché, anche se di default questi token sono utili solo per un'ora, se la vittima elimina la chiave API privata, il token OAuth rimarrà comunque valido fino alla sua scadenza.

Metadati

Ovviamente, fintanto che ti trovi all'interno di una macchina in esecuzione nell'ambiente GCP, sarai in grado di accedere all'account di servizio collegato a quella macchina contattando il punto finale dei metadati (nota che i token OAuth a cui puoi accedere in questo punto finale sono di solito limitati dagli scope).

Rimedi

Alcuni rimedi per queste tecniche sono spiegati in https://www.netskope.com/blog/gcp-oauth-token-hijacking-in-google-cloud-part-2

Riferimenti

Impara l'hacking di AWS da zero a eroe con htARTE (HackTricks AWS Red Team Expert)!

Altri modi per supportare HackTricks:

Last updated