Az - Speicherkonten & Blobs

Reading time: 14 minutes

tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Grundlegende Informationen

Azure Storage Accounts sind grundlegende Dienste in Microsoft Azure, die skalierbaren, sicheren und hochverfügbaren Cloud Speicher für verschiedene Datentypen bereitstellen, einschließlich Blobs (Binary Large Objects), Dateien, Warteschlangen und Tabellen. Sie dienen als Container, die diese verschiedenen Speicher Dienste unter einem einzigen Namensraum zur einfachen Verwaltung gruppieren.

Hauptkonfigurationsoptionen:

  • Jedes Speicherkonto muss einen eindeutigen Namen über alle Azure haben.
  • Jedes Speicherkonto wird in einer Region oder in einer erweiterten Azure-Zone bereitgestellt.
  • Es ist möglich, die Premium-Version des Speicherkontos für bessere Leistung auszuwählen.
  • Es ist möglich, zwischen 4 Arten von Redundanz zum Schutz vor Rack-, Laufwerks- und Rechenzentrums-Ausfällen zu wählen.

Sicherheitskonfigurationsoptionen:

  • Sicheren Transfer für REST-API-Operationen erforderlich: TLS in jeder Kommunikation mit dem Speicher erforderlich.
  • Ermöglicht anonymen Zugriff auf einzelne Container: Andernfalls wird es nicht möglich sein, in Zukunft anonymen Zugriff zu aktivieren.
  • Zugriff auf den Schlüssel des Speicherkontos aktivieren: Andernfalls wird der Zugriff mit Shared Keys verboten.
  • Minimale TLS-Version.
  • Erlaubter Geltungsbereich für Kopieroperationen: Erlauben von jedem Speicherkonto, von jedem Speicherkonto aus demselben Entra-Mandanten oder von Speicherkonten mit privaten Endpunkten im selben virtuellen Netzwerk.

Blob-Speicheroptionen:

  • Erlaube die Replikation über Mandanten hinweg.
  • Zugriffsebene: Hot (häufig auf Daten zugreifen), Cool und Cold (selten auf Daten zugreifen).

Netzwerkoptionen:

  • Netzwerkzugriff:
  • Erlauben von allen Netzwerken.
  • Erlauben von ausgewählten virtuellen Netzwerken und IP-Adressen.
  • Öffentlichen Zugriff deaktivieren und privaten Zugriff verwenden.
  • Private Endpunkte: Ermöglicht eine private Verbindung zum Speicherkonto von einem virtuellen Netzwerk.

Datenschutzoptionen:

  • Wiederherstellung zu einem bestimmten Zeitpunkt für Container: Ermöglicht die Wiederherstellung von Containern in einen früheren Zustand.
  • Es erfordert, dass Versionierung, Änderungsprotokoll und Blob-Weichlöschung aktiviert sind.
  • Weichlöschung für Blobs aktivieren: Es ermöglicht einen Aufbewahrungszeitraum in Tagen für gelöschte Blobs (auch überschrieben).
  • Weichlöschung für Container aktivieren: Es ermöglicht einen Aufbewahrungszeitraum in Tagen für gelöschte Container.
  • Weichlöschung für Dateifreigaben aktivieren: Es ermöglicht einen Aufbewahrungszeitraum in Tagen für gelöschte Dateifreigaben.
  • Versionierung für Blobs aktivieren: Behalten Sie frühere Versionen Ihrer Blobs.
  • Blob-Änderungsprotokoll aktivieren: Protokollieren Sie Erstellungs-, Änderungs- und Löschänderungen an Blobs.
  • Unterstützung für Unveränderlichkeit auf Versionsebene aktivieren: Ermöglicht es Ihnen, eine zeitbasierte Aufbewahrungsrichtlinie auf Kontoebene festzulegen, die für alle Blob-Versionen gilt.
  • Unterstützung für Unveränderlichkeit auf Versionsebene und Wiederherstellung zu einem bestimmten Zeitpunkt für Container können nicht gleichzeitig aktiviert werden.

Verschlüsselungskonfigurationsoptionen:

  • Verschlüsselungstyp: Es ist möglich, Microsoft-managed keys (MMK) oder Customer-managed keys (CMK) zu verwenden.
  • Infrastrukturverschlüsselung aktivieren: Ermöglicht die doppelte Verschlüsselung der Daten "für mehr Sicherheit".

