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

2026-07-28 22:51:09 -07:00 · 2026-07-09 16:57:41 +00:00
parent d7d2d7d27c
commit b78b6096b1
1 changed files with 70 additions and 69 deletions
@@ -4,49 +4,49 @@

 ## Informations de base

-Azure Storage Accounts sont des services fondamentaux dans Microsoft Azure qui fournissent un cloud **storage évolutif, sécurisé et hautement disponible pour divers types de données**, y compris les blobs (binary large objects), files, queues et tables. Ils servent de conteneurs qui regroupent ces différents services de stockage sous un seul namespace pour faciliter la gestion.
+Les Azure Storage Accounts sont des services fondamentaux dans Microsoft Azure qui fournissent un **stockage cloud** évolutif, sécurisé et hautement उपलब्ध pour différents types de données, y compris les blobs (binary large objects), files, queues et tables. Elles servent de conteneurs qui regroupent ces différents services de stockage sous un seul namespace pour une gestion facile.

-**Main configuration options** :
+**Principales options de configuration** :

- Chaque storage account doit avoir un **nom uniq dans tout Azure**.
- Chaque storage account est déployé dans une **region** ou dans une Azure extended zone
+- Chaque storage account doit avoir un **nom unique dans tout Azure**.
+- Chaque storage account est déployé dans une **région** ou dans une Azure extended zone
 - Il est possible de sélectionner la version **premium** du storage account pour de meilleures performances
- Il est possible de sélectionner parmi **4 types de redundancy pour protéger** contre les **failures** de rack, de disque et de datacenter.
+- Il est possible de sélectionner parmi **4 types de redundancy** pour protéger contre les pannes de rack, de disque et de datacenter.

-**Security configuration options** :
+**Options de configuration de sécurité** :

- **Require secure transfer for REST API operations** : Exiger TLS pour toute communication avec le storage
+- **Require secure transfer for REST API operations** : Exiger TLS dans toute communication avec le stockage
 - **Allows enabling anonymous access on individual containers** : Sinon, il ne sera pas possible d’activer l’accès anonyme à l’avenir
 - **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 un storage account avec private endpoints dans le même virtual network.

-**Blob Storage options** :
+**Options Blob Storage** :

 - **Allow cross-tenant replication**
- **Access tier** : Hot (données fréquemment accédées), Cool et Cold (rarely accessed data)
+- **Access tier** : Hot (données fréquemment consultées), Cool et Cold (données rarement consultées)

-**Networking options** :
+**Options réseau** :

 - **Network access** :
- Autoriser depuis tous les networks
- Autoriser depuis des virtual networks et des adresses IP sélectionnés
+- Autoriser depuis tous les réseaux
+- Autoriser depuis des virtual networks et adresses IP sélectionnés
 - Désactiver l’accès public et utiliser un accès privé
- **Private endpoints** : Cela permet une connexion privée au storage account depuis un virtual network
+- **Private endpoints** : Permet une connexion privée au storage account depuis un virtual network

-**Data protection options** :
+**Options de protection des données** :

- **Point-in-time restore for containers** : Permet de restaurer les containers à un état antérieur
+- **Point-in-time restore for containers** : Permet de restaurer des containers à un état antérieur
 - Cela nécessite que versioning, change feed et blob soft delete soient activés.
