mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-07 02:03:45 -08:00
Translated ['src/pentesting-cloud/aws-security/aws-privilege-escalation/
This commit is contained in:
Translator
@@ -4,14 +4,14 @@
|
||||
|
||||
## Grundinformationen
|
||||
|
||||
**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.
|
||||
**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.
|
||||
|
||||
> [!NOTE]
|
||||
> 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 nutzungsabhängigen Preisgestaltung, 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.
|
||||
- **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.
|
||||
@@ -21,7 +21,7 @@
|
||||
|
||||
Beim Erstellen einer neuen nicht containerisierten Function App (aber mit dem Code zum Ausführen) werden die **Code- und anderen funktionsbezogenen Daten in einem Speicherkonto gespeichert**. Standardmäßig erstellt die Webkonsole für jede Funktion ein neues Konto, um den Code zu speichern.
|
||||
|
||||
Darüber hinaus wird durch das Ändern des Codes im Bucket (in den verschiedenen Formaten, in denen er gespeichert werden kann) der **Code der App auf den neuen geändert und beim nächsten Aufruf der Funktion ausgeführt**.
|
||||
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]
|
||||
> 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.
|
||||
@@ -30,17 +30,17 @@ Darüber hinaus wird durch das Ändern des Codes im Bucket (in den verschiedenen
|
||||
|
||||
Es ist auch möglich, die **Master- und Funktionsschlüssel** im Speicherkonto im Container **`azure-webjobs-secrets`** im Ordner **`<app-name>`** in den JSON-Dateien zu finden, die Sie dort finden können.
|
||||
|
||||
Beachten Sie, dass Funktionen auch erlauben, den Code an einem entfernten Ort zu speichern, indem einfach die URL angegeben wird.
|
||||
Beachten Sie, dass Funktionen auch die Möglichkeit bieten, den Code an einem entfernten Ort zu speichern, indem Sie einfach die URL dazu angeben.
|
||||
|
||||
### Networking
|
||||
|
||||
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. Es ist jedoch auch möglich, diesen Zugriff einzuschränken.
|
||||
- Es ist auch möglich, **Zugriff zu gewähren oder einzuschränken** auf eine Function App von **einem internen Netzwerk (VPC)**.
|
||||
- Es ist auch möglich, **Zugriff auf eine Function App von einem internen Netzwerk (VPC)** zu gewähren oder einzuschränken.
|
||||
|
||||
> [!CAUTION]
|
||||
> 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, zu **internen Netzwerken zu pivotieren**.
|
||||
> 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**
|
||||
|
||||
@@ -56,27 +56,27 @@ In einer **Windows**-Funktion, die NodeJS verwendet, befand sich der Code in **`
|
||||
|
||||
### **Verwaltete Identitäten & Metadaten**
|
||||
|
||||
Genau wie [**VMs**](vms/), können Funktionen **verwaltete Identitäten** von 2 Typen haben: Systemzugewiesen und Benutzerzugewiesen.
|
||||
Genau wie bei [**VMs**](vms/index.html) können Funktionen **verwaltete Identitäten** von 2 Typen haben: Systemzugewiesen und Benutzerzugewiesen.
|
||||
|
||||
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]
|
||||
> Genau wie bei [**VMs**](vms/) können Funktionen **1 systemzugewiesene** verwaltete Identität und **mehrere benutzerzugewiesene** haben, daher ist es immer wichtig, zu versuchen, 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.
|
||||
> Genau wie bei [**VMs**](vms/index.html) können Funktionen **1 systemzugewiesene** verwaltete Identität und **mehrere benutzerzugewiesene** haben, daher ist es immer wichtig, zu versuchen, 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 systemverwaltete 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.
|
||||
> 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 Tokens von der standardmäßigen verwalteten Identität vom Metadaten-Endpunkt 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 Token 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" %}
|
||||
|
||||
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 Metadaten-Endpunkt **nur die standardmäßige verwenden wird** (siehe den vorherigen Link für weitere Informationen).
|
||||
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]
|
||||
> Beachten Sie, dass es keine RBAC-Berechtigungen gibt, um Benutzern den Zugriff auf die Funktionen zu gewähren. Der **Funktionsaufruf 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.
|
||||
> 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 **Autorisierungsniveau des Zugriffsschlüssels** anzugeben, das erforderlich ist, um die Funktion auszulösen. Drei Optionen sind verfügbar:
|
||||
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:
|
||||
|
||||
- **ANONYMOUS**: **Jeder** kann über die URL auf die Funktion zugreifen.
|
||||
- **FUNCTION**: Der Endpunkt ist nur für Benutzer zugänglich, die einen **Funktions-, Host- oder Master-Schlüssel** verwenden.
|
||||
@@ -85,7 +85,7 @@ Beim Erstellen eines Endpunkts innerhalb einer Funktion mit einem **HTTP-Trigger
|
||||
**Arten von Schlüsseln:**
|
||||
|
||||
- **Funktionsschlüssel:** Funktionsschlüssel können entweder standardmäßig oder benutzerdefiniert sein und sind so konzipiert, dass sie ausschließlich den Zugriff auf **spezifische Funktionsendpunkte** innerhalb einer Function App gewähren, was einen feineren Zugriff auf die Endpunkte ermöglicht.
|
||||
- **Host-Schlüssel:** Host-Schlüssel, die ebenfalls standardmäßig oder benutzerdefiniert sein können, gewähren Zugriff auf **alle Funktionsendpunkte innerhalb einer Function App mit FUNKTION-Zugriffslevel**.
|
||||
- **Host-Schlüssel:** Host-Schlüssel, die ebenfalls standardmäßig oder benutzerdefiniert sein können, gewähren Zugriff auf **alle Funktionsendpunkte innerhalb einer Function App mit FUNCTION-Zugriffslevel**.
|
||||
- **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.
|
||||
|
||||
@@ -99,7 +99,7 @@ Beim Erstellen eines Endpunkts innerhalb einer Funktion mit einem **HTTP-Trigger
|
||||
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-service.md
|
||||
az-app-services.md
|
||||
{{#endref}}
|
||||
|
||||
### Github-basierte Bereitstellungen
|
||||
@@ -192,14 +192,14 @@ package: ${{ env.AZURE_FUNCTIONAPP_PACKAGE_PATH }}
|
||||
```
|
||||
</details>
|
||||
|
||||
Darüber hinaus wird eine **Managed Identity** erstellt, damit die Github Action aus dem Repository sich damit bei Azure anmelden kann. Dies geschieht durch die Generierung einer föderierten Anmeldeinformation über die **Managed Identity**, die den **Issuer** `https://token.actions.githubusercontent.com` und den **Subject Identifier** `repo:<org-name>/<repo-name>:ref:refs/heads/<branch-name>` ermöglicht.
|
||||
Darüber hinaus wird eine **Managed Identity** erstellt, damit die Github Action aus dem Repository sich damit bei Azure anmelden kann. Dies geschieht durch die Generierung einer föderierten Berechtigung über die **Managed Identity**, die den **Issuer** `https://token.actions.githubusercontent.com` und den **Subject Identifier** `repo:<org-name>/<repo-name>:ref:refs/heads/<branch-name>` ermöglicht.
|
||||
|
||||
> [!CAUTION]
|
||||
> Daher kann jeder, der dieses Repository kompromittiert, die Funktion und die daran angehängten Managed Identities kompromittieren.
|
||||
|
||||
### Containerbasierte Bereitstellungen
|
||||
|
||||
Nicht alle Pläne erlauben die Bereitstellung von Containern, aber für die, die es tun, enthält die Konfiguration die URL des Containers. In der API wird die **`linuxFxVersion`**-Einstellung etwas wie `DOCKER|mcr.microsoft.com/...` haben, während in der Webkonsole die Konfiguration die **Bildeinstellungen** anzeigen wird.
|
||||
Nicht alle Pläne erlauben die Bereitstellung von Containern, aber für die, die es tun, wird die Konfiguration die URL des Containers enthalten. In der API wird die **`linuxFxVersion`** Einstellung etwas wie: `DOCKER|mcr.microsoft.com/...` haben, während in der Webkonsole die Konfiguration die **Bildeinstellungen** anzeigen wird.
|
||||
|
||||
Darüber hinaus wird **kein Quellcode im Speicher**-Konto gespeichert, das mit der Funktion verbunden ist, da dies nicht erforderlich ist.
|
||||
|
||||
@@ -249,7 +249,7 @@ curl "https://newfuncttest123.azurewebsites.net/admin/vfs/home/site/wwwroot/func
|
||||
# Get source code
|
||||
az rest --url "https://management.azure.com/<subscription>/resourceGroups/<res-group>/providers/Microsoft.Web/sites/<app-name>/hostruntime/admin/vfs/function_app.py?relativePath=1&api-version=2022-03-01"
|
||||
```
|
||||
## Privilegienausnutzung
|
||||
## Privilegienerweiterung
|
||||
|
||||
{{#ref}}
|
||||
../az-privilege-escalation/az-functions-app-privesc.md
|
||||
|
||||
Reference in New Issue
Block a user