Speicherendpunkte

SpeicherdienstEndpunkt
Blob-Speicherhttps://.blob.core.windows.net

https://.blob.core.windows.net/?restype=container&comp=list
Data Lake Storagehttps://.dfs.core.windows.net
Azure Fileshttps://.file.core.windows.net
Warteschlangen-Speicherhttps://.queue.core.windows.net
Tabellen-Speicherhttps://.table.core.windows.net

Öffentliche Exposition

Wenn "Öffentlichen Zugriff auf Blobs erlauben" aktiviert ist (standardmäßig deaktiviert), ist es beim Erstellen eines Containers möglich:

  • Öffentlichen Zugriff auf Blobs zu gewähren (Sie müssen den Namen kennen).
  • Container-Blobs aufzulisten und sie zu lesen.
  • Es vollständig privat zu machen.

Verbindung zum Speicher

Wenn Sie einen Speicher finden, zu dem Sie eine Verbindung herstellen können, können Sie das Tool Microsoft Azure Storage Explorer verwenden, um dies zu tun.

Zugriff auf Speicher

RBAC

Es ist möglich, Entra ID-Prinzipien mit RBAC-Rollen zu verwenden, um auf Speicherkonten zuzugreifen, und es ist der empfohlene Weg.

Zugriffsschlüssel

Die Speicherkonten haben Zugriffsschlüssel, die verwendet werden können, um darauf zuzugreifen. Dies bietet vollen Zugriff auf das Speicherkonto.

Shared Keys & Lite Shared Keys

Es ist möglich, Shared Keys zu generieren, die mit den Zugriffsschlüsseln signiert sind, um den Zugriff auf bestimmte Ressourcen über eine signierte URL zu autorisieren.

note

Beachten Sie, dass der Teil CanonicalizedResource die Ressource der Speicher Dienste (URI) darstellt. Und wenn ein Teil der URL codiert ist, sollte er auch im CanonicalizedResource codiert werden.

note

Dies wird standardmäßig von az cli verwendet, um Anfragen zu authentifizieren. Um die Anmeldeinformationen des Entra ID-Prinzips zu verwenden, geben Sie den Parameter --auth-mode login an.

  • Es ist möglich, einen Shared Key für Blob-, Warteschlangen- und Dateidienste zu generieren, indem die folgenden Informationen signiert werden:
bash
StringToSign = VERB + "\n" +
Content-Encoding + "\n" +
Content-Language + "\n" +
Content-Length + "\n" +
Content-MD5 + "\n" +
Content-Type + "\n" +
Date + "\n" +
If-Modified-Since + "\n" +
If-Match + "\n" +
If-None-Match + "\n" +
If-Unmodified-Since + "\n" +
Range + "\n" +
CanonicalizedHeaders +
CanonicalizedResource;
  • Es ist möglich, einen gemeinsamen Schlüssel für Tabellenservices zu generieren, indem die folgenden Informationen signiert werden:
bash
StringToSign = VERB + "\n" +
Content-MD5 + "\n" +
Content-Type + "\n" +
Date + "\n" +
CanonicalizedResource;
  • Es ist möglich, einen lite shared key für Blob-, Queue- und Dateidienste zu generieren, indem die folgenden Informationen signiert werden:
bash
StringToSign = VERB + "\n" +
Content-MD5 + "\n" +
Content-Type + "\n" +
Date + "\n" +
CanonicalizedHeaders +
CanonicalizedResource;
  • Es ist möglich, einen lite shared key für Tabellenservices zu generieren, indem die folgenden Informationen signiert werden:
bash
StringToSign = Date + "\n"
CanonicalizedResource

Dann kann der Schlüssel im Authorization-Header gemäß der Syntax verwendet werden:

bash
Authorization="[SharedKey|SharedKeyLite] <AccountName>:<Signature>"
#e.g.
Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=

PUT http://myaccount/mycontainer?restype=container&timeout=30 HTTP/1.1
x-ms-version: 2014-02-14
x-ms-date: Fri, 26 Jun 2015 23:39:12 GMT
Authorization: SharedKey myaccount:ctzMq410TV3wS7upTBcunJTDLEJwMAZuFPfr0mrrA08=
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-Konto gewähren, ohne die Zugriffsschlüssel des Kontos offenzulegen. Während Zugriffsschlüssel vollständigen administrativen Zugriff auf alle Ressourcen bieten, ermöglicht SAS eine granulare Kontrolle, indem Berechtigungen (wie Lesen oder Schreiben) festgelegt und eine Ablaufzeit definiert werden.

