Az - Storage Accounts & Blobs

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Unterstütze HackTricks

Grundinformationen

Azure-Speicherkonten 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 Rechenzentrumsausfä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.

  • Aktivieren des Zugriffs auf das Speicherkonto über Schlüssel: Andernfalls wird der Zugriff mit Shared Keys verboten.

  • Minimale TLS-Version

  • Erlaubter Geltungsbereich für Kopieroperationen: Erlaubt 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 zugegriffen), Cool und Cold (selten auf Daten zugegriffen)

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.

  • Aktivieren der Weichlöschung für Blobs: Es ermöglicht einen Aufbewahrungszeitraum in Tagen für gelöschte Blobs (auch überschrieben).

  • Aktivieren der Weichlöschung für Container: Es ermöglicht einen Aufbewahrungszeitraum in Tagen für gelöschte Container.

  • Aktivieren der Weichlöschung für Dateifreigaben: Es ermöglicht einen Aufbewahrungszeitraum in Tagen für gelöschte Dateifreigaben.

  • Aktivieren der Versionierung für Blobs: Behalte frühere Versionen deiner Blobs.

  • Aktivieren des Blob-Änderungsprotokolls: Halte Protokolle über Erstellungs-, Änderungs- und Löschänderungen an Blobs.

  • Aktivieren der Unterstützung für Unveränderlichkeit auf Versionsebene: Ermöglicht es dir, 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-verwaltete Schlüssel (MMK) oder vom Kunden verwaltete Schlüssel (CMK) zu verwenden.

  • Aktivieren der Infrastrukturverschlüsselung: Ermöglicht die doppelte Verschlüsselung der Daten "für mehr Sicherheit".

Speicherendpunkte

Blob-Speicher

https://<storage-account>.blob.core.windows.net https://<stg-acc>.blob.core.windows.net/<container-name>?restype=container&comp=list

Data Lake Storage

https://<storage-account>.dfs.core.windows.net

Azure Files

https://<storage-account>.file.core.windows.net

Warteschlangen-Speicher

https://<storage-account>.queue.core.windows.net

Tabellen-Speicher

https://<storage-account>.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 zum Lesen von Blobs zu gewähren (man muss den Namen kennen).

  • Container-Blobs aufzulisten und sie zu lesen.

  • Es vollständig privat zu machen.

Verbindung zum Speicher

Wenn du einen Speicher findest, zu dem du eine Verbindung herstellen kannst, kannst du 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.

Beachte, dass der Teil CanonicalizedResource die Ressource des Speicherdienstes (URI) darstellt. Und wenn ein Teil der URL kodiert ist, sollte er auch im CanonicalizedResource kodiert sein.

Dies wird standardmäßig von az cli verwendet, um Anfragen zu authentifizieren. Um die Anmeldeinformationen des Entra ID-Prinzips zu verwenden, gib 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:

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 Tabellendienste zu generieren, indem die folgenden Informationen signiert werden:

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:

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:

StringToSign = Date + "\n"
CanonicalizedResource

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

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 vom 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 Dateiübertrag und -verwaltung direkt zu Blob Storage ermöglicht, ohne benutzerdefinierte Lösungen oder Produkte von Drittanbietern zu benötigen.

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

Berechtigung
Symbol
Beschreibung

Lesen

r

Dateiinhalt lesen.

Schreiben

w

Dateien hochladen und Verzeichnisse erstellen.

Auflisten

l

Inhalte von Verzeichnissen auflisten.

Löschen

d

Dateien oder Verzeichnisse löschen.

Erstellen

c

Dateien oder Verzeichnisse erstellen.

Besitz ändern

o

Den besitzenden Benutzer oder die Gruppe ändern.

Berechtigungen ändern

p

ACLs für Dateien oder Verzeichnisse ändern.

Enumeration

# 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

Privilegieneskalation

Az - Storage Privesc

Nach der Ausnutzung

Az - Blob Storage Post Exploitation

Persistenz

Az - Storage Persistence

Referenzen

Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Unterstütze HackTricks

Last updated