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-services/az-stor

Browse Source
This commit is contained in:
Translator
2026-07-09 16:57:48 +00:00
parent 645dee1cd8
commit 35ae0fe55b
1 changed files with 69 additions and 68 deletions
Download Patch File Download Diff File Expand all files Collapse all files
src/pentesting-cloud/azure-security/az-services/az-storage.md
+69 -68
View File
@@ -2,54 +2,54 @@
{{#include ../../../banners/hacktricks-training.md}}
## Basic Information
## Grundlegende Informationen
Azure Storage Accounts sind grundlegende Services in Microsoft Azure, die skalierbaren, sicheren und hochverfügbaren Cloud-**storage for various data types** bereitstellen, einschließlich blobs (binary large objects), files, queues und tables. Sie dienen als Container, die diese verschiedenen storage services unter einem einzigen namespace für einfache Verwaltung zusammenfassen.
Azure Storage Accounts sind grundlegende Services in Microsoft Azure, die skalierbaren, sicheren und hochverfügbaren Cloud-**Storage für verschiedene Datentypen** bereitstellen, darunter blobs (binary large objects), files, queues und tables. Sie dienen als Container, die diese unterschiedlichen Storage-Services unter einem einzigen Namespace für eine einfache Verwaltung zusammenfassen.
**Main configuration options**:
**Wichtige Konfigurationsoptionen**:
- Every storage account must have a **uniq name across all Azure**.
- Every storage account is deployed in a **region** or in an Azure extended zone
- It's possible to select the **premium** version of the storage account for better performance
- It's possible to select among **4 types of redundancy to protect** against rack, drive and datacenter **failures**.
- Jeder storage account muss einen **eindeutigen Namen innerhalb von Azure** haben.
- Jeder storage account wird in einer **Region** oder in einer Azure-Extended-Zone bereitgestellt
- Es ist möglich, die **premium**-Version des storage account für bessere Performance auszuwählen
- Es ist möglich, zwischen **4 Arten von Redundanz zu wählen, um sich** gegen Rack-, Drive- und Datacenter-**Ausfälle** zu schützen.
**Security configuration options**:
**Security-Konfigurationsoptionen**:
- **Require secure transfer for REST API operations**: Require TLS in any communication with the storage
- **Allows enabling anonymous access on individual containers**: If not, it won't be possible to enable anonymous access in the future
- **Enable storage account key access**: If not, access with Shared Keys will be forbidden
- **Require secure transfer for REST API operations**: TLS bei jeder Kommunikation mit dem Storage erzwingen
- **Allows enabling anonymous access on individual containers**: Wenn nicht, ist es in Zukunft nicht möglich, anonymen Zugriff zu aktivieren
- **Enable storage account key access**: Wenn nicht, wird der Zugriff mit Shared Keys verboten
- **Minimum TLS version**
- **Permitted scope for copy operations**: Allow from any storage account, from any storage account from the same Entra tenant or from storage account with private endpoints in the same virtual network.
- **Permitted scope for copy operations**: Erlaubt von jedem storage account, von jedem storage account aus demselben Entra tenant oder von storage account mit private endpoints im selben virtual network.
**Blob Storage options**:
**Blob Storage-Optionen**:
- **Allow cross-tenant replication**
- **Access tier**: Hot (frequently access data), Cool and Cold (rarely accessed data)
- **Access tier**: Hot (häufig abgerufene Daten), Cool und Cold (selten abgerufene Daten)
**Networking options**:
**Networking-Optionen**:
- **Network access**:
- Allow from all networks
- Allow from selected virtual networks and IP addresses
- Disable public access and use private access
- **Private endpoints**: It allows a private connection to the storage account from a virtual network
- Zugriff von allen networks erlauben
- Zugriff von ausgewählten virtual networks und IP addresses erlauben
- Public access deaktivieren und private access verwenden
- **Private endpoints**: Ermöglicht eine private Verbindung zum storage account aus einem virtual network
**Data protection options**:
**Data protection-Optionen**:
- **Point-in-time restore for containers**: Allows to restore containers to an earlier state
- It requires versioning, change feed, and blob soft delete to be enabled.
- **Enable soft delete for blobs**: It enables a retention period in days for deleted blobs (even overwritten)
- **Enable soft delete for containers**: It enables a retention period in days for deleted containers
- **Enable soft delete for file shares**: It enables a retention period in days for deleted file shared
- **Enable versioning for blobs**: Maintain previous versions of your blobs
- **Enable blob change feed**: Keep logs of create, modification, and delete changes to blobs
- **Enable version-level immutability support**: Allows you to set time-based retention policy on the account-level that will apply to all blob versions.
- Version-level immutability support and point-in-time restore for containers cannot be enabled simultaneously.
- **Point-in-time restore for containers**: Ermöglicht es, containers auf einen früheren Zustand wiederherzustellen
- Es erfordert, dass versioning, change feed und blob soft delete aktiviert sind.
- **Enable soft delete for blobs**: Aktiviert eine Aufbewahrungsdauer in Tagen für gelöschte blobs (auch überschrieben)
- **Enable soft delete for containers**: Aktiviert eine Aufbewahrungsdauer in Tagen für gelöschte containers
- **Enable soft delete for file shares**: Aktiviert eine Aufbewahrungsdauer in Tagen für gelöschte file shared
- **Enable versioning for blobs**: Frühere Versionen deiner blobs beibehalten
- **Enable blob change feed**: Logs für create-, modification- und delete-Änderungen an blobs behalten
- **Enable version-level immutability support**: Erlaubt dir, eine zeitbasierte Retention Policy auf Account-Ebene festzulegen, die für alle blob versions gilt.
- Version-level immutability support und point-in-time restore for containers können nicht gleichzeitig aktiviert werden.
**Encryption configuration options**:
**Encryption-Konfigurationsoptionen**:
- **Encryption type**: It's possible to use Microsoft-managed keys (MMK) or Customer-managed keys (CMK)
- **Enable infrastructure encryption**: Allows to double encrypt the data "for more security"
- **Encryption type**: Es ist möglich, Microsoft-managed keys (MMK) oder Customer-managed keys (CMK) zu verwenden
- **Enable infrastructure encryption**: Ermöglicht eine doppelte Verschlüsselung der Daten „für mehr Sicherheit“
### Storage endpoints
@@ -62,13 +62,13 @@ Azure Storage Accounts sind grundlegende Services in Microsoft Azure, die skalie
| **Queue storage** | `https://<storage-account>.queue.core.windows.net` |
| **Table storage** | `https://<storage-account>.table.core.windows.net` |
### Public Exposure
### Öffentliche Exponierung
If "Allow Blob public access" is **enabled** (disabled by default), when creating a container it's possible to:
Wenn "Allow Blob public access" **aktiviert** ist (standardmäßig deaktiviert), ist beim Erstellen eines Containers Folgendes möglich:
- Give **public access to read blobs** (you need to know the name).
- **List container blobs** and **read** them.
- Make it fully **private**
- **Öffentlichen Zugriff auf blobs zum Lesen gewähren** (du musst den Namen kennen).
- Container-blobs **auflisten** und **lesen**.
- Alles vollständig **privat** machen
<figure><img src="https://lh7-rt.googleusercontent.com/slidesz/AGV_vUfoetUnYBPWQpRrWNnnlbqWpl8Rdoaeg5uBrCVlvcNDlnKwQHjZe8nUb2SfPspBgbu-lCZLmUei-hFi_Jl2eKbaxUtBGTjdUSDmkrcwr90VZkmuMjk9tyh92p75btfyzGiUTa0-=s2048?key=m8TV59TrCFPlkiNnmhYx3aZt" alt=""><figcaption></figcaption></figure>
@@ -89,19 +89,19 @@ az storage blob download -c '$web' --name iac/terraform.tfvars --file /dev/stdou
```
### Auditing anonymous blob exposure
- **Storage-Accounts lokalisieren**, die Daten exponieren können: `az storage account list | jq -r '.[] | select(.properties.allowBlobPublicAccess==true) | .name'`. Wenn `allowBlobPublicAccess` `false` ist, kannst du Container nicht public machen.
- **Riskante Accounts prüfen**, um den Flag und andere schwache Settings zu bestätigen: `az storage account show --name <acc> --query '{allow:properties.allowBlobPublicAccess, minTls:properties.minimumTlsVersion}'`.
- **Container-Level-Exposure auflisten**, bei der der Flag aktiviert ist:
- **Speicherkonten lokalisieren**, die Daten exponieren können: `az storage account list | jq -r '.[] | select(.properties.allowBlobPublicAccess==true) | .name'`. Wenn `allowBlobPublicAccess` `false` ist, kannst du Container nicht public machen.
- **Riskante Konten prüfen**, um das Flag und andere schwache Einstellungen zu bestätigen: `az storage account show --name <acc> --query '{allow:properties.allowBlobPublicAccess, minTls:properties.minimumTlsVersion}'`.
- **Container-level exposure auflisten**, wenn das Flag aktiviert ist:
```bash
az storage container list --account-name <acc> \
--query '[].{name:name, access:properties.publicAccess}'
```
- `"Blob"`: anonyme Reads sind **nur erlaubt, wenn der Blob-Name bekannt ist** (kein Listing).
- `"Blob"`: anonyme Reads nur **wenn der Blob-Name bekannt ist** (kein Listing).
- `"Container"`: anonymes **list + read** von jedem Blob.
- `null`: privat; Authentifizierung erforderlich.
- **Zugriff nachweisen** ohne Credentials:
- `null`: privat; Authentication erforderlich.
- **Zugriff nachweisen** ohne credentials:
- Wenn `publicAccess` `Container` ist, funktioniert anonymes Listing: `curl "https://<acc>.blob.core.windows.net/<container>?restype=container&comp=list"`.
- Für sowohl `Blob` als auch `Container` funktioniert anonymes Blob-Download, wenn der Name bekannt ist:
- Für sowohl `Blob` als auch `Container` funktioniert anonymes Downloaden eines Blobs, wenn der Name bekannt ist:
```bash
az storage blob download -c <container> -n <blob> --account-name <acc> --file /dev/stdout
# or via raw HTTP
@@ -109,7 +109,7 @@ curl "https://<acc>.blob.core.windows.net/<container>/<blob>"
```
### Connect to Storage
Wenn du irgendeinen **storage** findest, auf den du dich verbinden kannst, könntest du das Tool [**Microsoft Azure Storage Explorer**](https://azure.microsoft.com/es-es/products/storage/storage-explorer/) dafür verwenden.
Wenn du irgendeinen **storage** findest, zu dem du dich verbinden kannst, könntest du das Tool [**Microsoft Azure Storage Explorer**](https://azure.microsoft.com/es-es/products/storage/storage-explorer/) dafür verwenden.
## Access to Storage <a href="#about-blob-storage" id="about-blob-storage"></a>
@@ -119,7 +119,7 @@ Es ist möglich, Entra ID principals mit **RBAC roles** zu verwenden, um auf sto
### Access Keys
Die storage accounts haben access keys, die verwendet werden können, um auf sie zuzugreifen. Das bietet f**ull access to the storage account.**
Die storage accounts haben access keys, die verwendet werden können, um darauf zuzugreifen. Das bietet vollen Zugriff auf den storage account.
<figure><img src="../../../images/image (5).png" alt=""><figcaption></figcaption></figure>
@@ -128,12 +128,12 @@ Die storage accounts haben access keys, die verwendet werden können, um auf sie
Es ist möglich, [**Shared Keys zu generieren**](https://learn.microsoft.com/en-us/rest/api/storageservices/authorize-with-shared-key), die mit den access keys signiert sind, um den Zugriff auf bestimmte Ressourcen über eine signierte URL zu autorisieren.
> [!NOTE]
> Beachte, dass der `CanonicalizedResource`-Teil die storage services resource (URI) darstellt. Und wenn irgendein Teil in der URL kodiert ist, sollte er auch innerhalb von `CanonicalizedResource` kodiert sein.
> Beachte, dass der Teil `CanonicalizedResource` die Ressource der storage services (URI) darstellt. Und wenn irgendein Teil in der URL kodiert ist, sollte er auch innerhalb von `CanonicalizedResource` kodiert sein.
> [!NOTE]
> Das wird standardmäßig vom `az` cli verwendet, um Requests zu authentifizieren. Damit es die Entra ID principal credentials verwendet, gib den Param `--auth-mode login` an.
> Dies wird standardmäßig vom `az` cli verwendet, um Requests zu authentifizieren. Damit es die Entra ID principal credentials verwendet, gib den Parameter `--auth-mode login` an.
- Es ist möglich, einen **shared key für blob, queue and file services** zu generieren, indem die folgenden Informationen signiert werden:
- Es ist möglich, einen **shared key für blob, queue und file services** zu generieren, indem die folgenden Informationen signiert werden:
```bash
StringToSign = VERB + "\n" +
Content-Encoding + "\n" +
@@ -158,7 +158,7 @@ Content-Type + "\n" +
Date + "\n" +
CanonicalizedResource;
```
- Es ist möglich, einen **lite shared key für blob, queue und file services** zu generieren, indem die folgenden Informationen signiert werden:
- Es ist möglich, einen **lite shared key for blob, queue and file services** zu generieren, indem die folgenden Informationen signiert werden:
```bash
StringToSign = VERB + "\n" +
Content-MD5 + "\n" +
@@ -172,7 +172,7 @@ CanonicalizedResource;
StringToSign = Date + "\n"
CanonicalizedResource
```
Dann kann der key verwendet werden, indem er im Authorization-Header mit der folgenden Syntax angegeben wird:
Dann kann der Schlüssel verwendet werden, indem er im Authorization-Header mit der folgenden Syntax angegeben wird:
```bash
Authorization="[SharedKey|SharedKeyLite] <AccountName>:<Signature>"
#e.g.
@@ -186,14 +186,14 @@ Content-Length: 0
```
### **Shared Access Signature** (SAS)
Shared Access Signatures (SAS) sind sichere, zeitlich begrenzte URLs, die **spezifische Berechtigungen zum Zugriff auf Ressourcen** in einem Azure Storage account gewähren, ohne die access keys des Accounts offenzulegen. Während access keys vollen administrativen Zugriff auf alle Ressourcen bieten, ermöglicht SAS eine granulare Kontrolle durch das Festlegen von Berechtigungen (wie read oder write) und einer Ablaufzeit.
Shared Access Signatures (SAS) sind sichere, zeitlich begrenzte URLs, die **spezifische Berechtigungen zum Zugriff auf Ressourcen** in einem Azure Storage account gewähren, ohne die access keys des Accounts offenzulegen. Während access keys vollständigen administrativen Zugriff auf alle Ressourcen bieten, ermöglicht SAS eine granulare Steuerung durch das Festlegen von Berechtigungen (wie read oder write) und einer Ablaufzeit.
#### SAS Types
- **User delegation SAS**: Dies wird aus einem **Entra ID principal** erstellt, der das SAS signiert und die Berechtigungen vom user an das SAS delegiert. Es kann nur mit **blob and data lake storage** verwendet werden ([docs](https://learn.microsoft.com/en-us/rest/api/storageservices/create-user-delegation-sas)). Es ist möglich, alle generierten user delegated SAS zu **revoke**n.
- Auch wenn es möglich ist, ein delegation SAS mit "mehr" Berechtigungen zu generieren als der user hat. Wenn der principal sie jedoch nicht hat, funktioniert es nicht (kein privesc).
- **Service SAS**: Dies wird mit einem der **access keys** des storage account signiert. Es kann verwendet werden, um Zugriff auf bestimmte Ressourcen in einem einzelnen storage service zu gewähren. Wenn der key erneuert wird, funktioniert das SAS nicht mehr.
- **Account SAS**: Es wird ebenfalls mit einem der **access keys** des storage account signiert. Es gewährt Zugriff auf Ressourcen über die services eines storage account hinweg (Blob, Queue, Table, File) und kann service-level operations enthalten.
- **User delegation SAS**: Dies wird aus einem **Entra ID principal** erstellt, der die SAS signiert und die permissions vom user auf die SAS delegiert. Es kann nur mit **blob and data lake storage** verwendet werden ([docs](https://learn.microsoft.com/en-us/rest/api/storageservices/create-user-delegation-sas)). Es ist möglich, alle generierten user delegated SAS zu **revoke**.
- Auch wenn es möglich ist, eine delegation SAS mit "mehr" permissions zu generieren als die, die der user hat. Wenn der principal sie jedoch nicht hat, funktioniert es nicht (no privesc).
- **Service SAS**: Dies wird mit einem der storage account **access keys** signiert. Es kann verwendet werden, um Zugriff auf bestimmte Ressourcen innerhalb eines einzelnen storage service zu gewähren. Wenn der key erneuert wird, funktioniert die SAS nicht mehr.
- **Account SAS**: Auch dies wird mit einem der storage account **access keys** signiert. Es gewährt Zugriff auf Ressourcen über die storage account services hinweg (Blob, Queue, Table, File) und kann service-level operations enthalten.
Eine SAS URL, die mit einem **access key** signiert ist, sieht so aus:
@@ -205,28 +205,28 @@ Eine SAS URL, die als **user delegation** signiert ist, sieht so aus:
Beachte einige **http params**:
- Der **`se`** param gibt das **expiration date** des SAS an
- Der **`sp`** param gibt die **permissions** des SAS an
- Der **`sig`** ist die **signature**, die das SAS validiert
- Der **`se`** param gibt das **expiration date** der SAS an
- Der **`sp`** param gibt die **permissions** der SAS an
- Der **`sig`** ist die **signature**, die die SAS validiert
#### SAS permissions
Beim Generieren eines SAS muss angegeben werden, welche permissions es gewähren soll. Je nachdem, über welchem objet das SAS generiert wird, können unterschiedliche permissions enthalten sein. Zum Beispiel:
Beim Generieren einer SAS muss angegeben werden, welche permissions sie gewähren soll. Abhängig vom Objekt, über das die SAS generiert wird, können unterschiedliche permissions enthalten sein. Zum Beispiel:
- (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 für Azure Blob Storage
## SFTP Support for Azure Blob Storage
Azure Blob Storage unterstützt jetzt das SSH File Transfer Protocol (SFTP), wodurch sichere Dateiübertragung und Verwaltung direkt zu Blob Storage möglich sind, ohne Custom Solutions oder Third-party products zu benötigen.
Azure Blob Storage unterstützt jetzt das SSH File Transfer Protocol (SFTP), wodurch sichere Dateiübertragung und -verwaltung direkt zu Blob Storage möglich sind, ohne benutzerdefinierte Lösungen oder Produkte von Drittanbietern zu benötigen.
### Key Features
- Protocol Support: SFTP funktioniert mit Blob Storage accounts, die mit hierarchical namespace (HNS) konfiguriert sind. Dadurch werden blobs in directories und subdirectories organisiert, was die Navigation erleichtert.
- Security: SFTP verwendet lokale user identities zur Authentifizierung und integriert sich nicht mit RBAC oder ABAC. Jeder lokale user kann sich authentifizieren über:
- Azure-generierte passwords
- Security: SFTP kann lokale user identities verwenden, unterstützt aber auch Microsoft Entra ID-basierten Zugriff mit Azure RBAC zur authorization. Das bedeutet, dass Zugriff mit den üblichen Blob Storage data-plane roles gewährt werden kann, statt lokale SFTP users zu erstellen. Lokale users können sich authentifizieren über:
- Azure-generated passwords
- Public-private SSH key pairs
- Granular Permissions: Berechtigungen wie Read, Write, Delete und List können lokalen users für bis zu 100 containers zugewiesen werden.
- Networking Considerations: SFTP connections werden über Port 22 hergestellt. Azure unterstützt Netzwerk-Konfigurationen wie firewalls, private endpoints oder virtual networks, um SFTP traffic abzusichern.
- Networking Considerations: SFTP connections werden über port 22 hergestellt. Azure unterstützt network configurations wie firewalls, private endpoints oder virtual networks, um SFTP traffic abzusichern.
### Setup Requirements
@@ -234,8 +234,8 @@ Azure Blob Storage unterstützt jetzt das SSH File Transfer Protocol (SFTP), wod
- Supported Encryption: Erfordert von Microsoft Security Development Lifecycle (SDL) genehmigte cryptographic algorithms (z. B. rsa-sha2-256, ecdsa-sha2-nistp256).
- SFTP Configuration:
- SFTP auf dem storage account aktivieren.
- Lokale user identities mit passenden Berechtigungen erstellen.
- Home directories für users konfigurieren, um ihren Startpunkt innerhalb des containers festzulegen.
- Für local-user access lokale user identities mit den passenden Berechtigungen erstellen.
- Für lokale users home directories konfigurieren, um ihren Startpunkt innerhalb des container zu definieren.
### Permissions
@@ -379,7 +379,7 @@ az storage account local-user list \
{{#tab name="Az PowerShell" }}
<details>
<summary>Az PowerShell-Aufzählung</summary>
<summary>Az PowerShell Aufzählung</summary>
```powershell
# Get storage accounts
Get-AzStorageAccount | fl
@@ -471,6 +471,7 @@ az-file-shares.md
- [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)