SAS-Typen

  • Benutzerdelegation SAS: Dies wird von einem Entra ID-Prinzipal erstellt, der die SAS signiert und die Berechtigungen vom Benutzer an die SAS delegiert. Es kann nur mit Blob- und Data Lake Storage verwendet werden (docs). Es ist möglich, alle generierten benutzergestützten SAS zu widerrufen.
  • Auch wenn es möglich ist, eine Delegation SAS mit "mehr" Berechtigungen zu generieren, als der Benutzer hat. Wenn der Prinzipal diese jedoch nicht hat, funktioniert es nicht (kein Privesc).
  • Service SAS: Dies wird mit einem der Zugriffsschlüssel des Speicherkontos signiert. Es kann verwendet werden, um den Zugriff auf spezifische Ressourcen in einem einzelnen Speicherdienst zu gewähren. Wenn der Schlüssel erneuert wird, funktioniert die SAS nicht mehr.
  • Konto SAS: Es wird ebenfalls mit einem der Zugriffsschlüssel des Speicherkontos signiert. Es gewährt Zugriff auf Ressourcen über die Dienste eines Speicherkontos (Blob, Queue, Table, File) und kann dienstebezogene Operationen umfassen.

Eine SAS-URL, die mit einem Zugriffsschlüssel signiert ist, sieht so aus:

  • 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

Eine SAS-URL, die als Benutzerdelegation signiert ist, sieht so aus:

  • 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

Beachten Sie einige HTTP-Parameter:

  • Der se-Parameter gibt das Ablaufdatum der SAS an.
  • Der sp-Parameter gibt die Berechtigungen der SAS an.
  • Der sig ist die Signatur, die die SAS validiert.

SAS-Berechtigungen

Beim Generieren einer SAS ist es erforderlich, die Berechtigungen anzugeben, die sie gewähren soll. Abhängig von dem Objekt, über das die SAS generiert wird, können unterschiedliche Berechtigungen 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-Unterstützung für Azure Blob Storage

Azure Blob Storage unterstützt jetzt das SSH File Transfer Protocol (SFTP), das einen sicheren Dateitransfer und -management direkt zu Blob Storage ermöglicht, ohne dass benutzerdefinierte Lösungen oder Produkte von Drittanbietern erforderlich sind.

Hauptmerkmale

  • Protokollunterstützung: SFTP funktioniert mit Blob Storage-Konten, die mit hierarchischem Namensraum (HNS) konfiguriert sind. Dies organisiert Blobs in Verzeichnisse und Unterverzeichnisse für eine einfachere Navigation.
  • Sicherheit: SFTP verwendet lokale Benutzeridentitäten zur Authentifizierung und integriert sich nicht in RBAC oder ABAC. Jeder lokale Benutzer kann sich über folgende Methoden authentifizieren:
  • Von Azure generierte Passwörter
  • Öffentliche-private SSH-Schlüsselpaare
  • Granulare Berechtigungen: Berechtigungen wie Lesen, Schreiben, Löschen und Auflisten können lokalen Benutzern für bis zu 100 Container zugewiesen werden.
  • Netzwerküberlegungen: SFTP-Verbindungen erfolgen über Port 22. Azure unterstützt Netzwerkkonfigurationen wie Firewalls, private Endpunkte oder virtuelle Netzwerke, um den SFTP-Verkehr abzusichern.

Einrichtungsanforderungen

  • Hierarchischer Namensraum: HNS muss beim Erstellen des Speicherkontos aktiviert sein.
  • Unterstützte Verschlüsselung: Erfordert von Microsoft genehmigte kryptografische Algorithmen (z. B. rsa-sha2-256, ecdsa-sha2-nistp256).
  • SFTP-Konfiguration:
  • SFTP im Speicherkonto aktivieren.
  • Lokale Benutzeridentitäten mit entsprechenden Berechtigungen erstellen.
  • Home-Verzeichnisse für Benutzer konfigurieren, um ihren Startort innerhalb des Containers zu definieren.