- **Enable soft delete for blobs** : Cela active une période de rétention en jours pour les blobs supprimés (même écrasés)
- **Enable soft delete for containers** : Cela active une période de rétention en jours pour les containers supprimés
- **Enable soft delete for file shares** : Cela active une période de rétention en jours pour les file shared supprimés
+- **Enable soft delete for blobs** : Active une période de rétention en jours pour les blobs supprimés (y compris é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 shared supprimés
 - **Enable versioning for blobs** : Conserver les versions précédentes de vos blobs
- **Enable blob change feed** : Conserver les logs des changements de création, modification et suppression sur les blobs
- **Enable version-level immutability support** : Vous permet de définir une stratégie de rétention basée sur le temps au niveau du compte qui s’appliquera à toutes les versions de blob.
- Version-level immutability support et point-in-time restore for containers ne peuvent pas être activés simultanément.
+- **Enable blob change feed** : Conserver les logs des créations, modifications et suppressions de 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 blobs.
+- Le support de l’immutability au niveau de la version et le point-in-time restore for containers ne peuvent pas être activés simultanément.

-**Encryption configuration options** :
+**Options de configuration du chiffrement** :

 - **Encryption type** : Il est possible d’utiliser des Microsoft-managed keys (MMK) ou Customer-managed keys (CMK)
 - **Enable infrastructure encryption** : Permet de chiffrer les données deux fois "for more security"
@@ -62,21 +62,21 @@ Azure Storage Accounts sont des services fondamentaux dans Microsoft Azure qui f
 | **Queue storage** | `https://<storage-account>.queue.core.windows.net` |
 | **Table storage** | `https://<storage-account>.table.core.windows.net` |

-### Public Exposure
+### Exposition publique

-Si "Allow Blob public access" est **enabled** (désactivé par défaut), lors de la création d’un container il est possible de :
+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 pour lire les blobs** (vous devez connaître le nom).
 - **Lister les blobs du container** et les **lire**.
- Le rendre totalement **private**
+- Le rendre totalement **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`) & secrets leakés

- **Static websites** are served from the special `$web` container over a region-specific endpoint such as `https://<account>.z13.web.core.windows.net/`.
- The `$web` container may report `publicAccess: null` via the blob API, but files are still reachable through the static site endpoint, so dropping config/IaC artifacts there can leak secrets.
- Quick audit workflow:
+- Les **sites statiques** sont servis depuis le container spécial `$web` via un endpoint spécifique à la région, comme `https://<account>.z13.web.core.windows.net/`.
+- Le container `$web` peut afficher `publicAccess: null` via l’API blob, mais les fichiers restent accessibles via le endpoint du site statique, donc y déposer des artefacts de config/IaC peut leak des secrets.
+- Flux 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
@@ -89,8 +89,8 @@ az storage blob download -c '$web' --name iac/terraform.tfvars --file /dev/stdou
 ```
 ### Auditer l'exposition anonyme des blobs

- **Localisez les storage accounts** qui peuvent 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 à risque** pour confirmer le flag et d'autres paramètres faibles : `az storage account show --name <acc> --query '{allow:properties.allowBlobPublicAccess, minTls:properties.minimumTlsVersion}'`.
+- **Localisez les storage accounts** qui peuvent 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 à 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érez l'exposition au niveau des containers** lorsque le flag est activé :
 ```bash
 az storage container list --account-name <acc> \
@@ -99,7 +99,7 @@ az storage container list --account-name <acc> \
 - `"Blob"`: lectures anonymes autorisées **uniquement lorsque le nom du blob est connu** (pas de listing).
 - `"Container"`: **list + read** anonymes de chaque blob.
 - `null`: privé ; authentification requise.
- **Prouver l’accès** sans identifiants :
+- **Prouver l'accès** sans credentials :
 - 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 du blob fonctionne lorsque le nom est connu :
 ```bash
@@ -109,31 +109,31 @@ curl "https://<acc>.blob.core.windows.net/<container>/<blob>"
 ```
 ### Connect to Storage

-If you find any **storage** you can connect to you could use the tool [**Microsoft Azure Storage Explorer**](https://azure.microsoft.com/es-es/products/storage/storage-explorer/) to do so.
+Si vous trouvez un **storage** 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 le faire.

 ## Access to Storage <a href="#about-blob-storage" id="about-blob-storage"></a>

 ### RBAC

-Il est possible d’utiliser des principaux Entra ID avec des **RBAC roles** pour accéder aux storage accounts, 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 storage accounts, et c'est la méthode recommandée.

 ### Access Keys

-Les storage accounts ont des access keys qui peuvent être utilisées pour y accéder. Cela fournit un accès **complet au storage account.**
+Les storage accounts ont des access keys qui peuvent être utilisées pour y accéder. Cela fournit un **accès complet au storage account.**

 <figure><img src="../../../images/image (5).png" alt=""><figcaption></figcaption></figure>

 ### **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 access keys pour autoriser l’accès à certaines ressources via une signed URL.
+Il est possible de [**generate Shared Keys**](https://learn.microsoft.com/en-us/rest/api/storageservices/authorize-with-shared-key), signées avec les access keys, pour autoriser l'accès à certaines ressources via une URL signée.

 > [!NOTE]
-> Note that the `CanonicalizedResource` part represents the storage services resource (URI). And if any part in the URL is encoded, it should also be encoded inside the `CanonicalizedResource`.
+> Notez que la partie `CanonicalizedResource` représente la ressource des storage services (URI). Et si une partie de l'URL est encodée, elle doit aussi être encodée à l'intérieur de `CanonicalizedResource`.

 > [!NOTE]
-> This is **used by default by `az` cli** to authenticate requests. To make it use the Entra ID principal credentials indicate the param `--auth-mode login`.
+> Ceci est **used by default by `az` cli** pour authentifier les requêtes. Pour le faire utiliser les identifiants du principal Entra ID, indiquez 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 pour blob, queue et file services** en signant les informations suivantes :
 ```bash
 StringToSign = VERB + "\n" +
 Content-Encoding + "\n" +
@@ -158,7 +158,7 @@ Content-Type + "\n" +
 Date + "\n" +
 CanonicalizedResource;
 ```
- Il est possible de générer une **lite shared key pour blob, queue and file services** en signant les informations suivantes :
+- Il est possible de générer une **lite shared key pour blob, queue et file services** en signant les informations suivantes :
 ```bash
 StringToSign = VERB + "\n" +
 Content-MD5 + "\n" +
@@ -167,12 +167,12 @@ Date + "\n" +
 CanonicalizedHeaders +
 CanonicalizedResource;
 ```
- Il est possible de générer une **lite shared key for table services** en signant les informations suivantes :
+- Il est possible de générer une **lite shared key for table services** en signant les informations suivantes:
 ```bash
 StringToSign = Date + "\n"
 CanonicalizedResource
 ```
-Puis, pour utiliser la key, cela peut être fait dans l'en-tête Authorization suivant la syntaxe :
+Puis, pour utiliser la clé, cela peut être fait dans l'en-tête Authorization en suivant la syntaxe :
 ```bash
 Authorization="[SharedKey|SharedKeyLite] <AccountName>:<Signature>"
 #e.g.
@@ -186,14 +186,14 @@ Content-Length: 0
 ```
 ### **Shared Access Signature** (SAS)

-Shared Access Signatures (SAS) sont des URLs sécurisées à durée limitée qui **octroient des permissions spécifiques pour accéder à des resources** dans un compte Azure Storage sans exposer les access keys du compte. Alors que les access keys fournissent un accès administratif complet à toutes les resources, SAS permet un contrôle granulaire en spécifiant des permissions (comme read ou write) et en définissant une date d’expiration.
+Shared Access Signatures (SAS) sont des URL sécurisées à durée limitée 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 donnent un accès administratif complet à toutes les ressources, SAS permet un contrôle granulaire en spécifiant des permissions (comme read ou write) et en définissant une date d’expiration.

 #### SAS Types

- **User delegation SAS** : Il 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 **revoke** tous les user delegated SAS générés.
- Même s’il est possible de générer un delegation SAS avec plus de permissions que celles de l’utilisateur. Cependant, si le principal ne les a pas, cela ne fonctionnera pas (no privesc).
- **Service SAS** : Il est signé à l’aide d’une des **access keys** du storage account. Il peut être utilisé pour octroyer l’accès à des resources spécifiques dans un seul storage service. Si la key est renouvelée, le SAS cessera de fonctionner.
- **Account SAS** : Il est aussi signé avec l’une des **access keys** du storage account. Il octroie l’accès à des resources à travers plusieurs services du storage account (Blob, Queue, Table, File) et peut inclure des opérations au niveau du service.
+- **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 vers le 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 **revoke** tous les user delegated SAS générés.
+- Même s’il est possible de générer un delegation SAS avec davantage de permissions que celles de l’utilisateur. Cependant, si le principal ne les a pas, cela ne fonctionnera pas (pas de privesc).
+- **Service SAS**: Celui-ci est signé à l’aide de l’une des **access keys** 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 **access keys** 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 SAS URL signée par une **access key** ressemble à ceci :

@@ -203,51 +203,51 @@ Une SAS URL signée en tant que **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`

-Notez certains **http params** :
+Note some **http params** :

 - 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
+- Le **`sig`** est la **signature** qui valide le SAS

 #### SAS permissions

-Lors de la génération d’un SAS, il faut indiquer les permissions qu’il doit octroyer. Selon l’objet sur lequel le SAS est généré, différentes permissions peuvent être incluses. Par exemple :
+Lors de la génération d’un SAS, il faut 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 :

 - (a)dd, (c)reate, (d)elete, (e)xecute, (f)ilter_by_tags, (i)set_immutability_policy, (l)ist, (m)ove, (r)ead, (t)ag, (w)rite, (x)delete_previous_version, (y)permanent_delete

 ## SFTP Support for Azure Blob Storage

-Azure Blob Storage prend désormais en charge le SSH File Transfer Protocol (SFTP), permettant un transfert et une gestion sécurisés des fichiers directement vers Blob Storage sans nécessiter de solutions personnalisées ni de produits tiers.
+Azure Blob Storage prend désormais en charge le SSH File Transfer Protocol (SFTP), permettant le transfert sécurisé de fichiers et leur gestion directement vers Blob Storage sans nécessiter de solutions personnalisées ni de produits tiers.

 ### Key Features

- Protocol Support: SFTP fonctionne avec des comptes Blob Storage configurés avec hierarchical namespace (HNS). Cela organise les blobs en directories et subdirectories pour faciliter la navigation.
- Security: SFTP utilise des local user identities pour l’authentification et ne s’intègre pas avec RBAC or ABAC. Chaque local user peut s’authentifier via :
+- Protocol Support: SFTP fonctionne avec des comptes Blob Storage configurés avec hierarchical namespace (HNS). Cela organise les blobs en répertoires et sous-répertoires pour une navigation plus facile.
+- Security: SFTP peut utiliser des identités d’utilisateurs locaux, mais il prend aussi en charge l’accès basé sur Microsoft Entra ID avec Azure RBAC pour l’autorisation. Cela signifie que l’accès peut être accordé avec les rôles Blob Storage data-plane habituels au lieu de créer des utilisateurs SFTP locaux. Les utilisateurs locaux peuvent s’authentifier via :
 - Azure-generated passwords
 - Public-private SSH key pairs
- Granular Permissions: Des permissions telles que Read, Write, Delete et List peuvent être attribuées à des local users pour jusqu’à 100 containers.
- Networking Considerations: Les connexions SFTP passent par le port 22. Azure prend en charge des configurations réseau comme firewalls, private endpoints, ou virtual networks pour sécuriser le trafic SFTP.
+- Granular Permissions: Des permissions telles que Read, Write, Delete et List peuvent être attribuées aux utilisateurs locaux pour jusqu’à 100 containers.
+- Networking Considerations: Les connexions SFTP passent par 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.

 ### Setup Requirements

- Hierarchical Namespace: HNS doit être activé lors de la création du storage account.
- Supported Encryption: Nécessite des algorithmes cryptographiques approuvés par Microsoft Security Development Lifecycle (SDL) (par ex. rsa-sha2-256, ecdsa-sha2-nistp256).
+- Hierarchical Namespace: HNS doit être activé lors de la création du compte de stockage.
+- Supported Encryption: Requiert des algorithmes cryptographiques approuvés par Microsoft Security Development Lifecycle (SDL) (par ex. rsa-sha2-256, ecdsa-sha2-nistp256).
 - SFTP Configuration:
- Activer SFTP sur le storage account.
- Créer des local user identities avec les permissions appropriées.
- Configurer les home directories des users pour définir leur emplacement de départ dans le container.
+- Activer SFTP sur le compte de stockage.
+- Pour l’accès local-user, créer des identités d’utilisateurs locaux avec les permissions appropriées.
+- Pour les utilisateurs locaux, configurer des home directories afin de définir leur emplacement de départ dans le container.

 ### Permissions

 | Permission             | Symbol | Description                          |
 | ---------------------- | ------ | ------------------------------------ |
 | **Read**               | `r`    | Lire le contenu du fichier.          |
-| **Write**              | `w`    | Upload des fichiers et création de directories. |
-| **List**               | `l`    | Lister le contenu des directories.   |
-| **Delete**             | `d`    | Supprimer des fichiers ou directories. |
-| **Create**             | `c`    | Créer des fichiers ou directories.   |
-| **Modify Ownership**   | `o`    | Changer le user ou group propriétaire. |
-| **Modify Permissions** | `p`    | Modifier les ACLs sur des fichiers ou directories. |
+| **Write**              | `w`    | Téléverser des fichiers et créer des répertoires. |
+| **List**               | `l`    | Lister le contenu des répertoires.   |
+| **Delete**             | `d`    | Supprimer des fichiers ou des répertoires. |
+| **Create**             | `c`    | Créer des fichiers ou des répertoires. |
+| **Modify Ownership**   | `o`    | Modifier l’utilisateur ou le groupe propriétaire. |
+| **Modify Permissions** | `p`    | Modifier les ACLs sur des fichiers ou des répertoires. |

 ## Enumeration

@@ -448,7 +448,7 @@ New-AzStorageBlobSASToken `
 az-file-shares.md
 {{#endref}}

-## Escalade de privilèges
+## Privilege Escalation

 {{#ref}}
 ../az-privilege-escalation/az-storage-privesc.md
@@ -460,17 +460,18 @@ az-file-shares.md
 ../az-post-exploitation/az-blob-storage-post-exploitation.md
 {{#endref}}

-## Persistance
+## Persistence

 {{#ref}}
 ../az-persistence/az-storage-persistence.md
 {{#endref}}

-## Références
+## References

 - [https://learn.microsoft.com/en-us/azure/storage/blobs/storage-blobs-introduction](https://learn.microsoft.com/en-us/azure/storage/blobs/storage-blobs-introduction)
 - [https://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview](https://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview)
 - [https://learn.microsoft.com/en-us/azure/storage/blobs/secure-file-transfer-protocol-support](https://learn.microsoft.com/en-us/azure/storage/blobs/secure-file-transfer-protocol-support)
+- [https://learn.microsoft.com/en-us/azure/storage/blobs/secure-file-transfer-protocol-support-entra-id-based-access](https://learn.microsoft.com/en-us/azure/storage/blobs/secure-file-transfer-protocol-support-entra-id-based-access)
 - [Holiday Hack Challenge 2025 – Spare Key (Azure static website SAS leak)](https://0xdf.gitlab.io/holidayhack2025/act1/spare-key)
 - [Holiday Hack Challenge 2025: Blob Storage (Storage Secrets)](https://0xdf.gitlab.io/holidayhack2025/act1/blob-storage)
 - [https://learn.microsoft.com/en-us/cli/azure/storage/account](https://learn.microsoft.com/en-us/cli/azure/storage/account)