gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-07-29 07:00:29 -07:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/pentesting-cloud/gcp-security/gcp-unauthenticated-e

Browse Source
This commit is contained in:
Translator
2026-06-16 13:40:21 +00:00
parent 9c52341635
commit 99b18c8cf6
1 changed files with 103 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/pentesting-cloud/gcp-security/gcp-unauthenticated-enum-and-access/gcp-api-keys-unauthenticated-enum.md
+103 -12
View File
@@ -4,27 +4,27 @@
## API Keys
Per ulteriori informazioni sulle API Keys controlla:
Per maggiori informazioni su API Keys consulta:
{{#ref}}
../gcp-services/gcp-api-keys-enum.md
{{#endref}}
### Tecniche OSINT
### OSINT techniques
**Le Google API Keys sono ampiamente utilizzate da qualsiasi tipo di applicazioni** che utilizzano dal lato client. È comune trovarle nel codice sorgente di siti web o nelle richieste di rete, in applicazioni mobili o semplicemente cercando regex su piattaforme come Github.
**Google API Keys are widely used by any kind of applications** che le usano dal lato client. È comune trovarle nel source code dei siti web o nelle network requests, nelle applicazioni mobile oppure semplicemente cercando regex su piattaforme come Github.
La regex è: **`AIza[0-9A-Za-z_-]{35}`**
Cercala ad esempio su Github seguendo: [https://github.com/search?q=%2FAIza%5B0-9A-Za-z\_-%5D%7B35%7D%2F\&type=code\&ref=advsearch](https://github.com/search?q=%2FAIza%5B0-9A-Za-z_-%5D%7B35%7D%2F&type=code&ref=advsearch)
Cercala, per esempio, su Github seguendo: [https://github.com/search?q=%2FAIza%5B0-9A-Za-z\_-%5D%7B35%7D%2F\&type=code\&ref=advsearch](https://github.com/search?q=%2FAIza%5B0-9A-Za-z_-%5D%7B35%7D%2F&type=code&ref=advsearch)
### Controlla l'origine del progetto GCP
### Check origin GCP project
Questo è estremamente utile per controllare a **quale progetto GCP appartiene una API key che hai trovato**. Abbiamo diverse opzioni:
Questo è estremamente utile per verificare **a quale progetto GCP appartiene una API key che hai trovato**. Abbiamo diverse opzioni:
- Contattare `https://www.googleapis.com/identitytoolkit/v3/relyingparty/getProjectConfig?key=<api-key`
- Contatta `https://www.googleapis.com/identitytoolkit/v3/relyingparty/getProjectConfig?key=<api-key>`
Per motivi di brevità, l'output è stato troncato, ma nell'output completo l'ID del progetto appare più di 5 volte.
Per brevità l'output è stato troncato, ma nell'output completo il project ID appare più di 5 volte
```bash
curl -s "https://www.googleapis.com/identitytoolkit/v3/relyingparty/getProjectConfig?key=AIzaSyD[...]uE8Y"
@@ -34,9 +34,9 @@ curl -s "https://www.googleapis.com/identitytoolkit/v3/relyingparty/getProjectCo
"message": "Identity Toolkit API has not been used in project 943955951114 before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/identitytoolkit.googleapis.com/overview?project=943955951114 then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.",
[...]
```
- Contattare `https://www.googleapis.com/identitytoolkit/v3/relyingparty/getProjectConfig?key=<api-key>`
- Contatta `https://identitytoolkit.googleapis.com/v1/projects?key=<api-key>`
Per brevità, l'output è stato troncato, ma nell'output completo l'ID del progetto appare più di 5 volte.
Per brevità l'output è stato troncato, ma nell'output completo il project ID appare più di 5 volte
```bash
curl -s "https://identitytoolkit.googleapis.com/v1/projects?key=AIzaSyD[...]uE8Y"
@@ -69,8 +69,99 @@ resource: projects/89123452509
service: cloudresourcemanager.googleapis.com
reason: AUTH_PERMISSION_DENIED
```
### Brute Force API endspoints
### Ricognizione API guidata dal discovery-document
Poiché potresti non sapere quali API sono abilitate nel progetto, sarebbe interessante eseguire lo strumento [https://github.com/ozguralp/gmapsapiscanner](https://github.com/ozguralp/gmapsapiscanner) e controllare **cosa puoi accedere con la chiave API.**
Una volta che hai una chiave valida, non testare solo le API pubbliche ovvie. Negli ambienti Google, i **discovery documents** possono funzionare come una mappa leggibile dalla macchina della attack surface, esponendo **resources, methods, paths, HTTP verbs, parameters, and request/response schemas**.
Target utili:
```bash
# Public / common path
curl -s 'https://serviceusage.googleapis.com/$discovery/rest?key=<api-key>'
# Hidden docs behind a visibility label
curl -s 'https://serviceusage.googleapis.com/$discovery/rest?labels=GOOGLE_INTERNAL&key=<api-key>'
```
Notes:
- Confronta la dimensione del documento e il numero di method con e senza label come `GOOGLE_INTERNAL`.
- Un **vero method inesistente** di solito restituisce un **HTML 404**. Un **JSON 404** con `Method not found.` può indicare che il method esiste ma al **API key project manca una label di visibilità richiesta**.
- Alcune API first-party sono più facili da raggiungere tramite `*.clients6.google.com` o host non documentati `*-pa.googleapis.com` rispetto al public API explorer.
Questo è particolarmente utile per enumerare **internal/admin APIs accidentalmente esposte a Internet** e per costruire custom fuzzers dallo schema invece di indovinare manualmente i campi JSON.
### Key ownership filtering at scale
Se raccogli molte Google API keys da APK, traffico browser, IPA o binary, potresti voler identificare rapidamente **quale project possiede ogni key** e se appartiene all'azienda target.
Un trucco pratico è chiamare intenzionalmente un API che **non è abilitata** per la key. Google spesso espone il **project number** di supporto nell'errore:
```bash
curl -s 'https://protos.googleapis.com/$discovery/rest?key=<api-key>'
```
Cerca messaggi come:
```text
Protos API has not been used in project 244648151629 before or it is disabled
```
Quel numero di progetto può quindi essere correlato con altri endpoint, metadata leakati o logica interna di mapping aziendale per separare **in-scope first-party keys** da progetti cliente / third-party.
### Gestisci le restrizioni della key prima di scartare una key
Una restricted key non è necessariamente inutile. Conserva il contesto in cui la key è stata trovata e ripeti le richieste con gli header corrispondenti:
```bash
# Browser restricted
curl -H 'X-Goog-Api-Key: <api-key>' \
-H 'Referer: https://target.google.com' \
'https://servicemanagement.googleapis.com/v1/operations'
# iOS restricted
curl -H 'X-Goog-Api-Key: <api-key>' \
-H 'X-Ios-Bundle-Identifier: com.google.GoogleMobile' \
'https://servicemanagement.clients6.google.com/v1/operations'
# Android restricted
curl -H 'X-Goog-Api-Key: <api-key>' \
-H 'X-Android-Package: com.google.android.settings.intelligence' \
-H 'X-Android-Cert: <sha1-signing-cert>' \
'https://servicemanagement.clients6.google.com/v1/operations'
```
Classi comuni di restrizioni:
- **HTTP Referer**
- **iOS bundle ID** (`X-Ios-Bundle-Identifier`)
- **Android package + signing cert** (`X-Android-Package` + `X-Android-Cert`)
- Restrizioni su **Server IP**, che in genere non possono essere bypassate da remoto
### Suggerimenti per first-party auth / origin whitelist
Alcune Google web APIs accettano una combinazione di **session cookie + first-party authorization headers** e sono ospitate su `*.clients6.google.com`. Quando testi queste API:
- Mantieni `Origin` e `Referer` compatibili con il prodotto che normalmente usa l'API.
- Un `401` con `reason: SESSION_COOKIE_INVALID` può in realtà significare che l'**origin non è whitelisted**, non che il cookie sia errato.
- Le API pubblicamente raggiungibili che accettano solo origin interne come `*.corp.google.com` sono candidati ad alto valore per una review di broken access control.
### Brute force sulle API abilitate e fuzz dei metodi documentati
Dato che potresti non sapere quali API sono abilitate nel progetto, può essere interessante eseguire lo strumento [https://github.com/ozguralp/gmapsapiscanner](https://github.com/ozguralp/gmapsapiscanner) e verificare **a cosa puoi accedere con la API key.**
Dopo aver identificato i servizi raggiungibili, preferisci il **schema-driven fuzzing** rispetto al blind guessing:
- Genera richieste direttamente dai discovery docs
- Ripeti la stessa richiesta con **tutte le API key valide note**
- Normalizza gli errori in modo da distinguere tra **invalid input** e fallimenti di **visibility-label / auth / restriction**
- Per identificatori numerici di oggetti, prova valori vicini come `ID-1`, `ID+1`, `1`, `2`, `100`, `1000`
- Segnala solo quando confermi **cross-user data access** o un altro reale fallimento di authorization; la semplice enumeration di solito non basta da sola
### Pattern di vuln comune: unauthenticated direct-object reference
Un pattern di bug ricorrente è una **internal/admin API** che accetta un identificatore controllato dalla vittima (per esempio `gaiaId`) e verifica solo che la richiesta contenga una API key utilizzabile, ma **non controlla mai se il chiamante è autorizzato ad accedere a quello specifico oggetto**.
```bash
curl 'https://gfibervoice-pa.googleapis.com/v1/BssGetVoiceSettings?gaiaId=<victim_gaia_id>' \
-H 'X-Goog-Api-Key: <api-key>'
```
Se l'endpoint restituisce il numero di telefono, l'indirizzo email, le impostazioni o altri campi privati di un altro utente, trattalo come un classico problema di **IDOR / broken access control**.
## References
- [Hacking Google with AI: AI-Assisted Discovery-Document Fuzzing of Google APIs](https://brutecat.com/articles/hacking-google-with-ai)
- [Google APIs Explorer](https://developers.google.com/apis-explorer)
{{#include ../../../banners/hacktricks-training.md}}