Berechtigungen

BerechtigungSymbolBeschreibung
LesenrDateiinhalte lesen.
SchreibenwDateien hochladen und Verzeichnisse erstellen.
AuflistenlInhalte von Verzeichnissen auflisten.
LöschendDateien oder Verzeichnisse löschen.
ErstellencDateien oder Verzeichnisse erstellen.
Besitz ändernoDen besitzenden Benutzer oder die Gruppe ändern.
Berechtigungen ändernpACLs für Dateien oder Verzeichnisse ändern.

Enumeration

bash
# Get storage accounts
az storage account list #Get the account name from here

# BLOB STORAGE
## List containers
az storage container list --account-name <name>
## Check if public access is allowed
az storage container show-permission \
--account-name <acc-name> \
-n <container-name>
## Make a container public
az storage container set-permission \
--public-access container \
--account-name <acc-name> \
-n <container-name>
## List blobs in a container
az storage blob list \
--container-name <container name> \
--account-name <account name>
## Download blob
az storage blob download \
--account-name <account name> \
--container-name <container name> \
--name <blob name> \
--file </path/to/local/file>
## Create container policy
az storage container policy create \
--account-name mystorageaccount \
--container-name mycontainer \
--name fullaccesspolicy \
--permissions racwdl \
--start 2023-11-22T00:00Z \
--expiry 2024-11-22T00:00Z

# QUEUE
az storage queue list --account-name <name>
az storage message peek --account-name <name> --queue-name <queue-name>

# ACCESS KEYS
az storage account keys list --account-name <name>
## Check key policies (expiration time?)
az storage account show -n <name> --query "{KeyPolicy:keyPolicy}"
## Once having the key, it's possible to use it with the argument --account-key
## Enum blobs with account key
az storage blob list \
--container-name <container name> \
--account-name <account name> \
--account-key "ZrF40pkVKvWPUr[...]v7LZw=="
## Download a file using an account key
az storage blob download \
--account-name <account name> \
--account-key "ZrF40pkVKvWPUr[...]v7LZw==" \
--container-name <container name> \
--name <blob name> \
--file </path/to/local/file>
## Upload a file using an account key
az storage blob upload \
--account-name <account name> \
--account-key "ZrF40pkVKvWPUr[...]v7LZw==" \
--container-name <container name> \
--file </path/to/local/file>

# SAS
## List access policies
az storage <container|queue|share|table> policy list \
--account-name <acc name> \
--container-name <container name>

## Generate SAS with all permissions using an access key
az storage <container|queue|share|table|blob> generate-sas \
--permissions acdefilmrtwxy \
--expiry 2024-12-31T23:59:00Z \
--account-name <acc-name> \
-n <container-name>

## Generate SAS with all permissions using via user delegation
az storage <container|queue|share|table|blob> generate-sas \
--permissions acdefilmrtwxy \
--expiry 2024-12-31T23:59:00Z \
--account-name <acc-name> \
--as-user --auth-mode login \
-n <container-name>

## Generate account SAS
az storage account generate-sas \
--expiry 2024-12-31T23:59:00Z \
--account-name <acc-name>  \
--services qt \
--resource-types sco \
--permissions acdfilrtuwxy

## Use the returned SAS key with the param --sas-token
## e.g.
az storage blob show \
--account-name <account name> \
--container-name <container name> \
--sas-token 'se=2024-12-31T23%3A59%3A00Z&sp=racwdxyltfmei&sv=2022-11-02&sr=c&sig=ym%2Bu%2BQp5qqrPotIK5/rrm7EMMxZRwF/hMWLfK1VWy6E%3D' \
--name 'asd.txt'

#Local-Users
## List users
az storage account local-user list \
--account-name <storage-account-name> \
--resource-group <resource-group-name>
## Get user
az storage account local-user show \
--account-name <storage-account-name> \
--resource-group <resource-group-name> \
--name <local-user-name>

## List keys
az storage account local-user list \
--account-name <storage-account-name> \
--resource-group <resource-group-name>

Dateifreigaben

Az - File Shares

Privilegienerweiterung

Az - Storage Privesc

Nach der Ausnutzung

Az - Blob Storage Post Exploitation

Persistenz

Az - Storage Persistence

Referenzen

tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks