mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-02 07:50:00 -08:00
Translated ['src/pentesting-ci-cd/cloudflare-security/cloudflare-domains
This commit is contained in:
Translator
@@ -4,18 +4,18 @@
|
||||
|
||||
## Grundinformationen
|
||||
|
||||
**Azure Function Apps** sind ein **serverloser Compute-Service**, der es Ihnen ermöglicht, kleine Codeabschnitte, die als **Funktionen** bezeichnet werden, auszuführen, ohne die zugrunde liegende Infrastruktur zu verwalten. Sie sind so konzipiert, dass sie Code als Reaktion auf verschiedene Trigger ausführen, wie z.B. **HTTP-Anfragen, Timer oder Ereignisse von anderen Azure-Diensten** wie Blob Storage oder Event Hubs. Function Apps unterstützen mehrere Programmiersprachen, darunter C#, Python, JavaScript und Java, was sie vielseitig für den Aufbau von **ereignisgesteuerten Anwendungen**, die Automatisierung von Workflows oder die Integration von Diensten macht. Sie sind kosteneffektiv, da Sie normalerweise nur für die Rechenzeit bezahlen, die verwendet wird, wenn Ihr Code ausgeführt wird.
|
||||
**Azure Function Apps** sind ein **serverloser Compute-Dienst**, der es Ihnen ermöglicht, kleine Codeabschnitte, die als **Funktionen** bezeichnet werden, auszuführen, ohne die zugrunde liegende Infrastruktur zu verwalten. Sie sind so konzipiert, dass sie Code als Reaktion auf verschiedene Trigger ausführen, wie z.B. **HTTP-Anfragen, Timer oder Ereignisse von anderen Azure-Diensten** wie Blob Storage oder Event Hubs. Function Apps unterstützen mehrere Programmiersprachen, darunter C#, Python, JavaScript und Java, was sie vielseitig für den Aufbau von **ereignisgesteuerten Anwendungen**, die Automatisierung von Workflows oder die Integration von Diensten macht. Sie sind kosteneffektiv, da Sie normalerweise nur für die Rechenzeit bezahlen, die verwendet wird, wenn Ihr Code ausgeführt wird.
|
||||
|
||||
> [!NOTE]
|
||||
> [!HINWEIS]
|
||||
> Beachten Sie, dass **Funktionen eine Teilmenge der App-Dienste sind**, daher werden viele der hier besprochenen Funktionen auch von Anwendungen verwendet, die als Azure Apps (`webapp` in cli) erstellt wurden.
|
||||
|
||||
### Verschiedene Pläne
|
||||
|
||||
- **Flex Consumption Plan**: Bietet **dynamisches, ereignisgesteuertes Skalieren** mit einer Pay-as-you-go-Preismodell, das das Hinzufügen oder Entfernen von Funktionsinstanzen basierend auf der Nachfrage ermöglicht. Es unterstützt **virtuelles Networking** und **vorab bereitgestellte Instanzen**, um Kaltstarts zu reduzieren, was es für **variable Workloads** geeignet macht, die keine Containerunterstützung erfordern.
|
||||
- **Flex Consumption Plan**: Bietet **dynamisches, ereignisgesteuertes Skalieren** mit einer Bezahlung nach Nutzung, wobei Funktionsinstanzen je nach Bedarf hinzugefügt oder entfernt werden. Es unterstützt **virtuelles Networking** und **vorab bereitgestellte Instanzen**, um Kaltstarts zu reduzieren, was es für **variable Workloads** geeignet macht, die keine Containerunterstützung benötigen.
|
||||
- **Traditional Consumption Plan**: Die Standard-Serverless-Option, bei der Sie **nur für Rechenressourcen bezahlen, wenn Funktionen ausgeführt werden**. Es skaliert automatisch basierend auf eingehenden Ereignissen und umfasst **Optimierungen für Kaltstarts**, unterstützt jedoch keine Containerbereitstellungen. Ideal für **intermittierende Workloads**, die automatisches Skalieren erfordern.
|
||||
- **Premium Plan**: Entwickelt für **konstante Leistung**, mit **vorwärmenden Arbeitern**, um Kaltstarts zu eliminieren. Es bietet **erweiterte Ausführungszeiten, virtuelles Networking** und unterstützt **benutzerdefinierte Linux-Images**, was es perfekt für **geschäftskritische Anwendungen** macht, die hohe Leistung und erweiterte Funktionen benötigen.
|
||||
- **Dedicated Plan**: Läuft auf dedizierten virtuellen Maschinen mit **vorhersehbarer Abrechnung** und unterstützt manuelles oder automatisches Skalieren. Es ermöglicht das Ausführen mehrerer Apps im selben Plan, bietet **Rechenisolierung** und gewährleistet **sicheren Netzwerkzugang** über App Service Environments, was es ideal für **langfristige Anwendungen** macht, die eine konsistente Ressourcenzuteilung benötigen.
|
||||
- **Container Apps**: Ermöglicht das Bereitstellen von **containerisierten Funktions-Apps** in einer verwalteten Umgebung, zusammen mit Mikrodiensten und APIs. Es unterstützt benutzerdefinierte Bibliotheken, die Migration von Legacy-Apps und **GPU-Verarbeitung**, wodurch die Verwaltung von Kubernetes-Clustern entfällt. Ideal für **ereignisgesteuerte, skalierbare containerisierte Anwendungen**.
|
||||
- **Container Apps**: Ermöglicht das Bereitstellen von **containerisierten Funktions-Apps** in einer verwalteten Umgebung, zusammen mit Microservices und APIs. Es unterstützt benutzerdefinierte Bibliotheken, die Migration von Legacy-Apps und **GPU-Verarbeitung**, wodurch die Verwaltung von Kubernetes-Clustern entfällt. Ideal für **ereignisgesteuerte, skalierbare containerisierte Anwendungen**.
|
||||
|
||||
### **Speicher-Buckets**
|
||||
|
||||
@@ -23,7 +23,7 @@ Beim Erstellen einer neuen nicht containerisierten Function App (aber mit dem Co
|
||||
|
||||
Darüber hinaus wird der Code im Bucket (in den verschiedenen Formaten, in denen er gespeichert werden kann) geändert, sodass der **Code der App auf den neuen geändert und beim nächsten Aufruf der Funktion ausgeführt wird**.
|
||||
|
||||
> [!CAUTION]
|
||||
> [!VORSICHT]
|
||||
> Dies ist aus der Perspektive eines Angreifers sehr interessant, da **Schreibzugriff auf diesen Bucket** es einem Angreifer ermöglichen würde, **den Code zu kompromittieren und Berechtigungen** für die verwalteten Identitäten innerhalb der Function App zu eskalieren.
|
||||
>
|
||||
> Mehr dazu im **Abschnitt zur Berechtigungseskalation**.
|
||||
@@ -39,12 +39,12 @@ Bei Verwendung eines HTTP-Triggers:
|
||||
- Es ist möglich, **Zugriff auf eine Funktion von überall im Internet** zu gewähren, ohne eine Authentifizierung zu verlangen, oder den Zugriff IAM-basiert zu gewähren. Obwohl es auch möglich ist, diesen Zugriff einzuschränken.
|
||||
- Es ist auch möglich, **Zugriff auf eine Function App von einem internen Netzwerk (VPC)** zu gewähren oder einzuschränken.
|
||||
|
||||
> [!CAUTION]
|
||||
> [!VORSICHT]
|
||||
> Dies ist aus der Perspektive eines Angreifers sehr interessant, da es möglich sein könnte, von einer verwundbaren Funktion, die dem Internet ausgesetzt ist, **auf interne Netzwerke zu pivotieren**.
|
||||
|
||||
### **Function App-Einstellungen & Umgebungsvariablen**
|
||||
|
||||
Es ist möglich, Umgebungsvariablen innerhalb einer App zu konfigurieren, die sensible Informationen enthalten könnten. Darüber hinaus werden standardmäßig die Umgebungsvariablen **`AzureWebJobsStorage`** und **`WEBSITE_CONTENTAZUREFILECONNECTIONSTRING`** (unter anderem) erstellt. Diese sind besonders interessant, da sie **den Kontoschlüssel enthalten, um mit VOLLER Berechtigung auf das Speicherkonto zuzugreifen, das die Daten der Anwendung enthält**. Diese Einstellungen sind auch erforderlich, um den Code aus dem Speicherkonto auszuführen.
|
||||
Es ist möglich, Umgebungsvariablen innerhalb einer App zu konfigurieren, die sensible Informationen enthalten könnten. Darüber hinaus werden standardmäßig die Umgebungsvariablen **`AzureWebJobsStorage`** und **`WEBSITE_CONTENTAZUREFILECONNECTIONSTRING`** (unter anderem) erstellt. Diese sind besonders interessant, da sie **den Kontoschlüssel enthalten, um mit VOLLBERECHTIGUNGEN auf das Speicherkonto zuzugreifen, das die Daten der Anwendung enthält**. Diese Einstellungen sind auch erforderlich, um den Code aus dem Speicherkonto auszuführen.
|
||||
|
||||
Diese Umgebungsvariablen oder Konfigurationsparameter steuern auch, wie die Funktion den Code ausführt, zum Beispiel, wenn **`WEBSITE_RUN_FROM_PACKAGE`** existiert, zeigt es die URL an, wo sich der Code der Anwendung befindet.
|
||||
|
||||
@@ -60,20 +60,20 @@ Genau wie [**VMs**](vms/index.html) können Funktionen **verwaltete Identitäten
|
||||
|
||||
Die **systemzugewiesene** Identität ist eine verwaltete Identität, die **nur die Funktion**, die sie zugewiesen hat, verwenden kann, während die **benutzerzugewiesenen** verwalteten Identitäten verwaltete Identitäten sind, die **von jedem anderen Azure-Dienst verwendet werden können**.
|
||||
|
||||
> [!NOTE]
|
||||
> [!HINWEIS]
|
||||
> Genau wie bei [**VMs**](vms/index.html) können Funktionen **1 systemzugewiesene** verwaltete Identität und **mehrere benutzerzugewiesene** haben, daher ist es immer wichtig, alle zu finden, wenn Sie die Funktion kompromittieren, da Sie möglicherweise Berechtigungen für mehrere verwaltete Identitäten von nur einer Funktion eskalieren können.
|
||||
>
|
||||
> Wenn keine systemzugewiesene verwaltete Identität verwendet wird, aber eine oder mehrere benutzerverwaltete Identitäten an eine Funktion angehängt sind, können Sie standardmäßig kein Token erhalten.
|
||||
|
||||
Es ist möglich, die [**PEASS-Skripte**](https://github.com/peass-ng/PEASS-ng) zu verwenden, um Token von der standardmäßigen verwalteten Identität vom Metadatenendpunkt zu erhalten. Oder Sie könnten sie **manuell** erhalten, wie in:
|
||||
Es ist möglich, die [**PEASS-Skripte**](https://github.com/peass-ng/PEASS-ng) zu verwenden, um Tokens von der standardmäßigen verwalteten Identität vom Metadatenendpunkt zu erhalten. Oder Sie könnten sie **manuell** erhalten, wie in:
|
||||
|
||||
{% embed url="https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf#azure-vm" %}
|
||||
{% embed url="https://book.hacktricks.wiki/en/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf.html#azure-vm" %}
|
||||
|
||||
Beachten Sie, dass Sie einen Weg finden müssen, um **alle verwalteten Identitäten zu überprüfen, die eine Funktion angehängt hat**, da der Metadatenendpunkt **nur die standardmäßige verwenden wird** (siehe den vorherigen Link für weitere Informationen).
|
||||
|
||||
## Zugriffsschlüssel
|
||||
|
||||
> [!NOTE]
|
||||
> [!HINWEIS]
|
||||
> Beachten Sie, dass es keine RBAC-Berechtigungen gibt, um Benutzern den Zugriff auf die Funktionen zu gewähren. Die **Funktionsausführung hängt vom Trigger** ab, der beim Erstellen ausgewählt wurde, und wenn ein HTTP-Trigger ausgewählt wurde, könnte es erforderlich sein, einen **Zugriffsschlüssel** zu verwenden.
|
||||
|
||||
Beim Erstellen eines Endpunkts innerhalb einer Funktion mit einem **HTTP-Trigger** ist es möglich, das **Zugriffsschlüssel-Autorisierungsniveau** anzugeben, das erforderlich ist, um die Funktion auszulösen. Drei Optionen sind verfügbar:
|
||||
@@ -89,14 +89,14 @@ Beim Erstellen eines Endpunkts innerhalb einer Funktion mit einem **HTTP-Trigger
|
||||
- **Master-Schlüssel:** Der Master-Schlüssel (`_master`) dient als administrativer Schlüssel, der erhöhte Berechtigungen bietet, einschließlich Zugriff auf alle Funktionsendpunkte (ADMIN-Zugriffslevel eingeschlossen). Dieser **Schlüssel kann nicht widerrufen werden.**
|
||||
- **Systemschlüssel:** Systemschlüssel werden **von bestimmten Erweiterungen verwaltet** und sind erforderlich, um auf Webhook-Endpunkte zuzugreifen, die von internen Komponenten verwendet werden. Beispiele sind der Event Grid-Trigger und Durable Functions, die Systemschlüssel verwenden, um sicher mit ihren jeweiligen APIs zu interagieren.
|
||||
|
||||
> [!TIP]
|
||||
> [!TIPP]
|
||||
> Beispiel für den Zugriff auf einen Funktions-API-Endpunkt mit einem Schlüssel:
|
||||
>
|
||||
> `https://<function_uniq_name>.azurewebsites.net/api/<endpoint_name>?code=<access_key>`
|
||||
|
||||
### Basis-Authentifizierung
|
||||
|
||||
Genau wie in App Services unterstützen Funktionen auch die Basis-Authentifizierung, um sich mit **SCM** und **FTP** zu verbinden, um Code mit einem **Benutzernamen und Passwort in einer URL** bereitzustellen, die von Azure bereitgestellt wird. Weitere Informationen dazu finden Sie in:
|
||||
Genau wie bei App-Diensten unterstützen Funktionen auch die Basis-Authentifizierung, um sich mit **SCM** und **FTP** zu verbinden, um Code mit einem **Benutzernamen und Passwort in einer URL** bereitzustellen, die von Azure bereitgestellt wird. Weitere Informationen dazu finden Sie in:
|
||||
|
||||
{{#ref}}
|
||||
az-app-services.md
|
||||
@@ -104,7 +104,7 @@ az-app-services.md
|
||||
|
||||
### Github-basierte Bereitstellungen
|
||||
|
||||
Wenn eine Funktion aus einem Github-Repo generiert wird, ermöglicht die Azure-Webkonsole, **automatisch einen Github-Workflow in einem bestimmten Repository zu erstellen**, sodass der Code der Funktion aktualisiert wird, wenn dieses Repository aktualisiert wird. Tatsächlich sieht die Github Action YAML für eine Python-Funktion so aus:
|
||||
Wenn eine Funktion aus einem Github-Repo generiert wird, ermöglicht die Azure-Webkonsole, **automatisch einen Github-Workflow in einem bestimmten Repository zu erstellen**, sodass der Code der Funktion aktualisiert wird, wann immer dieses Repository aktualisiert wird. Tatsächlich sieht die Github Action YAML für eine Python-Funktion so aus:
|
||||
|
||||
<details>
|
||||
|
||||
|
||||
Reference in New Issue
Block a user